MCP
Показаны сообщения с ярлыком windows. Показать все сообщения
Показаны сообщения с ярлыком windows. Показать все сообщения

воскресенье, 10 февраля 2019 г.

Деградация Windows Server

Есть у меня простенький компьютер. Был куплен в порыве шопоголизма на распродаже. Я так и не придумал, чем занять данный компьютер, поэтому накатил на него Windows Server 2016 (По факту LTSB сборка 10-ой винды 1607, которая Anniversary Update, но с серверными фичами). Компьютер после запуска (и ожидания 8 минут, пока винда разберётся со своими внутренними делами) выглядел так:

Если не вдаваться в подробности, то запущено 54 процесса, 848 потоков и занято 0.9Гб оперативки. Вполне допустимая ситуация для пустого сервера, хотя всегда хочется меньше.

Но я решил потестировать недавно вышедший Windows Server 2019, эта та же Windows 10, только уже злополучная 1809, October 2018 Update. Я просто обновил сервер, подождал джентльменские 8 минут и результат на экране:

Процессов уже стало 110 (ровно в два раза больше!), количество потоков увеличилось всего на 300 штук, что уже лучше, хендлов стало больше почти в 2 раза и сожрано стало на 400МБ оперативной памяти больше.

Ещё раз, для понимания бреда. За 2 года разработки операционная система на свои личные нужды стала использовать гораздо больше ресурсов. Может от этого она стала быстрее или лучше работать? Как-то незаметно. Вместо оптимизации системы в итоге получаешь просто ещё больше внутреннего потребления. Зачем? А просто так, потому что программисты Microsoft могут тратить ресурсы как захотят. Железо же становится быстрее, памяти больше, никто и не заметит. И вот это бесит неимоверно.

UPD: Оказывается, это сознательное решение Microsoft, они в 1703 разгруппировали сервисы, если в системе больше чем 3.5ГБ памяти. Объяснили как всегда надёжностью и безопасностью. Но памяти это, конечно же, жрёт больше, о чём не скрывают. А то, что "стабильность" теперь зависит от количества оперативной памяти — выглядит это очень странно.

UPD2: Поиск решения проблемы привёл на следующую ссылку, надо в реестре по пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control отредактировать (создать?) ключ SvcHostSplitThresholdInKB, изменив там количество памяти для разделения процессов. Итог изменения ключа следующий:

Процессов и памяти резко уменьшилось. До старых значений ещё не доходит, но всё-таки результат стал получше. 

среда, 6 апреля 2016 г.

Windows Update ошибка 800F0922

Собственно, данный пост на случай, если его нагуглят, ибо гугление ошибок с виндовым апдейтом — самое милое дело. Других сведений про источник проблемы обычно нет.
Итак, я долго возился с тем, что у меня не ставились некоторые обновления. Занимался уже делением пополам и установкой того, что ставится (ибо, если не ставится одно, откатываются все пакетом, ибо транзакционность). Но на днях решил разобраться, в чём же причина.
Собственно, т.к. не ставилась куча апдейтов, код конкретного не привожу, но ошибка была с кодом 800F0922, и выглядела примерно так

Гуглёж по коду выдал кучу безумных рекомендаций вида — удалить драйвер Cisco VPN или увеличить служебный раздел System Reserved. А также стандартные пляски с бубном вида sfc /scannow и сброса состояния Windows Update. Но первые причины явно были не мои, а вторые помогают только, когда действительно сломано всё. У меня же были проблемы только с частью апдейтов.

В общем, я пошёл копать в логи, которые у апдейтов находятся в C:\Windows\Logs\CBS\CBS.log на предмет, того, что же там не так. А не так там оказалась подобная строчка (хана дизайну блога, ну да ладно):

2016-04-05 10:03:35, Error                 CSI    00000001 (F) Logged @2016/4/5:07:03:35.059 : [ml:262{131},l:260{130}]"events installer: online=1, install=1, component=wow64_Microsoft-Windows-Win32k_31bf3856ad364e35_6.2.9200.17461_neutral_release__."
[gle=0x80004005]
2016-04-05 10:03:35, Error                 CSI    00000002 (F) Logged @2016/4/5:07:03:35.090 : [ml:240{120},l:238{119}]"EventAITrace:Provider Microsoft-Windows-Win32k is already installed with GUID {e7ef96be-969f-414f-97d7-3ddb7b558ccc}.

