Посекторное копирование жесткого диска. Копирование дисков: Посекторное копирование жёстких дисков HDD. Сильные стороны Paragon Drive Backup

Резервное копирование дисков – многофункциональная процедура. Не всегда есть необходимость копировать диск в логическом формате; в некоторых случаях необходимо только копирование файлов с повреждённого жёсткого диска, в других – резервное копирование системы на другой жёсткий диск.

Зачем может потребоваться копировать жёсткий диск?

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

Вы можете самостоятельно познакомиться с возможностями Handy Backup, в том числе копировать диск с помощью любого из её плагинов, скачав и установив прямо сейчас пробную версию программы со всем набором инструментов и функций на 30-дневный бесплатный период!

Видеоурок по резервному копированию жесткого диска и его восстановлению

В данном видео описано резервное копирование образа диска через плагин Disk Image и его восстановление с помощью Handy Backup Disaster Recovery. Интрефейс Handy Backup показан на английском языке (для русского шаги аналогичные). Интерфейс утилиты Handy Backup Disaster Recovery доступен только на английском языке!

Внимание: Данная видео-инструкция предполагает, что программа Handy Backup уже установлена на компьютер, а утилита Handy Backup Disaster Recovery - на USB-устройство. Если это не так, пожалуйста, скачайте и установите Handy Backup и Disaster Recovery перед началом работы, согласно видео-инструкции.

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

Если делать это вручную – заново устанавливать систему, программы и копировать пользовательские файлы, то можно потратить целый день.

Гораздо удобнее доверить это автоматике - специальным программам для клонирования жестких дисков. С их помощью все файлы, настройки и сама система просто “переедут на новое место жительства” в том виде, в каком они были на старом носителе.

Клонирование жесткого диска - это процедура низкоуровневого посекторного переноса данных с одного носителя на другой. При этом диск-клон будет представлять собой точную копию диска-оригинала.

Клонирование жесткого диска

Для создания дисков-клонов выпущено немало платных и бесплатных программ. Среди них есть универсальные, работающие с любыми HDD и SSD, и узкоспециализированные, предназначенные для дисков определенной марки, например, только Samsung или только Western Digital.

Рассмотрим пять популярных и наиболее простых в использовании программ для клонирования жестких дисков на SSD или HDD любого производителя.

EASEUS Disk Copy

Farstone RestoreIT Pro - прежде всего инструмент восстановления системы и пользовательских данных после сбоев, вирусных атак, изменений и случайного удаления.

Как таковые клоны дисков эта программа не создает, но может создавать бекапы любой информации на них.

Периодичность резервирования в RestoreIT Pro можно настроить хоть ежечасно. А восстановление к сохраненной копии производится нажатием одной кнопки.

Возможности RestoreIT Pro:

• способность восстанавливать систему даже после повреждения загрузчика;
• 2 режима резервирования - полное и накопительное (сохранение только измененных данных);
• мониторинг всего диска или только выбранных разделов;
• хранение всей истории изменений файлов, а не только последней сохраненной версии.

Недостатками программы является платная лицензия ($24.95) и отсутствие функции клонирования дисков.

Суть проблемы

Данная неисправность представляет собой повреждение произвольного количества секторов на винчестере до состояния, когда их чтение головками в штатном режиме работы жёсткого диска становится невозможным. Либо поверхность накопителя деградирует до состояния, когда чтение секторов возможно, но идёт крайне медленно, что не позволяет накопителю полноценно работать с операционной системой и пользовательскими данными. Нужно признать, что на каждом жёстком диске есть повреждённые сектора. При производстве дисков эти повреждённые сектора заносят в специальный заводской дефект-лист P-List (Primary list) и уже далее в процессе работы эти повреждённые сектора диск "не видит". Если в процессе эксплуатации появляются дополнительные bad-блоки, то диск сам заносит их в пользовательский дефект лист G-List (Grown list). Объём этого дефект-листа ограничен и если поверхность диска начинает деградировать, а количество повреждённых секторов превышает вместимость G-List"а, то диск перестаёт полноценно функционировать и bad-блоки повреждают пользовательские данные.

Причины возникновения bad-блоков:

• физический износ накопителя, вызванный длительной работой 24/7;
• различные механические воздействия на накопитель, удары, падения, вибрация;
• перегрев накопителя вследствие работы без охлаждения;
• брак при изготовлении накопителя на заводе производителя;
• некачественный блок питания, нестабильное напряжение в сети, отсутствие ИБП;
• некорректное отключение жёсткого диска от работающего компьютера;

Симптомы неисправности:

