ОПЫТЫ: Параноидальный бэкап

ОПЫТЫ: Параноидальный бэкап

Автор: Филипп Казаков

В прошлом номере мы начали рассматривать вопросы посекторного резервного копирования жесткого диска и остановились на том, что идеальных программных средств не бывает. Продолжим.

При создании посекторных образов системы, вне зависимости от используемого софта, есть тонкости, на которые следует обратить внимание.

Любому бэкапированию препятствует мусор – информация, не требующая резервного копирования, которая, однако, подмешивается в основной массив данных, увеличивая время создания и итоговый размер резервного файла. Первое правило отделения мух от котлет – не разводить на жестком диске коммунальную квартиру. Как минимум ОС должна жить на отдельном логическом диске, а в идеале каждому типу данных должен быть выделен свой раздел или, на худой конец, папка. Это очень упрощает процесс настройки бэкапов. Классический «мусор» системного диска – файл hiberfil sys, предназначенный для хранения содержимого оперативной памяти во время спящего режима, файл подкачки pagefile sys, кэш браузера и игры. Hiberfil sys и pagefile sys имеют сиюминутное значение, но в дефолтной конфигурации системы занимают объем в 2,5 раза больший объема оперативной памяти. С hiberfil sys, к сожалению, ничего не сделаешь – его местонахождение жестко определено ядром системы и перенести его невозможно. Единственный выход – перед созданием бэкапа вручную отключать «Спящий режим», а затем включать снова. Файл подкачки можно штатными средствами Windows разделить на два: на системном диске оставить небольшой файл с жестко ограниченным объемом, а дополнительный pagefile sys создать на другом логическом или физическом диске (второе, кстати, еще и полезно для повышения общей производительности системы), например на том же бэкапном. Туда же заодно можно перенести и кэш браузера. Что же касается игр, крайне охочих до дискового пространства, но не требующих увековечивания, то существует элегантный способ отделить их от системного диска. Достаточно создать «игровой» логический раздел и подмонтировать его в качестве какой-нибудь папки, например C:Games, штатными средствами «Управления компьютером». Логически эта папка ничем не будет отличаться от любой другой, а «лишний» раздел не займет дефицитной буквы. В результате посекторные бэкапы системного диска будут избавлены от тяжкого груза виртуальных реальностей, что благотворно скажется на их (бэкапов) объеме.

Кроме того, необходимо учесть одну тонкость в работе Windows. Это известная проблема с сигнатурами жестких дисков, возникающая при посекторном клонировании разделов [ Подробнее см. на forum ixbt com/topic cgi?id=22:22723], о решении которой не заботится ни DriveImage XML, ни Acronis True Image, ни большинство других программ. Корень зла в том, что Windows XP запоминает все подключавшиеся к ней когда-либо жесткие диски и ставит им в соответствие буквы алфавита или пути к папкам NTFS-разделов. При переносе системы на новый диск (или, применительно к бэкапной теме, потенциальном восстановлении бэкапа на новый жесткий диск, приобретенный взамен умершего) порой возникает ситуация, в которой «клонированная» Windows XP во время загрузки назначает новому системному диску букву, отличную от C (или той буквы, которой раньше соответствовал системный диск). В результате система впадает в ступор, так в какой-то момент понимает, что грузится «ниоткуда». Решение проблемы очень простое: перед созданием очередного бэкапа нужно заставить Windows XP при очередной загрузке переопределить все буквы заново. Достигается это удалением параметров ветки реестра «HKEY_LOCAL_MACHINE SYSTEMMountedDevices». В результате при первой загрузке восстановленного из бэкапа образа буквы накопителей расставятся по умолчанию и система гарантировано загрузится. Правда, придется вручную переназначить буквы всем логическим дискам и флэшкам вашего компьютера, но ради легкого «воскрешения» системы с этим можно смириться. Чтобы буквы не «летели» каждый раз после снятия образа вашей рабочей системы, достаточно упомянутую ветку реестра перед очисткой сохранять, а по завершении бэкапирования – восстанавливать.

nnBackup