"
[gle=0x80004005]


2016-04-05 10:03:35, Error                 CSI    00000003 (F) Logged @2016/4/5:07:03:35.090 : [ml:168{84},l:166{83}]"WmiCmiPlugin manproc.cpp(683): InstrumentationManifestAssert failed. HR=0x80073aa2."
[gle=0x80004005]


2016-04-05 10:03:35, Error                 CSI    00000004 (F) Logged @2016/4/5:07:03:35.090 : [ml:166{83},l:164{82}]"WmiCmiPlugin eventloghandler.cpp(192): ProcessEventsInstall failed. HR=0x80073aa2."
[gle=0x80004005]


2016-04-05 10:03:35, Error                 CSI    00000005 (F) Logged @2016/4/5:07:03:35.090 : [ml:170{85},l:168{84}]"WmiCmiPlugin eventloghandler.cpp(212): EventLogHandlerInstall failed. HR=0x80073aa2."
[gle=0x80004005]


2016-04-05 10:03:35, Error                 CSI    00000006@2016/4/5:07:03:35.090 (F) CMIADAPTER: Inner Error Message from AI HRESULT = HRESULT_FROM_WIN32(15010)
 [
[22]"Configuration error.

"
]

аКлючевое в этом: EventAITrace:Provider Microsoft-Windows-Win32k is already installed with GUID {e7ef96be-969f-414f-97d7-3ddb7b558ccc}, т.е. в переводе на русский, уже есть источник журнала событий, а его опять пытаются сделать. Почему бы не успокоиться, я не знаю. Но решение тут банальное:

  • идём в реестр в ветку HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{e7ef96be-969f-414f-97d7-3ddb7b558ccc}
  • Экспортируем её на всякий случай
  • Удаляем
  • Перегружаемся (это важно)
  • Пробуем установить апдейт заново
И чудо! всё заработало. Все апдейты стали снова ставиться без проблем.
Это, естественно, не единственный вариант источника проблемы, но, может быть в вашем случае он поможет.

пятница, 27 февраля 2015 г.

Немного про починку винды через много букв

Я уже писал про то, что надо бекапить самое ценное у винды, как что-то сделать с упавшей виндой, и как работать с реестром в не загружающейся.
Сегодня чуть-чуть расскажу про то, что можно сделать, если винда пережила экзистенциальный кризис, но загружается и местами пытается работать.

В качестве примера буду приводить систему, с которой недавно боролся после того, как она сама себе испоганила диск. Точнее не она, заглючил RAID-контроллер и вместо обеспечения целостности запорол кучу файлов (похоже писал данные не в те блоки), потом он, конечно, отправил систему в синий экран, но это было уже потом.

Винда, с трудом но поднялась после всего этого, правда для этого пришлось починить несколько важных для загрузки файлов и собрать монстра из реестра (комбинация из встроенного бекапа в C:\Windows\System32\config\RegBack\ и основного реестра), но в общем-то фатальных проблем не было.
Правда при работе слегка глючила, не давала подключиться удалённо, плюс были ещё мелкие и не очень проблемы (некоторые выявились только спустя несколько месяцев).
Что можно с этим сделать, и как чинить?

Вариант 1. Апгрейд винды на саму себя из установочных файлов

Винда бережно сохраняет все настройки и восстанавливает их в новой системе. Но есть проблема, могут сохраниться ошибочные настройки, а часть данных не перенесётся, причём лучше уж поломанный сервис, который ты знаешь, что надо починить, чем рабочий, у которого потерялась какая-то хитрая настройка, и из-за этого он поведёт себя не так как надо.
Так что этот способ не очень хорош, кроме того требует некоторого даунтайма системы (на установку и настройку сервисов снова). У меня был один такой системный сервис, который очень не хотелось трогать (и да, он разваливается при переустановке, можно поднять его из бекапа, и потом донастроить).
Так что я пробовал другие способы

Вариант 2. sfc /scannow