• диск определяется в BIOS, но операционная система виснет на этапе загрузке или выдаёт синий экран;
• отдельные файлы и папки перестают открываться или показываться в проводнике;
• при копировании файлов и папок выдаются сообщения о невозможности прочитать\записать файл;
• диск может издавать тихие "трыкающие" звуки при попытке прочитать файлы, содержащие bad-блоки;
• очень медленная работа системы с повреждённым диском;
• ненулевые параметры SMART: Reallocated Sector Count (количество переназначенных секторов) и Current Pending Sector Count (количество нестабильных секторов);

Влияние bad-блоков на файлы пользователя

Данная неисправность позволяет при использовании профессионального оборудования вычитать все пользовательские данные практически без потерь. На полноту восстановления данных при наличии повреждённых секторов на диске влияют такие факторы как количество bad-секторов и их расположение. Т.е. повреждённых секторов может быть 10шт. и они располагаются на секторах не содержащих пользовательских файлов, а может быть повреждённых секторов 100000шт. и все они попали например в бухгалтерскую базу 1C или в таблицу файлов MFT (Master File Table - «Главная файловая таблица»).

Методы и программы для тестирования жёсткого диска на наличие bad-блоков

Все существующие программные средства для тестирования жёстких дисков делятся на два типа: профессиональное оборудование для сервис центров и бесплатные программы доступные пользователям в интернете. Профессиональные средства работы с жёсткими дисками обычно являются программно-аппаратными комплесами, состоящими из непосредственно программной части и аппаратной платы криптозащиты с дополнительными независимыми от операционной системы SATA портами, реле управления питанием HDD и COM-терминалом с различными переходниками для разных моделей винчестеров. Возможности по тестированию HDD у программно-аппаратных комплексов значительно превосходят возможности в бесплатном програмном обеспечении. Стоимость одного программно-аппаратного комплекса может доходить до 3000$. Бесплатные программы не предназначены для ремонта, но подходят для полноценного тестирования HDD на наличие повреждённых секторов.

Профессиональные программно-аппаратные комплексы: PC3000 Data Extractor, HDD Repair Tool.

Бесплатные программы для тестирования жёстких дисков: MHDD, Victoria API, HDD Scan.

Ниже представлен пример результатов тестирования жёсткого диска IBM на программно-аппаратном комплексе HDD Repair Tool. Как видно из рисунка, данное профессиональное оборудование позволяет не только определить количество и номера LBA повреждённых секторов, но и позволяет в графическом режиме показать точное расположение и распределение bad-блоков по всем пластинам жёсткого диска. На скриншоте повреждённые сектора на разных поверхностях и головках h0, h1, h2 ,h3 отмечены разныи цветами. Это даёт чёткое визуальное восприятие распределения повреждений по пластинам HDD.
На рисунке ниже показан скриншот из программы Vactoria при тестировании диска содержащего повреждённые сектора, которые отмечены крестиками. Цветные клетки это сектора с низкой скоростью чтения, которые вскоре полностью перестанут читаться и превратятся в bad-блоки.

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

Существуют два основных метода копирования данных с дисков, повреждённых bad-секторами. В простых случаях, когда файловая таблица MFT не повреждена и её удаётся вычитать, то далее строится виртуальная карта занятых пользовательскими данными секторов на диске и копируются только сектора содержащие информацию, а пустые сектора не копируются. Это значительно ускоряет процесс копирования и снижает вероятность увеличения повреждений диска в ходе создания посекторного образа. В случаях, когда файловая таблица MFT повреждена и расположение файлов и папок на диске неизвестно, приходится делать полную посекторную копию всего диска, а уже после её завершения восстанавливать логическую структуру файловой системы на диске, куда была сделана посекторная копия. Любой метод восстановления данных при наличии повреждённых секторов на диске сводится к созданию посекторной копии повреждённого диска. Этот процесс всегда проходит в режиме "read only" (только чтение). Производить запись на повреждённый диск или подключать его к операционной системе крайне не рекомендуется, т.к. такой диск при попытке записать информацию может увеличить количество сбойных секторов и, как следствие, битых файлов. На многих моделях жёстких дисков имеется возможность вычитать данные из повреждённых секторов с помощью активной утилиты входящей в состав программно-аппаратного комплекса PC3000 DataExtractor. Активная утилита позволяет с помощью подачи в накопитель специальной команды ввести диск в технологический режим, после чего скорость чтения диска падает в разы, но при этом он начинает читать данные из повреждённых секторов. Общий же алгоритм сводится к тому, что бы сначала вычитать в режиме UDMA на высокой скорости все неповреждённые сектора, а затем перевести диск в технологический режим и вычитать на медленной скорости данные из повреждённых секторов.

Примеры повреждённых файлов в которых содержатся bad-блоки

На картинке выше представлена фотография содержащая bad-блок. Как мы видим, наличие даже одного повреждённого сектора в файле фатально влияет на качество фотографии. Появляются визуальные артефакты, изменения цветов и сдвиги изображения. После вычитывания данного файла с помощью активной утилиты входящей в состав комплекса PC3000 Data Extractor повреждений в файле уже не наблюдается, т.к. в технологическом режиме диск читает очень медленно, но без сбоев.