Пофайловый бэкап, то есть бэкап файлов и папок, производимый на уровне файловой системы, гораздо более актуален, чем создание посекторного образа системы. Действительно, с потерей настроенной Windows еще можно смириться, потратив несколько вечеров на установку и обкатку системы с нуля, а вот с потерей всей накопленной за много лет информации или большого проекта, до сдачи которого остался день-другой – едва ли. Случай, когда вся эта информация помещается на одну DVD-болванку, тривиален и не интересен, – такой объем достаточно куда-нибудь регулярно копировать. Гораздо интереснее (и жизненнее) обезопасить гигабайт 200—300 динамично изменяющихся данных, причем сделать это, придерживаясь концепции максимального удобства пользователя и автоматизации процесса. Только если пользователь вообще не должен будет о них вспоминать, бэкапы будут происходить регулярно. Задача становится еще интереснее, если мы захотим создать систему очень динамичных (например, ежедневных) бэкапов с многоступенчатым откатом, который позволил бы хранить не только текущую копию исходных данных, но и предыдущие их варианты, так далеко назад во времени, как только позволяет емкость бэкапного жесткого диска. Для такой задачи простым копированием не обойдешься, поскольку даже на самый большой современный диск, объемом в терабайт, трехсотгигабайтный массив можно скопировать всего три раза.

Определив сверхзадачу, давайте формализуем пожелания. Итак, пофайловые бэкапы должны:

• происходить из рабочей операционной системы;

• не требовать внимания пользователя, но при этом быть для него прозрачными;

• быть инкрементными – заново копироваться должны только изменившиеся с прошлого бэкапа данные;

• быть устойчивы к человеческому фактору, чтобы в случае чего был доступ не только к копии текущего состояния винчестера, но и к файлу, случайно удаленному две недели тому назад;

• происходить со скоростью, близкой к максимально возможной скорости работы дисковой подсистемы компьютера;

• просто и наглядно отделять «мусор» от открытых для бэкапирования данных;

• поддерживать достаточно глубокую вложенность директорий и кодировку unicode в именах файлов.

Как видите, перечисленные требования вполне реализуемы несколькими банальными, всем знакомыми операциями с файловой системой: скопировать, переместить, удалить да запланировать все это в определенной последовательности. Казалось бы, гораздо более простая задача, чем посекторное копирование разделов, но – удивительно! – я не нашел ни единой высокоуровневой программы с графическим интерфейсом, которая могла бы достойно выполнить эти пожелания. Роскошные навороченные платные комплексы, бесплатные «поделки на коленке» – все они пасовали в лучшем случае на трех из перечисленных пунктов. На помощь пришла отечественная разработка – консольная утилита nnBackup. Это гениальная программа, при весе всего в 350 килобайт позволяющая организовать пофайловые бэкапы практически любой сложности. Можно просто регулярно копировать информацию; можно создавать «дампы» только изменившихся данных или синхронизировать две папки; можно работать не только с реальными файлами, но и с текстовым «слепком» файловой системы; можно запланировать расфасовку сделанного бэкапа по директориям заданного объема, чтобы каждая из них поместилась на CD или DVD с сохранением оригинальной структуры вложенных директорий. Есть еще с десяток разных функций, комбинируя которые можно достичь практически любого результата. Программа ведет скрупулезный лог своих действий, в результате чего локализация любой возникшей проблемы не вызывает никаких трудностей. Большая часть действий утилиты сводится к операциям копирования, которые производятся операционной системой, а не каким-то там подозрительным драйвером, за счет чего скорость бэкапирования вплотную приближается к скорости обыкновенного копирования вашего компьютера.

Увы и ах, как и за все другое, за отличную функциональность приходится платить. Но в данном случае не деньгами, так как утилита бесплатна для русскоязычного населения, а временем и мозговыми ресурсами. Общение с программой происходит только через командную строку, так что даже несмотря на превосходную русскоязычную справку, настройка требует изрядного напряжения серого вещества. Для облегчения этого процесса предлагаю вам ознакомить с моей конфигурацией бэкапа динамично меняющегося рабочего раздела, а при настройке своей системы отталкиваться уже от нее.

С целью упрощения процесса создания сценария бэкапа, исполняемый файл nnbackup exe можно попросить брать команды не из командной строки, а из текстового файла, который очень удобно комментировать. Вот, к примеру, создадим в папке nnBackup файл config cfg. Строчки, обозначенные обратным слэшем, – комментарии, а все остальные – команды (см. врезку).

Синхронизировать приемный каталог с

исходным. В этом случае из исходного

каталога в приемный копируется вся

информация, которой там еще нет:

sync

Исходный каталог:

– i W:

И приемный каталог:

– o «X:w"

Учитывать все подкаталоги при копировании:

– s

Сравнивать при синхронизации не только

время последней модификации файла, но и

время его создания:

– tc

Сравнивать при синхронизации еще и размер