Способ, который рекомендуют на всех форумах, к сожалению помогает он плохо, т.е. ничего не лечит (ему неоткуда взять корректные файлы при серьёзных повреждениях), но зато создаёт логи в C:\Windows\Logs\CBS\CBS.log, с помощью которых можно узнать повреждённые файлы и физически заменить их с аналогичной системы (тут очень помогает Far, который достаточно вольно относится к отсутствию прав на файлы (т.е. если есть права выдать себе права, но в данный момент их нет, а приказ что-то сделать с файлом есть, фар решит эту проблему самостоятельно). Без фара можно ручками выдавать права на проблемные файлы, меняя владельца с TrustedInstaller на себя и раздавая права (если хочется красоты, следующий запуск sfc /scannow всё починит).
Таким образом я починил большинство проблем и система жила, пока не потребовалось ещё кое-что настроить.
Но для начала

Вариант 3. dism

Утверждается, что свежая винда может себя починить через следующую команду:

DISM.exe /Online /Cleanup-image /Restorehealth

или

DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairSource\Windows /LimitAccess

Первый способ обещает починить файлы через Windows Update, второй использует локальное хранилище в случае невозможности подключиться.

Вкратце: способ мне не помог, хотя что-то делал и явных ошибок работы не выдавал. Тем не менее, он много каши не просит, поэтому стоит его попробовать.



Файлы были починены, но потом неожиданно начал стрелять реестр, причём совершенно непредсказуемо. Я подобных проблем ещё не встречал, гугл тоже даёт подозрительно мало вариантов. Поэтому, тут я расскажу только общие проблемы и возможные пути их решения, ибо если у вас будет подобное, оно будет подобным, а не точно таким.

Итак, на первый взгляд проблемы появились в том, что не ставились апдейты. Изучение ошибок и логов привело к парадоксальному результату: они не ставились, потому что валился Task Scheduler со статусом что-то типа Initialize::UserTable (за точность ошибки не ручаюсь, ибо по памяти). Т.е. совершенно невменяемая ошибка. Были перепробованы все средства, пока не оказалось, что проблема в том, что в управлении пользователями отсутствовали локальные пользователи, а при открытии групп вылезало две ошибки с чтением данных. Т.е. проблема не в этом, а в том что есть именно проблема с пользователями. При этом из консоли (net user, net localgroup) проблем явных не было.

Тут я полез уже в дебри и выяснил следующее:
Вся информация о пользователях хранится в ветке реестра SAM, которая в реестре замаплена на HKEY_LOCAL_MACHINE\SAM. Если вы откроете ветку сейчас, вы ничего там не увидите. Рекомендую добавить себе права.
Там всё внутри устроено оригинально и не так как в остальном реестре. В частности, есть группы пользователей (SAM\Domains\Account\Aliases) и сами локальные пользователи (SAM\Domains\Account\Users). Они идентифицируется неким id, а сопоставление имён и id идёт в отдельном разделе (SAM\Domains\Account\Users\Names\), где в качестве типа указан данный id. Т.е. не значение, а тип. который обычно DWORD, STRING, BINARY. Впрочем, это можно списать на особенности отображения и то, что этот раздел не предназначен для обычных глаз.
У пользователей есть бинарные параметры F и V, а у групп С, которые содержат описание объекта, SIDы, и кто кому принадлежит.
В моём случае, были повреждены разделы C (их тупо не было) у групп администраторов и пользователей, и был один повреждённый пользователь (хотя визуально он был в порядке.
Эти проблемы и вызывали странное поведение в управлении пользователями.
Если хочется тут что-то сделать, вначале делаем бекап, потом играемся как хотим. У нас есть возможность откатиться.
Эмпирическим путём проблемный пользователь был вычислен и уничтожен (удалением ветки реестра), пользователи вернулись в норму. Раздел C, был импортирован с соседнего компьютера и всё ожило (Планировщик, а вместе с ним и апдейты. То ли у них были проблемы с группами, то ли с пользователем). К сожалению, в управлении группами в этих группах появились неизвестные SIDы (неудивительно, с таким-то импортом), которые не удалялись, а также не добавлялись новые пользователи.

Наилучшим решением проблемы я посчитал следующее (очень не хотелось разбираться в бинарной структуре данных записей, не стоит оно того). Например, у нас проблемная группа Administrators. Создаём группу Bdministrators. В эту группу добавляем нужных пользователей (самого администратора, например). Экспортируем из реестра обе группы по отдельности. Переносим бинарные данные из экспортированного файла от Bdministrators в Administrators, и импортируем его назад. Тем самым, у нас появились правильные администраторы (с правильным id), но неправильным именем. Ну, тут открываем в редакторе реестра бинарный редактор и меняем код байтика, отвечающий за B, на A. Всё, у нас правильные администраторы. Лишнюю группу удаляем, чтобы не мешалась. Повторяем тоже самое для других групп.
Результат — всё красиво и работает.



На этом пока всё. Я рассказал как чинить файлы, и что можно сделать с реестром. После этого, при желании винду можно восстановить почти из любого состояния, вопрос только целесообразности. А я буду ожидать очередного безумного сюрприза от очередной системы, но также буду надеяться, что он случится когда-нибудь попозже.

воскресенье, 28 декабря 2014 г.

Новогоднее RDP

Скоро новый год, а значит выходные, т.е. к серверам лучше не прикасаться, а если прикасаться, то аккуратно. Естественно, Microsoft всех приучило, что самый простой и ненапряжный способ это сделать - RDP (нет, конечно, PowerShell рулит и бибикает, но назвать этот способ простым, как-то язык не поворачивается).

Итак, RDP живёт, проблем вроде бы нет, но... в один прекрасный момент вы обнаруживаете следующую картину, которые можете наблюдать продолжительное время без видимых результатов.


Другими словами, при попытке подключения — RDP тупит, а потом идёт отлуп с пространными объяснениями, что всё плохо.
Вы дома, сервер далеко, к нему не подойти и не пнуть ногами. Подключиться — не удаётся.
Практика показывает, что это частое явление при разрывах сети. Т.е. кроме разрыва соединения, ещё появляются такие шикарные эффекты. Причем страдают обычно 8-ые винды (т.е. Windows Server 2012 и 2012 R2)
Что в этом случае можно сделать?

Для начала, конечно же выполнить пункт номер 0 — иметь пути отхода и дырку в фаирволле. Причём делать это по-возможности всегда. Т.е. у вас всегда должно быть как минимум 2 пути подключения к серверу (например через рабочий компьютер и через другой сервер), и желательно на определённые IP иметь хороший список открытых портов для этих дружественных компов. Винда это вам не Linux, тут одним SSH не обойдёшься, особенно когда так тупит RDP!

Вариант первый, банальный и неинтересный:
shutdown /m \\server /r /t 1
Отправляем компьютер в ребут... очевидно и неинтересно. Надо идти другими путями. Другие пути заключаются в том, что надо бы перепустить службу Remote Desktop, которая зовётся TermService.

Тут 2 варианта:
sc \\server restart TermService (оцените синтаксис команды относительно предыдущей)

Или же, с помощью мышки: mmc.exe, добавить остнаску, службы, другой компьютер, перезапуск.

Но, тут как всегда нас ждёт сюрприз... в 90% случаях служба зависнет и не захочет останавливаться. Так что придётся добивать её ногами. Битьё усложняется тем, что она висит в процессе svchost.exe (благо обычно на нужном ничего полезного нет).

Так что
tasklist /s server /svc | findstr TermService (оценили синтаксис?)
taskkill /s server /pid 123456

Ну и запускаем службу. Вроде просто и очевидно, но как всегда лезут нюансы: если у нас плохо с логином и паролем (а мы дома, а не в домене), то получим отказ в доступе. Некоторые команды имеют возможность указать логин с паролем, некоторые используют существующее соединение (net use \\server\c$ - получим замечательное подключение и для управления), некоторые просто отказываются работать.

Можно применить PowerShell, создать сессию на сервер и там всё сделать, но ведь его надо настроить... добавить доверие... в общем если вы не занимаетесь этим специально, работать не будет.

Так что, если всё плохо и ничего не работает, то придётся ползти в сторону Sysinternals, а именно PsTools, и через psexec уже всё делать. Что удивительно, работает это гораздо надёжнее, чем встроенные средства системы. Даже если не разбираться, можно написать


psexec \\server tasklist /svc

И получить тот же результат (да, мне лень изучать другие команды из этого набора ).

Собственно, зачем я это написал? Вроде очевидные вещи. Да в общем-то с двумя простыми целями: в очередной раз поныть на винду, и показать, что если что-то не работает, можно всё-таки обойтись без перезагрузки.

UPD: Спустя время, надо бы добавить ещё пару команд, которые помогут решить подобную проблему. Ибо у Microsoft всё устроено очень сложно, половина команд может работать, а другая половина не работать с дурацкими сообщениями вида (не шутка):
Couldn't access server:

The operation completed successfully.

Соответственно, tasklist /svc в нашём случае можно заменить на
sc queryex TermService

А вот с taskkill посложнее. Может прокатить скрипт на PowerShell
Invoke-Command -ComputerName server -ScriptBlock {Stop-Process -Id 123456 -Force} -Credential DOMAIN\user

суббота, 16 ноября 2013 г.

Windows, делаем бекап самого дорогого

Как известно, люди делятся на тех, кто ещё не делает бекапы, и тех кто уже делает. Я предпочитаю использовать для дома следующую схему: не часто, но периодически делаю полный бекап системы на случай глобального факапа, а также, гораздо чаще сохраняю важные данные (и храню большее количество версий). Под важными данными я понимаю рабочие файлы, настройки программ, базы данных. И данные бекапы также используются для восстановления случайно удалённых или изменённых файлов без полного отката системы.

Сегодня же, я хочу рассказать, как сделать бекап самого ценного для винды, а именно реестра. Дело в том, что в настоящий момент, практически всё необходимое для жизни винды хранится именно там. Вплоть до того, что если у вас есть сохранённая копия реестра, то вы можете поставить новую систему, и подменить ей реестр. И она заработает как старая, со всеми предыдущими настройками! Конечно, есть некоторые оговорки: повалятся некоторые сервисы и программы, будут проблемы с драйверами. Но эти проблемы можно уже решить в рабочем порядке. Главное — на вас не будет смотреть голая система.

Кому-то такое покажется странным, ведь некоторые люди переставляют систему постоянно, или периодически по настроению, и любят всё настраивать идеально (а через несколько месяцев — повторить). Я же подобное не люблю, и у меня в системе попадаются ошмётки десятилетней давности, просто потому что я привык к своему рабочему инструменту, и не хочу что-то кардинально менять без веской причины и привыкать заново.

В общем, если вам относительно близко моё мнение, я расскажу, как сохранить реестр, чтобы в случае непредвиденных проблем можно было его восстановить и продолжить работать в существующей системе не переставляя заново.

Где хранится реестр?

Он хранится в нескольких файлах. Во-первых, в папке C:\Windows\System32\config\ Там находятся файлы вида SYSTEM, SOFTWARE, SAM, COMPONENTS, DRIVERS. Это соответствующие ветки реестра. Например, SYSTEM — информация о сервисах и драйверах, SOFTWARE — установленные драйвера, SAM — данные о пользователях с внутренними идентификаторами и паролями (именно данная ветка обычно хорошо так меняется при установке, из-за чего система становится "особенно другой").
Также в этой папке находится системный профиль (профиль компьютера, который с точки зрения системы почти настоящий пользователь), и всякая другая мелочёвка.
При перезагрузке системы копия реестра сохраняется в папке RegBack. Я не очень представляю, когда данные из RegBack могут использоваться автоматически, но в случае проблем можно попытаться подменить файлы реестра из данной папки, чтобы восстановить работоспособность.

Также, в папке с профилем каждого пользователя (C:\Users\username\) находится файл ntuser.dat, являющийся реестром для данного пользователя.

Собственно, эти файлы мы и будем архивировать.

Как сделать архивную копию?

Какзалось бы, просто взять и скопировать. Но не всё так просто. Дело в том, что данные файлы заблокированы системой (справедливости ради, из RegBack можно достать файлы достаточно просто, но они будут не очень свежими в случае отсутствия перезагрузок, да и реестр пользователя не архивируется самостоятельно).

Т.е. с большинством файлов ничего не сделать на рабочей системе. В качестве аварийного решения, можно загрузиться в recovery режиме или с установочного диска/флешки, и вручную заархивировать данные файлы. Но данный вариант обычно используется, когда всё плохо, и данная копия делается при попытке восстановления, на случай, если после восстановления станет ещё хуже и надо будет откатиться.

Мы же не будем искать аварийных путей, и займёмся использованием встроенных средств Windows, а именно Volume Shadow Copy, теневой копией.

При создании теневой копии диска, создаётся снимок всей файловой системы на заданный момент времени, с неизменяемыми файлами. Который можно использовать для чтения заблокированных файлов или использовать в качестве версии файлов на определённый момент времени (так работает System Restore в Windows, она делает примерно тоже самое, в определённых случаях).

Итак, что надо сделать:
  1. Сделать теневую копию диска
  2. Подмонтировать её симлинком для удобства работы
  3. Скопировать нужные файлы
  4. Удалить копию
Всё это можно сделать из консоли, используя стандартные утилиты, я для удобства написал всё это на Powershell.

Итак по пунктам (полный скрипт в конце поста):

Делаем теневую копию и монтируем её:
Function CreateShadow($disk)
{
    # e.g. c: -> c:\
    $disk = $disk[0] + ':\';

    $shadowObj = (gwmi -List Win32_ShadowCopy).Create($disk, "ClientAccessible")
    $currentShadow = gwmi Win32_ShadowCopy | ? { $_.ID -eq $shadowObj.ShadowID }
    $shadowID = $currentShadow.ID
    $name  = $currentShadow.DeviceObject + "\"
    $dummy = cmd /c "mklink /d .\$shadowID $name"
    Write-Host $dummy
    return $shadowID
}

В данном куске скрипта мы через WMI создаём теневую копию, получаем её идентификатор, и монтируем её в качестве симлинка в текущей папке (с названием как идентификатор теневой копии).
Используя данный скрипт уже можно вручную скопировать файлы. Ну или автоматически, примерно так:
Function PerformBackup($shadowPath, $bakRoot)
{
    if ($shadowPath -like '%\')
    {
        $shadowPath = $shadowPath.SubString(0, $shadowPath.Length - 1)
    }

    if ($bakPath -like '%\')
    {
        $bakPath = $bakPath.SubString(0, $bakPath.Length - 1)
    }

    $tmpFile = "$PWD\tmpFileList.txt"

    # if script was incorrectly finished
    if (Test-Path $tmpFile)
    {
        Remove-Item $tmpFile
    }
    Get-ChildItem -Recurse "$($shadowPath)\Windows\System32\Config" -Force -ErrorAction Continue | % { $_.FullName.Remove(0, $shadowPath.Length + 1) | Out-File -FilePath $tmpFile -Encoding ascii -Append }

    Get-ChildItem "$($shadowPath)\Users\" -Directory | % { Get-ChildItem -File -Force "$($_.FullName)\ntuser.*" -ErrorAction SilentlyContinue | % { $_.FullName.Remove(0, $shadowPath.Length + 1) | Out-File -FilePath $tmpFile -Encoding ascii -Append } }

    $archName = Get-Date -Format 'yyyyMMdd'

    # if file exists, using _1, _2, ...
    $archPath = $bakRoot + '\' + $archName;
    $iterator = 1;
    while (Test-Path "$archPath.7z")
    {
        $archPath = $bakRoot + '\' + $archName + '_' + $iterator;
        $iterator++;
    }

    $curPWD = $PWD
    cd $shadowPath
    cmd /c "$($curPWD)\7z.exe a -m0=LZMA2 $archPath.7z @$tmpFile"
    cd $curPWD
    Remove-Item $tmpFile
}

В данном скрипте мы собираем список файлов для архивирования во временный файл, и передаём его архиватору 7z, чтобы он уже самостоятельно проделал всю необходимую работу.

Дальше мы удаляем лишнюю копию:
Function DropShadow($shadowID)
{
    $dummy = cmd /c "rmdir .\$shadowID"
    Write-Host $dummy
    $currentShadow = gwmi Win32_ShadowCopy | ? { $_.ID -eq $shadowID }
    $currentShadow.Delete()
}

И лишние файлы:
Function RemoveOldBackups($bakPath)
{
    dir $bakPath | ? { $_.CreationTime -le $(Get-Date).AddDays(-30) } | Remove-Item
}

Скрипт целиком можно взять тут: backup-registry.7z (вместе с 7zip). В скрипте надо будет поправить необходимые пути и настроить его на периодическое выполнение, например, раз в день (что мелочиться-то?).

Также, можете его изменить чтобы архивировать не только данные файлы, но и другие, или придумать ещё более оригинальный способ использования. Можете оставлять комментарии с идеями.