Буквально недавно на одном из компьютеров на моей работе был заменен жесткий диск. Почти сразу после замены Windows XP стал по несколько раз в день сваливаться в BSOD и ругаться ошибками Драйвер обнаружил ошибку контроллера \Device\Harddisk0\.

Изначально я грешил на то, что установлен стандартный драйвер IDE контроллера (в BIOS материнской платы для SATA-контроллера поставлен режим IDE compatible), хотя материнская плата на чипе VIA — драйвер поменял, однако проблемы это не решило. Так же пробовал менять SATA-шлейф — тоже не помогло.

Тип события: Ошибка
Источник события: Disk

Код события: 11
Дата: 10.03.2011
Время: 16:22:36
Пользователь: Н/Д
Компьютер: MPS-F01EC7424DE
Описание:
Драйвер обнаружил ошибку контроллера \Device\Harddisk0\D.

Тип события: Ошибка
Источник события: atapi
Категория события: Отсутствует
Код события: 5
Дата: 10.03.2011
Время: 16:22:36
Пользователь: Н/Д
Компьютер: MPS-F01EC7424DE
Описание:
Обнаружена ошибка нарушения четности на \Device\Ide\IdePort0.

Стало понятно, что проблема в том, что сам диск оказался бракованным. Решил его заменить. Но, так как на данном компьютере установлено довольно много специфичного ПО (бухгалтерия 😉), то было решено снимать образ и заливать его на новый диск.

Сказано — сделано! Скачал сборку BartPE под названием NervOS — там есть Acronis, Ghost и целая куча других утилит. Подцепил второй HDD, загрузился с CD, запустил копирования Disk-to-Disk с помощью Ghost и приготовился ждать. Но не тут-то было! Где-то на 2% Ghost заявил, что не может прочитать поврежденные сектора и вырубился. Так же, диск отвалился из Windows PE и снова появился только после перезагрузки.

Решил попробовать Acronis — тот же результат. Думал проверить диск родной утилитой от WD — «Too many bad sectors. FAIL». А образ снимать надо!

После небольшой консультации с коллегой-сисадмином-линуксоидом было решено сливать образ с помощью Ubuntu:

2. Там же смотрим инструкцию как записать образ на CD или на USB. Я записывал на USB с помощью Universal USB Installer

3. Грузимся с USB при двух подключенных hdd — старом и новом

4. Запускаем Ubuntu с USB

5. Запускаем Terminal

6. Переходим в режим суперпользователя — sudo su

7. Используем команду fdisk -l для того чтобы увидеть «имена» жестких дисков, в моем случае: /dev/sdb — старый, поврежденный диск, /dev/sda — новый

8. Теперь приступаем собственно к переносу образа с диска на диск:

dd if=/dev/sdb of=/dev/sda bs=4096 conv=noerror

где if — источник, of — назначение

conv=noerror — dd будет пропускать сектора с ошибками

полное описание параметров dd можно посмотреть, выполнив man dd

Процесс пошел. У меня процесс занял около 1 часа — диск 160 Gb при 20% заполнении.

9. После того как процесс завершится, надо не забыть перенести MBR :

dd if=/dev/sdb of=MBR-backup bs=512 count=1 — со старого диска в бекап

dd if=MBR-backup of=/dev/sda bs=512 count=1 — из бекапа на новый диск

Вот и все, образ успешно перенесен! Отключаем флешку, старый диск и успешно загружаемся с нового!

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

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

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

Любому бэкапированию препятствует мусор - информация, не требующая резервного копирования, которая, однако, подмешивается в основной массив данных, увеличивая время создания и итоговый размер резервного файла. Первое правило отделения мух от котлет - не разводить на жестком диске коммунальную квартиру. Как минимум ОС должна жить на отдельном логическом диске, а в идеале каждому типу данных должен быть выделен свой раздел или, на худой конец, папка. Это очень упрощает процесс настройки бэкапов. Классический "мусор" системного диска - файл 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". В результате при первой загрузке восстановленного из бэкапа образа буквы накопителей расставятся по умолчанию и система гарантировано загрузится. Правда, придется вручную переназначить буквы всем логическим дискам и флэшкам вашего компьютера, но ради легкого "воскрешения" системы с этим можно смириться. Чтобы буквы не "летели" каждый раз после снятия образа вашей рабочей системы, достаточно упомянутую ветку реестра перед очисткой сохранять, а по завершении бэкапирования - восстанавливать.

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 на них же спотыкался?). В-третьих, конечно, программе не хватает простенького графического интерфейса, который мог бы здорово сэкономить время ее настройки.

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

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