файла, а также бэкапить файлы, даже если

дата их модификации в исходном каталоге

изменилась в обратную сторону:

– ad

Удалять в приемном каталоге файлы,

отсутствующие в исходном каталоге:

– da

Этот ключ определяет поведение программы

в случае, если какой-то каталог был удален в

исходном каталоге, но все еще содержится в

резервной копии:

– nd

Исключать из бэкапа все файлы и

директории, имя которых заканчивается

на.@exc:

– x *.@exc

Оставлять копию всей информации, которая

меняется или удаляется в приемном каталоге.

При этом помещать измененные файлы в

специальный каталог «W_dumps», создавая

каждый раз подкаталог с именем в виде

текущей даты:

– backup X:W_dumps\%YYYY%-%MM%-%DD%

Если теперь запустить nnbackup exe с ключом – f config cfg, он прочтет содержимое конфигурационного файла. Весь диск W: будет скопирован в папку X:w на бэкапном HDD. Помните пункт о наглядном отделении «мусора» от требующих резервного копирования данных? Все папки и файлы, оканчивающиеся на».@exc», будут проигнорированы. Таким образом, чтобы запретить бэкап, предположим, захваченного только что с ТВ-тюнера сериала, достаточно к названию папки с захватами добавить».@exc», например, так: «W:captures.@exc". Сразу видно, что это папка-неудачница! Конечно, такое замысловатое буквосочетание я придумал сам, встретить подобную «символьную тусовку» в реальной жизни почти невероятно. Вы можете придумать любое свое обозначение.

Итак, при первом запуске содержимое диска W: за оговоренным исключением скопируется в X:w. В результате каждого повторного запуска скрипта содержимое исходного диска будет пофайлово сравниваться с копией, и если на бэкапируемом разделе что-то изменилось, копия будет приводиться в полное соответствие с оригиналом. Самое интересное в том, что всякое изменение, происходящее с бэкапом, не канет в лету, но будет аккуратно отражено в папке X:W_dumps, в которой вы всегда сможете найти удаленный невзначай файл. Временна, я глубина дампов прямо пропорциональна емкости бэкапного HDD и обратно пропорциональна интенсивности бэкапирования. С емкостью диска все понятно, а вот интенсивностью бэкапирования можно выгодно манипулировать. Для раздела с актуальными рабочими данными разумно запланировать ежедневный бэкап. В этом случае объем «дампнутых» данных растет быстро, однако вы будете наилучшим образом защищены от потерь насущной работы.

Долговременные хранилища, напротив, выгодно бэкапить пореже. Информация в них меняется медленно, зато эти данные наиболее ценны и хранить их желательно как можно дольше.

Запланировать ежедневное выполнение сценария можно даже встроенными средствами Windows, однако у автора nnBackup имеется не менее мощная утилита-планировщик под названием nnCron, выполненная в аналогичной стилистике и дающая большую фору виндусовскому шедулеру. В последних версиях, кстати, эта утилита обрела графический интерфейс, так что с ее настройками, полагаю, вы без труда разберетесь.

Справедливости ради и стимулирования для отмечу несколько недостатков nnBackup. Во-первых, программа хоть и поддерживает опцию архивирования, из-за, видимо, лицензионных соображений эта функция ограничена использованием старых библиотек zip, не умеющих создавать на выходе файлы размером более 2 Гбайт. Во-вторых, хоть в последних версиях nnBackup заявлена поддержка файлов с юникодовыми именами, в действительности иногда возникают проблемы при работе с файлами, имеющими длинные русскоязычные имена (может быть, Acronis True Image на них же спотыкался?). В-третьих, конечно, программе не хватает простенького графического интерфейса, который мог бы здорово сэкономить время ее настройки.

Не забудьте про себя

Что еще можно придумать, чтобы обезопасить свои информационные богатства? Если в доме несколько компьютеров, можно организовать перекрестный или цепочный бэкап, чтобы каждый компьютер бэкапился на соседа. Это исключит возможность потери данных в результате редких случаев порчи всей «начинки» компьютера зараз. Дабы избежать природных катаклизмов и прочих «обстоятельств непреодолимой силы», можно организовать перекрестный бэкап через Интернет с компьютером какого-нибудь другого пара… единомышленника. Систему бэкапов можно улучшать и усложнять бесконечно. Важно, однако, в какой-то момент остановиться, потому что иначе можно прийти к мысли о бэкапе собственной головы. Вот только не будет ли поздно?..