Любому бэкапированию препятствует мусор – информация, не требующая резервного копирования, которая, однако, подмешивается в основной массив данных, увеличивая время создания и итоговый размер резервного файла. Первое правило отделения мух от котлет – не разводить на жестком диске коммунальную квартиру. Как минимум ОС должна жить на отдельном логическом диске, а в идеале каждому типу данных должен быть выделен свой раздел или, на худой конец, папка. Это очень упрощает процесс настройки бэкапов. Классический «мусор» системного диска – файл 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\ SYSTEM\MountedDevices». В результате при первой загрузке восстановленного из бэкапа образа буквы накопителей расставятся по умолчанию и система гарантировано загрузится. Правда, придется вручную переназначить буквы всем логическим дискам и флэшкам вашего компьютера, но ради легкого «воскрешения» системы с этим можно смириться. Чтобы буквы не «летели» каждый раз после снятия образа вашей рабочей системы, достаточно упомянутую ветку реестра перед очисткой сохранять, а по завершении бэкапирования – восстанавливать.
Пофайловый бэкап, то есть бэкап файлов и папок, производимый на уровне файловой системы, гораздо более актуален, чем создание посекторного образа системы. Действительно, с потерей настроенной Windows еще можно смириться, потратив несколько вечеров на установку и обкатку системы с нуля, а вот с потерей всей накопленной за много лет информации или большого проекта, до сдачи которого остался день-другой – едва ли. Случай, когда вся эта информация помещается на одну DVD-болванку, тривиален и не интересен, – такой объем достаточно куда-нибудь регулярно копировать. Гораздо интереснее (и жизненнее) обезопасить гигабайт 200—300 динамично изменяющихся данных, причем сделать это, придерживаясь концепции максимального удобства пользователя и автоматизации процесса. Только если пользователь вообще не должен будет о них вспоминать, бэкапы будут происходить регулярно. Задача становится еще интереснее, если мы захотим создать систему очень динамичных (например, ежедневных) бэкапов с многоступенчатым откатом, который позволил бы хранить не только текущую копию исходных данных, но и предыдущие их варианты, так далеко назад во времени, как только позволяет емкость бэкапного жесткого диска. Для такой задачи простым копированием не обойдешься, поскольку даже на самый большой современный диск, объемом в терабайт, трехсотгигабайтный массив можно скопировать всего три раза.