Сравнение способов резервного копирования. Резервное копирование в Windows

29.10.2012 Мишель Пуле

Резервное копирование баз данных является самым простым и дешевым средством обеспечения сохранности корпоративных данных. Не стоит доверять ложному чувству защищенности, возникающему после ввода в эксплуатацию новейшей системы высокой доступности. Если все данные виртуализованы и консолидированы, риски даже возрастают

Мишель Пуле ([email protected])-редактор журнала SQL Server Pro, соучредитель компаний Mount Vernon Data Systems и Six Sigma Uptime.

Большинство компаний, существующих на рынке достаточно давно, переживали катастрофические события, которые могли бы вывести их из игры, например сбой базы данных. Резервная копия базы данных представляет собой копию данных, структур и объектов безопасности, содержащихся в базе данных. Каждая база данных должна резервироваться по своему графику в зависимости от количества выполняемых за день транзакций записи. Для минимизации потерь при сбое базы данных необходимо выполнять резервное копирование всех баз данных, используемых на предприятии. А дабы убедиться, что резервные копии работоспособны, следует проверять их работу после операций восстановления. По меньшей мере, необходимо иметь копии баз данных, пригодные для быстрого восстановления, а сама операция восстановления должна быть отработана и не вызывать никаких трудностей.

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

Не стоит доверять ложному чувству защищенности, возникающему после ввода в эксплуатацию новейшей системы высокой доступности. Если все данные виртуализованы и консолидированы, риски даже возрастают. Как проста была жизнь, когда на одном компьютере выполнялся единственный экземпляр базы данных. Теперь обычно на сервере в виртуальных машинах исполняются десятки экземпляров SQL Server, которые, в случае отказа физического сервера, откажут все одновременно. Если средства позволяют, вы можете создать отказоустойчивый кластер хостов виртуальных машин на разных физических серверах. При необходимости высокой доступности так обычно и делают. Но даже такая отказоустойчивая система может оказаться уязвимой в случае, скажем, пожара, потопа или землетрясения. Резервные копии все равно необходимы. При этом создание резервных копий доверено ограниченному кругу лиц. Более подробно о том, кто имеет право создавать резервные копии, рассказано во врезке «Кто может выполнять резервирование?».

Частота резервирования базы данных зависит от того, как долго она будет восстанавливаться из резервной копии. Чем чаще выполняется резервирование базы данных, тем меньше времени займет восстановление. График резервирования и восстановления можно настроить индивидуально для каждой базы данных. Тип резервирования зависит еще от объема базы данных и количества транзакций, выполняемых за единицу времени. Основными типами резервирования являются полное, журнальное и инкрементальное. Более подробные сведения о режимах восстановления приведены во врезке «Модели восстановления баз данных», команды по резервированию SQL Server описаны во врезке «Стандартные команды для резервирования».

Полное резервирование

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

Больше всего полное резервирование подходит для «небольших» баз данных – назовем так базы данных, резервирование которых может быть завершено за отведенное для этого время. Когда SQL Server осуществляет полное резервирование базы данных, сначала выполняется сохранение на диск всех экстентов (экстент представляет собой восемь идущих последовательно страниц, размер каждой составляет 8 Кбайт). Затем SQL Server резервирует журнал транзакций, чтобы все изменения базы данных, которые могли произойти за время резервирования, также были сохранены в файле полной резервной копии.

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

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

Для выполнения полного резервирования базы данных выполните следующий код:

BACKUP DATABASE AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak’WITH INIT, NAME = ‘AdventureWorks Full Db backup’, DESCRIPTION = ‘AdventureWorks Full Database Backup

Параметр DISK определяет целевой файл резервной копии. Вы можете выполнять резервирование на диск или на ленту (в данном случае – на диск). Перед началом резервирования убедитесь, что папка для хранения резервной копии существует. В большинстве случаев резервирование на диск происходит значительно быстрее, чем на ленту, но стоимость дисковой памяти существенно выше. Для обеспечения дополнительного уровня защиты можно выполнять резервирование на диск, а затем сохранять резервную копию на ленту. Параметр WITH INIT указывает, что файл резервной копии должен быть перезаписан. Этот метод подходит в том случае, если резервирование Windows выполняется после каждого резервирования базы данных. NAME – имя резервной копии, до 128 символов. Если имя не указать, поле имени останется пустым. DESCRIPTION – более полное и подробное описание, которое может помочь, например, через длительный промежуток времени выяснить, что это за резервная копия и зачем она была создана.

Для полного восстановления базы данных выполните следующую команду:

RESTORE DATABASE AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.BAK’ WITH RECOVERY, REPLACE

WITH RECOVERY предписывает SQL Server отменить все незавершенные транзакции, которые могли быть в журнале транзакций, и оставить базу в рабочем состоянии. REPLACE означает перезапись любого существующего файла с тем же именем. Более подробно об этом рассказано во врезке «Замена базы данных».

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

BACKUP LOG AdventureWorks WITH TRUNCATE_ONLY

Если указана установка TRUNCATE_ONLY, то резервирование журнала в действительности не выполняется, это указание SQL Server создать контрольную точку, очистить неактивные элементы и уменьшить размер файла журнала. В последующих версиях SQL Server эта установка исключена, но вместо нее можно использовать режим простого восстановления, чтобы позволить SQL Server автоматически очистить журнал транзакций от неактивных элементов.

Полное резервирование с сохранением журнала

Если недопустима любая потеря данных при восстановлении, можно воспользоваться стратегией полного резервирования с добавлением журнала. Этот метод позволит предотвратить потерю данных; он подходит для часто обновляемых баз данных. Хотя эта стратегия увеличивает сложность операций и сопровождения, общие затраты времени на резервирование базы данных сокращаются.

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

Если не указано обратное, после завершения резервирования журнала неактивные записи в нем «удаляются» (в действительности они помечаются для перезаписи). При запуске команды BACKUP LOG вы можете добавить параметры NO_TRUNCATE или COPY_ONLY, чтобы при резервировании записи в журнале не изменялись. Но мы не рекомендуем использовать эти параметры, если только вы не знаете наверняка, для чего это может понадобиться.

SQL Server 2005 имеется режим резервирования копии заключительного фрагмента журнала (tail-log backup), то есть резервирование после краха базы данных в том случае, если журнал транзакций не был испорчен. В этом режиме осуществляется резервирование последних транзакций, выполненных с момента последнего резервирования журнала. Более подробно об этом режиме рассказано во врезке «Что такое резервные копии заключительного фрагмента журнала».

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

Если в базе данных массовые обновления носят регулярный характер, возможно, имеет смысл использовать модель восстановления с неполным протоколированием (bulk logged recovery). Поскольку отдельные записи, включенные в массовую операцию в этом случае не журналируются, этот подход сокращает накладные расходы на ведение журнала SQL Server. Хотя вы можете получить заметное увеличение производительности при выполнении массовых операций, вы рискуете потерять данные при восстановлении, если исходные данные для повторного выполнения массовых операций окажутся в момент восстановления недоступны. При применении простой модели восстановления резервирование журнала также невозможно, так как в этом случае происходит обрезание журнала до контрольной точки.

Для выполнения полного резервирования с журналом необходимо сперва выполнить резервирование всей базы данных, как в приведенном ниже примере:

BACKUP DATABASE AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak’ WITH INIT, NAME = ‘AdventureWorks Full Db backup’, DESCRIPTION = ‘AdventureWorks Full Database Backup’

А затем следует выполнить резервирование журнала с помощью команды:

BACKUP LOG AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak’ WITH NOINIT, NAME = ‘AdventureWorks Translog backup’, DESCRIPTION = ‘AdventureWorks Transaction Log Backup’, NOFORMAT

Параметр WITH NOINIT в последней команде указывает, что файл резервной копии должен быть записан в режиме добавления (append) на существующий носитель, диск или ленту. В этом случае все резервные копии журнала транзакций будут дописаны в один и тот же файл один за другим подряд. NOFORMAT предписывает процессу резервирования сохранить всю заголовочную информацию, которая может содержаться на резервных дисках в заголовках. Этот способ принят по умолчанию, и явное указание данной установки является необязательным, но оно полезно в качестве самодокументирования операции.

Для восстановления с полной резервной копии или полной копии с сохранением журнала выполните следующие шаги.

1. Если база данных в состоянии онлайн, ограничьте доступ к ней, переключив режим доступа (в окне свойств) на RESTRICTED_USER. Таким образом доступ к базе данных будет разрешен только членам группы базы данных db_owner и членам групп сервера dbcreator и sysadmin.
2. Исправьте ошибку, вызвавшую крушение базы данных.
3. Если возможно, примените все сохраненные в резервных копиях журналы транзакций с параметром NORECOVERY.

Для выполнения резервирования заключительного фрагмента журнала запустите команду:

BACKUP LOG AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_TaillogBkup.bak’ WITH NORECOVER

Для полного восстановления из полной резервной копии необходимо сначала восстановить файлы базы данных с помощью команды:

RESTORE DATABASE AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak’ WITH NORECOVERY

Параметр NORECOVERY сообщает SQL Server, что частичные транзакции должны быть оставлены как есть, не нужно пытаться отменить их. При последующем восстановлении журналов транзакций будут восстановлены данные, позволяющие завершить эти частичные транзакции. При использовании параметра NORECOVERY база данных остается в нерабочем состоянии. Сразу за полным восстановлением должны быть восстановлены все резервные копии журналов транзакций с параметром NORECOVERY, как показано ниже:

RESTORE LOG AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak’ WITH NORECOVERY

Наконец, выполните восстановление заключительного фрагмента с параметром RECOVERY:

RESTORE LOG AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_TaillogBkup.bak’ WITH RECOVERY

Стратегия полного восстановления с восстановлением журналов не является абсолютной защитой. Если одна из резервных копий журналов окажется повреждена, то восстановление будет возможно только до точки, предшествующей поврежденному журналу. Например, предположим, что по воскресеньям выполняется еженедельное полное резервирование, а резервирование журналов – с понедельника по субботу. Если повреждена резервная копия вторника, то восстановлены могут быть только данные понедельника: риск повреждения целостности данных в результате применения транзакций среды к данным понедельника вряд ли оправдан. И восстановление заключительного фрагмента тоже ничего не даст.

Полное плюс разностное резервирование

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

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

Рисунок 3. Расписание заданий на разностное резервирование

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

BACKUP DATABASE AdventureWorks TO DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_DiffDbBkup.bak’ WITH INIT, DIFFERENTIAL, NAME = ‘AdventureWorks Diff Db backup’, DESCRIPTION = ‘AdventureWorks Differential Database Backup’

Чтобы восстановить базу данных из разностной резервной копии, выполните следующие шаги.

1. Если база данных в состоянии онлайн, ограничьте к ней доступ, переключив режим доступа (в окне свойств) на RESTRICTED_USER. Тем самым доступ к базе данных будет разрешен только членам группы базы данных db_owner и членам групп сервера dbcreator и sysadmin.
2. Выполните резервирование заключительного фрагмента журнала.
3. Исправьте ошибку, вызвавшую сбой базы данных.
4. Выполните восстановление полной резервной копии с параметром NORECOVERY.
5. Выполните восстановление последней имеющейся разностной резервной копии с параметром NORECOVERY.
6. Выполните восстановление резервной копии заключительного фрагмента журнала с параметром RECOVERY.

Для восстановления разностной резервной копии (выполняется после восстановления полной копии) введите команду:

RESTORE DATABASE AdventureWorks FROM DISK = ‘E:\SQLdata\BACKUPS\AdventureWorks_DiffDbBkup.bak’WITH NORECOVERY

Затем восстановите заключительный фрагмент журнала с параметром RECOVERY, с помощью приведенной ранее команды.

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

Комбинирование стратегией

Если повторное выполнение транзакций для восстановления операций последнего дня представляется нецелесообразным, вы можете выполнять полное резервирование в воскресенье, разностное резервирование каждую последующую ночь и резервирование журналов транзакций по утрам и вечерам с понедельника по субботу, как показано на рисунке 4. Если в пятницу вечером с базой данных случится беда, а разностная резервная копия четверга окажется поврежденной, можно будет выполнить восстановление по разностной копии среды, а затем применить журналы четверга и пятницы. Таким образом база данных будет восстановлена до самого момента отказа. Более подробно этот вопрос рассматривается во врезке «Как восстановить базу данных по состоянию на заданный момент времени».

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

Альтернативные стратегии резервирования

Резервирование в SQL Server не сводится только к полному, разностному и журналу транзакций. Более сложные стратегии, включающие резервирование файлов или групп файлов, стратегию частичного резервирования и резервирование только путем копирования.

Доступ к базе данных во время выполнения резервирования и восстановления

Резервирование базы SQL Server является онлайн-процессом, все хранящиеся в SQL Server данные во время операции резервирования доступны. Операции изменения базы данных, предложения INSERT, UPDATE и DELETE доступны точно так же, как выборка данных (SELECT). Во время резервирования нельзя изменять структуру базы данных или файловую структуру – предложения ALTER DATABASE, ADD FILE или SHRINKFILE во время резервирования выполняться не могут. Если для базы данных включен режим автоматического запуска уменьшения файла базы данных (auto-shrink), возможен конфликт во время выполнения резервирования. Так, если в процессе выполнения резервирования запустится автоматическое уменьшение файла базы, то обе операции могут завершиться отказом. Та операция, которая стартует раньше, установит блокировку файла, а следующей операции придется ожидать снятия блокировки. Если первая операция снимет блокировку, то начнется выполнение второй. Если же произойдет тайм-аут блокировки первой операции, вторая операция завершится отказом. Такой подход может показаться неправильным с точки зрения исполнения второй операции, которая вынуждена ожидать отказа, и только после него выдаст отказ. Но если учесть, что работа второй операции зависит от успеха первой, если при выполнении первой операции произошел отказ, выполнение второй не имеет смысла. Для предотвращения такой проблемы следует отключать автоматическое уменьшение файла базы данных перед выполнением резервирования.

В большинстве случаев восстановление базы SQL Server является автономной операцией, во время которой доступ пользователей к базе невозможен. При использовании SQL Server 2005 Enterprise Edition с моделью полного восстановления частичное восстановление и восстановление неосновных групп файлов по умолчанию являются онлайн-операциями. Части базы данных, которые не должны восстанавливаться, например группы файлов с доступом только для записи, могут быть доступны пользователям на всем протяжении выполнения операции восстановления. Группы файлов для чтения/записи доступны, если они не были переведены в автономное состояние для восстановления. Эта возможность очень полезна для больших баз данных, работающих в режиме 24x7x365. Дополнительную информацию можно найти в документации SQL Server 2005 BOL, «Performing Online Restores» (http://msdn.microsoft.com/ru-ru/library/ms188671.aspx), а также во врезке «Почему восстановление базы данных не может выполняться онлайн».

Подведем итоги

Данные имеют огромное значение для бизнеса, так что обеспечение их сохранности является одной из важнейших задач. Резервирование данных играет в этом процессе основную роль. Первым шагом при обеспечении постоянного доступа к данным является создание системы регулярного резервирования и проверочного восстановления баз данных. При создании новой базы данных следует сразу же создавать сценарии для резервирования и восстановления. SQL Server предоставляет разнообразные возможности резервирования и восстановления, которые могут быть адаптированы для задач конкретной базы данных.

Кто может выполнять резервирование?

Резервирование баз данных доступно ограниченному кругу лиц. По умолчанию разрешение дается членам определенных групп системных администраторов серверов и ролям базы данных db_owner и db_backupoperator. При использовании устройств резервирования, дисков или лент необходимо обращать внимание на то, кто является владельцем и какие установлены разрешения. SQL Server должен иметь возможность чтения и записи на устройство. Если учетная запись, от имени которой работает SQL Server, не обладает правами доступа к устройству, вы узнаете об этом только в случае сбоя при выполнении операций резервирования или восстановления. Хранимая процедура sp_addumpdevice, выполняющая добавление записи об устройстве резервирования в системные таблицы, не выполняет проверку прав доступа на уровне файлов.

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

Модели восстановления баз данных

Настройка модели восстановления определяет, какая часть данных может быть восстановлена в случае краха базы данных. Для каждой базы данных можно установить собственную модель восстановления в зависимости от того, какую потерю данных вы готовы допустить. Чтобы установить модель восстановления базы данных с помощью SQL Server Management Studio (SSMS), щелкните правой кнопкой нужную базу данных, откройте окно свойств Properties, перейдите на страницу Options и выберите нужную модель резервирования из выпадающего списка.

Существует три типа моделей восстановления: полное, простое и с неполным журналированием (full, simple, и bulk-logged). Полная модель восстановления наиболее использует все возможности журнала транзакций и позволяет восстановить базу данных с высокой степенью точности на заданный момент времени. Все операции, такие как транзакции данных, структурные изменения базы данных, операционные инструкции типа завершения транзакции или отмена, большие объекты и массовые операции, сохраняются в журнале. Журнал транзакций пополняется до тех пор, пока не будет выполнено резервирование журнала транзакций.

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

Модель восстановления с неполным журналированием занимает промежуточное положение между «крайними» моделями полного и простого восстановления. Хотя название bulk-logged может навести на мысль о журналировании массовых операций, в действительности они сохраняются в журнале лишь частично. Во время массовых операций, которые часто заключаются в добавлении большого числа записей за короткий промежуток времени, SQL Server устанавливает на каждом затронутом обновлением экстенте базы данных битовый флажок, но на самом деле вставленные записи не добавляются в файл журнала. Во время последующего резервирования журнала транзакций SQL Server проверяет этот флажок и записывает в резервную копию журнала транзакций сами экстенты базы данных, которые были изменены массовой операцией в добавление к обычным записям о вставке и удалении. Таким образом, резервная копия журнала в модели восстановления с неполным журналированием содержит результаты выполнения массовых операций, а не действительно выполненные отдельные транзакции.

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

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

Стандартные команды для резервирования

В SQL Server 2005 и SQL Server 2000 имеются две команды для выполнения, в сущности, одного и того же действия – DUMP и BACKUP (то есть DUMP DATABASE или BACKUP DATABASE и DUMP LOG или BACKUP LOG). Команда DUMP сохранилась со времен SQL Server 6.5, когда резервирование базы данных означало просто копирование базы данных в состоянии на момент перед началом операции резервирования. При этом изменения в базе данных, которые могли произойти после начала резервирования, не попадали в резервную копию.

Начиная с версии 7 SQL Server может выполнять настоящее «динамическое» резервирование, а это означает, что изменения, внесенные после начала процесса резервирования, записываются в журнал транзакций и сохраняются в файле резервной копии. Таким образом, резервная копия представляет собой «снимок» базы данных на момент завершения операции резервирования. Команда DUMP сохраняется для обратной совместимости, но Microsoft не рекомендует ее использовать в новых разрабатываемых системах. Когда-нибудь эта команда будет исключена, и разработчикам придется избавиться от нее в тех фрагментах программного кода, где она еще используется.

Тем, кто всегда тщательно следил за резервированием баз данных SQL Server и стремился изучать нововведения SQL Server 2005, следует продолжать внимательно следить за резервными копиями: в SQL Server 2005 нет привычной команды DBCC REPAIR. «Заменой» для этой команды служит DROP DATABASE.

Замена базы данных

При восстановлении базы данных на новом сервере используйте параметр REPLACE, который отключает обычные проверки безопасности и позволяет перезаписывать существующие базы данных, даже если их имя отличается от имени восстанавливаемой базы. Например, предположим, что была сделана резервная копия базы данных D, расположенной на сервере A. Эта резервная копия должна быть восстановлена на сервере B. Сначала на сервере B следует создать пустую промежуточную базу, при этом имя и размер базы не имеют никакого значения. Далее, надо восстановить базу D с параметром REPLACE на сервере B поверх только что созданной промежуточной базы. Если же восстановление должно быть произведено обратно на сервер A, на прежнее место, параметр REPLACE указывать не требуется. По умолчанию операция восстановления базы данных выполняет встроенные проверки безопасности, например если в нормальной ситуации нельзя выполнить восстановление базы поверх другой существующей базы данных. Аналогично, запрещено восстановление базы данных, зарезервированной в режиме полного резервирования или резервирования с журналированием массовых операций, если отсутствует резервная копия заключительного фрагмента журнала.

Если требуется восстановить базу данных, для которой по тем или иным причинам не была сделана резервная копия заключительного фрагмента журнала (например, из-за испорченного файла резервирования журнала транзакций), то восстановление в режиме REPLACE может оказаться единственным способом успешного восстановления. Другой пример, когда параметр REPLACE необходим, - если резервную копию производственной базы данных требуется восстановить в среде тестирования и разработки. Даже когда имена базы данных в производственной среде и в среде разработки совпадают, с точки зрения SQL Server это различные базы данных.

Что такое резервные копии заключительного фрагмента журнала

Резервирование заключительного фрагмента журнала – новый режим резервирования в SQL Server 2005. В этом режиме в резервную копию дописываются записи журнала транзакций, которые добавлялись с момента последнего резервирования файла журнала. Когда вы пытаетесь восстановить базу данных на момент отказа, перед началом восстановления выполните резервирование заключительного фрагмента. Резервирование последнего не нужно делать в том случае, если вы собираетесь восстановить базу данных по состоянию на момент до последнего резервирования журнала транзакций, или переносите базу данных с одного экземпляра сервера на другой, либо перезаписываете базу данных. Возможна ситуация, когда журнал транзакций поврежден – в этом случае выполнить резервирование заключительного фрагмента невозможно, и восстановление придется выполнять без него.

Как восстановить базу данных по состоянию на заданный момент времени

Возможна ситуация, когда необходимо выполнить восстановление базы из-за ошибочно выполненного кода – например, кто-то по ошибке удалил таблицу в производственной базе данных или забыл указать оператор WHERE в предложении DELETE. В таких случаях требуется восстановить базу по состоянию до того момента, когда ошибочный код был выполнен.

Восстановление представляет собой комплекс операций, приводящих базу данных в согласованное состояние. Для восстановления базы до определенной точки во времени необходимо выполнить полное восстановление или восстановление с неполным журналированием. Модель простого восстановления приводит к отсечению журнала транзакций до контрольной точки без возможности повтора-отмены действия (redo-undo) и без возможности восстановления по состоянию на заданный момент времени.

Выполнение операций восстановления с последующим «повторением/отменой изменений» заключается в восстановлении данных в исходное состояние на определенный, заданный пользователем момент времени – по имени выполненной транзакции или по номеру последовательности в журнале. Модель восстановления с неполным журналированием характеризуется дополнительным ограничением: восстановление на определенный момент возможно только в том случае, если с момента предыдущего резервирования журнала не выполнялись массовые операции. Другими словами, для успешного восстановления на определенный момент времени необходимо, чтобы последовательность файлов резервных копий журналов была непрерывной.

Восстанавливаемые данные на определенный момент времени должны содержаться в резервной копии журнала транзакций. При восстановлении журнала вы можете восстановить транзакции, которые были выполнены до определенного момента времени, указав нужный момент с помощью оператора STOPAT, STOPATMARK или STOPBEFOREMARK.

При восстановлении базы данных по состоянию на некоторый момент времени выполните полное резервирование с установкой NORECOVERY, как показано ниже:

RESTORE DATABASE AdventureWorks FROM DISK = "E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak" WITH NORECOVERY

Затем примените все резервные копии журналов с установкой RECOVERY и указанием даты и времени требуемой точки во времени в каждом предложении RESTORE LOG:

RESTORE LOG AdventureWorks FROM DISK = "E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak" WITH RECOVERY, STOPAT = ‘ Dec 10, 2007 8:10 PM’

Резервирование файлов/групп файлов

Эта стратегия резервирования подходит только в том случае, если база данных состоит из нескольких файлов или групп файлов. Если размеры базы или требования к производительности делают полное резервирование базы данных невозможным и если необходимо быстрое восстановление в случае отказа, стоит принять во внимание стратегии резервирования файлов/групп файлов.
Эта стратегия может использоваться для SQL Server 2005 или SQL Server 2000, при этом при выполнении каждой операции требуется указать, какие файлы, группы файлов или комбинации будут резервироваться. При этом следует выполнить полное резервирование базы данных вскоре после создания, после чего выполнять регулярное резервирование файлов или групп файлов. Если для конкретной базы данных необходимо задействовать простую модель восстановления, все доступные для чтения/записи файлы и группы файлов должны резервироваться одновременно. Для минимизации потерь данных при восстановлении выбирайте модель полного восстановления или модель восстановления с неполным протоколированием, при этом необходимо включить в стратегию резервирование журнала транзакций.
Восстановление базы все равно означает ограничение доступа к базе данных, но на меньшее время, чем при полном восстановлении базы данных. Во время восстановления доступ ограничивается только к группам файлов, восстанавливаемым в данный момент.
В худшем случае, если требуется восстановление всей базы данных и вы используете модель полного восстановления, потребуются все резервные копии журналов транзакций с момента создания базы данных. Кроме того, если необходимо восстановление базы на определенный момент времени, потребуется полный набор резервных копий журналов транзакций.

Частичное восстановление

Эта стратегия, появившаяся в SQL Server 2005, предназначена для баз данных, в которых имеются множественные группы файлов только для чтения и которые используют простую модель восстановления. Поскольку базы данных этого типа в основном предназначены только для чтения, стратегии полного резервирования и полного восстановления являются избыточными. Впрочем, модель частичного резервирования может применяться к базам данных любого типа.

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

Перед тем, как настраивать частичное резервирование, необходимо осуществить тщательное планирование. При создании базы данных следует создать различные группы файлов, а при формировании таблиц – разместить их явным образом в соответствующих группах файлов. Так, таблицы каталогов базы данных в первичной группе файлов, таблицы только для чтения – в группах файлов только для чтения, а таблицы для чтения/записи – в группах файлов для чтения/записи.

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

Восстановление после частичного резервирования все равно подразумевает ограничение доступа к базе данных, но на меньший интервал времени, чем при полном восстановлении базы данных – и только для первичной группы файлов, групп для чтения/записи и групп только для чтения, которые были частью резервирования. Более подробную информацию можно найти в документации SQL Server 2005 Books Online «Частичные резервные копии» http://msdn.microsoft.com/ru-ru/library/ms191539.aspx.

Резервные копии состояния

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

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

Стратегию резервирования состояния нельзя использовать в качестве базы для разностного резервирования, так как при создании копии состояния не обновляется карта разностей (differential bitmap), используемая для определения, какие экстенты следует копировать, а какие оставить. В действительности, процедура разностного копирования не учитывает сделанные копии состояния, поэтому такие копии не могут участвовать в процессе разностного восстановления.

При резервировании журнала транзакций состояния базы данных журнал транзакций не обрезается, в отличие от обычного резервирования. Резервирование состояния также не оказывает влияния на цепочку журналов, которая используется для полного резервирования с журналом восстановления. Резервные копии состояния вообще не включаются в список резервных копий журналов при восстановлении. Более подробные сведения можно найти в документации SQL Server 2005 BOL «Резервные копии состояния» по адресу http://msdn.microsoft.com/ru-ru/library/ms191495.aspx.

Почему восстановление базы данных не может выполняться онлайн

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

Процесс восстановления обычно начинается с копирования данных, журналов и индексных страниц с резервного носителя на место файлов базы данных. Затем наступает черед фазы повторного исполнения – применения сохраненных в журнале транзакций к данным, сохраненным на момент резервирования базы; этот процесс часто называют «повторять изменения». Эти зафиксированные в журнале транзакции представляют собой изменения в базе данных, которые были выполнены после последнего резервирования базы перед сбоем. Сначала SQL Server копирует данные и структурные изменения в журнал транзакций, а затем выполняет эти изменения на реальной базе данных. Повторение изменений обеспечивает применение к базе данных изменений, которые были сделаны в журнале.

На этой стадии в базе данных обычно содержатся незавершенные транзакции, и база данных не может использоваться для доступа. Далее для SQL Server 2005 Standard Edition наступает фаза последней отмены, в ходе которой выполняется отмена всех незавершенных транзакций. После завершения этой фазы база данных полностью восстановлена и готова к работе. Редакция Enterprise Edition работает немного по другому – база данных готова к использованию сразу после повторения изменений, не дожидаясь фазы отмены незавершенных транзакций.

Доступ к файлам, группам файлов и страницам в процессе восстановления базы данных и фаз повторения изменений/отмены незавершенных транзакций запрещен потому, что данные, которые могли бы быть получены, являются недостоверными. Попытка обработки «грязных» данных может вызвать проблемы, связанные с пропущенными и незавершенными транзакциями.

Недавно моя подруга попросила объяснить ей, как делать резервное копирование данных. Она гуманитарий, поэтому ей нужны были варианты, в которых ничего настраивать не нужно. Так как она - человек не глупый, который любит сам разбираться в проблеме и принимать решение, я решила собрать для нее основные принципы и описать плюсы и минусы тех или иных вариантов (как я их вижу). Опубликовать здесь я решилась на тот случай, что кому-то из вас пригодится – помочь другу или родственнику. Буду очень рада комментариям о том, как можно было бы сделать текст проще и понятнее.

Основные принципы

1. Регулярность и частота

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

Раздельность

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

Перепроверка

Как только сделана первая резервная копия данных, необходимо сразу проверить, что из нее эти данные можно восстановить! Это означает не только то, что файлы становятся видны. Нужно открыть несколько файлов на выбор и проверить, что они не испорчены. Желательно такую проверку потом повторять раз в какой-то период (скажем, раз в год).

Различение

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

Зачастую программы резервного копирования делают так называемые «образы» (image). Они выглядят как один единственный файл. Так вот в каждый такой образ лучше сохранять различные данные.

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

Резервное копирование данных

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

Резервное копирование системы

Речь идет об операционной системе со всеми ее настройками. Такой backup избавляет от необходимости устанавливать операционную систему заново, делать все настройки, устанавливать программы. Однако, это не самый из необходимых типов резервного копирование.

Куда делать backup

1. Внешний жесткий диск. Часто можно купить прямо в коробке. Бывают ноутбучные - такие диски маленькие по размеру, но более дорогие. Обычные жесткие диски можно сравнительно дешево купить объемом в 2 Тб - тогда за место на диске долго не придётся беспокоиться.

Достаточно надежный (если не ронять и не трясти чрезмерно)
+ Относительно недорогой

Необходимо самому не забывать подключать диск для бэкапа
-Не очень удобно переносить (не относится к ноутбучным дискам)

2. USB-stick - подойдет как дополнительное средство, когда данные хотелось бы переносить с одного компьютера на другой и/или иметь под рукой. Так же если сами данные не хочется хранить на компьютере.
Есть одно большое но - у флешки ограничено число записей, так что если на ней хранить данные приложения, которое будет интенсивно записывать, то флешка (usb stick) довольно быстро прикажет долго жить. К тому же, по моему личному впечатлению, они достаточно часто ломаются. Мой знакомый, покупая самые дорогие флешки, которые позиционировались как «не убиваемые», получал сломанную флешку за месяц-другой. Справедливости ради, надо сказать что у меня до сих пор ни одна флешка не сломалась, некоторые работают уже лет 5. Тем не менее, только на одном только usb-stick`e я бы хранить данные не стала.

Мобильное хранение
+Занимает мало места
+Очень дешево

Непредсказуемая надежность

3. Хранение данных на удаленном сервере (или в облаке).

Есть свои плюсы и минусы:

Данные будут доступны не только дома, но и на работе, во время путешествий.
+Локационная раздельность основных данных и резервных копий (например, если случается, не дай бог, пожар данные выживают)
+Нет нужды подключать жесткий диск для бэкапа, как правило, все делается полностью автоматически.

Желательно шифровать данные, так как неизвестно кто к ним может получить доступ
-Тратится большой объем трафика (если он ограничен, то возникают проблемы)
-Зачастую бесплатно можно хранить только данные до 2 Гб. Так что, такой backup - это дополнительная статья расходов

Список с хорошим описанием сервисов можно найти

Чем делать backup

Приведу список приложений, на которые стоит обратить внимание (по моему мнению), при резервном копировании на жесткий диск.

Из бесплатных пользуются популярностью

1. Genie Backup Manager - очень удобная программа, но немного тормозит при работе
2. Handy Backup - простой интерфейс, работает быстро.

Дополнительно

Часто в настройках программ по backup есть опция - сделать инкрементальный или дифференциальный backup. Практическое различие довольно простое. При дифференциальном резервном копировании можно сэкономить на месте которое он занимает. Зато есть только две возможности восстановления: данные в том состоянии, когда был сделан полный backup + данные на тот момент, когда был сделан дифференциальный.

Инкрементальный backup же позволяет откатиться на любой из моментов в прошлом, когда делалось резервное копирование. Однако, особенно если изменения в данных происходили часто, место будет съедаться быстро.

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

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

При выборе способа резервного копирования нужно прежде всего обратить внимание на следующие критерии:

1. Скорость (время) резервного копирования в хранилище;
2. Скорость (время) восстановления из резервной копии;
3. Сколько копий можно будет держать при ограниченном размере хранилища (сервере хранения бекапов);
4. Объем рисков из-за неконсистентности резервных копий, неотлаженности метода выполнения бэкапов, полной или частичной потери бекапов;
5. Накладные расходы: уровень нагрузки, создаваемой на сервер при выполнении копирования, уменьшение скорости отклика сервиса и т.п.
6. Стоимость аренды всех использующихся сервисов.

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

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

При выборе схемы организации метода резервирования следует обратить внимание на следующие базовые моменты:

1. Резервные копии нельзя хранить в одном месте с резервируемыми данными. Если вы храните резервную копию на одном дисковом массиве с вашими данными, то вы потеряете её в случае повреждения основного дискового массива.
2. Зеркалирование (RAID1) нельзя сравнивать с резервным копированием. Рейд защищает вас только от аппаратной проблемы с одним из дисков (а рано или поздно такая проблема будет, т.к. дисковая подсистема почти всегда является узким местом на сервере). К тому же при использовании аппаратных рейдов есть риск поломки контроллера, т.е. необходимо хранить его запасную модель.
3. Если вы храните резервные копии в рамках одной стойки в ДЦ или просто в рамках одного ДЦ, то в такой ситуации тоже имеются определенные риски (об этом можно прочитать, например, .
4. Если вы храните резервные копии в разных ДЦ, то резко возрастают затраты на сеть и скорость восстановления из удаленной копии.

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

Далее нужно подумать о схеме и времени восстановления данных с точки зрения хранения бекапов. Может быть вас вполне устраивает, что бекап выполняется за 6 часов ночью на хранилище с ограниченной скоростью доступа, однако восстановление длиной в 6 часов вас вряд ли устроит. Значит доступ к резервным копиям должен быть удобным и данные должны копироваться достаточно быстро. Так, например, восстановление 1Тб данных с полосой в 1Гб/с займет почти 3 часа, и это если вы не «упретесь» в производительность дисковой подсистемы в хранилище и сервере. И не забудьте прибавить к этому время обнаружения проблемы, время на решение об откате, время проверки целостности восстановленных данных и объем последующего недовольства клиентов/коллег.

Инкрементальное резервное копирование

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

Инкрементальное копирование чаще всего производится с помощью утилиты rsync. С его помощью можно сэкономить место в хранилище, если количество изменений за день не очень велико. Если измененные файлы имеют большой размер, то они будут скопированы полностью без замены предыдущих версий.

Процесс резервного копирования с помощью rsync можно разделить на следующие шаги:

1. Составляется список файлов на резервируемом сервере и в хранилище, по каждому файлу считываются метаданные (права, время изменения и т.д) или контрольная сумма (при использовании ключа —checksum).
2. Если метаданные файлов разнятся, то файл бьется на блоки и по каждому блоку считается контрольная сумма. Отличающиеся блоки закачиваются в хранилище.
3. Если во время подсчета контрольных сумм или передачи файла в него было внесено изменение, его резервирование повторяется с начала.
4. По умолчанию rsync передает данные через SSH, а значит каждый блок данных дополнительно шифруется. Rsync можно также запустить как демон и передавать данные без шифрования по его протоколу.

С более подробной информацией о работе rsync можно ознакомиться на официальном сайте .

Для каждого файла rsync выполняет очень большое количество операций. Если файлов на сервере много или если процессор сильно загружен, то скорость резервного копирования будет существенно снижена.

Из опыта можем сказать, что проблемы на SATA-дисках (RAID1) начинаются примерно после 200G данных на сервере. На самом деле всё, конечное же, зависит от количества inode. И в каждом случае эта величина может смещаться как в одну так и в другую сторону.

После определенной черты время выполнения резервного копирования будет очень долгим или попросту не будет отрабатывать за сутки.

Для того, чтобы не сравнивать все файлы, есть lsyncd. Этот демон собирает информацию об изменившихся файлах, т.е. мы уже заранее будем иметь готовый их список для rsync. Следует, однако, учесть, что он дает дополнительную нагрузку на дисковую подсистему.

Дифференциальное резервное копирование

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

Дифференциальное резервное копирование осуществляется, например, при помощи такой утилиты, как rdiff-backup. При работе с этой утилитой возникают те же проблемы, что и при инкрементальном резервном копировании.

В целом, если при поиске разницы в данных осуществляется полный перебор файлов, проблемы такого рода резервирования аналогичны проблемам с rsync.

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

Полное резервное копирование

Полное копирование обычно затрагивает всю вашу систему и все файлы. Еженедельное, ежемесячное и ежеквартальное резервное копирование подразумевает создание полной копии всех данных. Обычно оно выполняется по пятницам или в течение выходных, когда копирование большого объёма данных не влияет на работу организации. Последующие резервные копирования, выполняемые с понедельника по четверг до следующего полного копирования, могут быть дифференциальными или инкрементальными, главным образом для того, чтобы сохранить время и место на носителе. Полное резервное копирование следует проводить по крайней мере еженедельно.

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

На самом деле полное резервное копирование можно поделить на 2 части:

1. Полное резервное копирование на уровне файловой системы;
2. Полное резервное копирование на уровне устройств.

Рассмотрим их характерные особенности на примере:
root@komarov:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/komarov_system-root 3.4G 808M 2.4G 25% / /dev/mapper/komarov_system-home 931G 439G 493G 48% /home udev 383M 4.0K 383M 1% /dev tmpfs 107M 104K 107M 1% /run tmpfs 531M 0 531M 0% /tmp none 5.0M 0 5.0M 0% /run/lock none 531M 0 531M 0% /run/shm /dev/xvda1 138M 22M 109M 17% /boot

Резервировать мы будем только /home. Все остальное можно быстро восстановить вручную. Можно также развернуть сервер системой управления конфигурациями и подключить к нему наш /home.

Полное резервное копирование на уровне файловой системы

Типичный представитель: dump.

Утилита создает «дамп» файловой системы. Можно создавать не только полную, но и инкрементальную резервную копию. dump работает с таблицей inode и «понимает» структуру файлов (так, разреженные файлы сжимаются).
Создавать дамп работающей файловой системы «глупо и опасно», потому что ФС может изменяться во время создания дампа. Его надо создавать со снапшота (чуть позже мы обсудим особенности работы со снапшотами более подробно), отмонтированной или замороженной ФС.

Такая схема так же зависит от количества файлов, и время её выполнения будет расти с ростом количества данных на диске. В то же время у dump скорость работы выше, чем у rsync.
В случае, если требуется возобновить не резервную копию целиком, а, например, только пару случайно испорченных файлов), извлечение таких файлов утилитой restore может занять слишком много времени

Полное резервное копирование на уровне устройств

1. mdraid и DRBD
   Фактически настраивается RAID1 с диском/рейдом на сервере и сетевым диском, и время от времени (по частоте выполнения бекапов) дополнительный диск синхронизируется с основным диском/рейдом на сервере.

   Самый большой плюс — скорость. Длительность выполнения синхронизации зависит только от количества внесенных за последний день изменений.
   Такая система резервного копирования используется довольно часто, но мало кто отдает себе отчет в том, что полученные с ее помощью резервные копии могут быть недееспособными, и вот почему. Когда синхронизация дисков завершена, диск с резервной копией отключается. Если у нас, например, запущена СУБД, которая пишет данные на локальный диск порциями, храня промежуточные данные в кэше, нет никакой гарантии того, что они вообще попадут на бэкапный диск. В лучшем случае мы потеряем часть изменяемых данных. Поэтому такие бэкапы вряд ли стоит считать надежными.

2. LVM + dd
   Снапшоты — замечательный инстумент для создания консистентных бекапов. Перед созданием снапшота необходимо сбросить кеш ФС и вашего ПО на дисковую подсистему.

Например, с одним MySQL это будет выглядеть так:
$ sudo mysql -e "FLUSH TABLES WITH READ LOCK;" $ sudo mysql -e "FLUSH LOGS;" $ sudo sync $ sudo lvcreate -s -p r -l100%free -n %s_backup /dev/vg/%s $ sudo mysql -e "UNLOCK TABLES;"

* Коллеги рассказывают истории как у кого-то «read lock» иногда приводил к дедлокам, но на моей памяти такого не было ни разу.

Бекапы СУБД можно создать отдельно (например, используя бинарные логи), устранив тем самым простой на время сброса кеша. А можно создавать дампы в хранилище, запустив там инстанс СУБД. Резервное копирование разных СУБД — это тема для отдельных публикаций.

Копировать снапшот можно с использованием докачки (например, rsync с патчем для копирования блочных устройств bugzilla.redhat.com/show_bug.cgi?id=494313), можно по блокам и без шифрования (netcat, ftp). Можно передавать блоки в сжатом виде и монтировать их в хранилище при помощи AVFS, и примонтировать на сервере раздел с бекапами по SMB.

Сжатие устраняет проблемы скорости передачи, забития канала и места в хранилище. Но, однако если вы не используете AVFS в хранилище, то на восстановление только части данных у вас уйдет много времени. Если будете использовать AVFS, то столкнетесь с её «сыростью».
Альтернатива сжатию блоками — squashfs: можно подмонтировать, к примеру, по Samba раздел к серверу и выполнить mksquashfs, но эта утилита так же работает с файлами, т.е. зависит от их количества.

К тому же при создании squashfs тратится достаточно много ОЗУ, что может легко привести к вызову oom-killer.

Безопасность

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

Если канал резервного копирования может быть прослушан, то нужны средства шифрования.

Заключение

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

В итоге, при выборе системы резервного копирования под ваш проект, нужно провести тесты выбранного типа резервного копирования и обратить внимание на:

• время резервного копирования в текущей стадии проекта;
• время резервного копирования в случае, если данных будет в разы больше;
• нагрузку на канал;
• нагрузку на дисковую подсистему на сервере и в хранилище;
• время восстановление всех данных;
• время восстановления пары файлов;
• необходимость в консистентности данных, особенно БД;
• расход памяти и наличие вызовов oom-killer;

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

Теги: Добавить метки

Все носители информации, такие как жесткие диски, флешки, SSD носители, магнитные накопители, CD/DVD и т.д, обладают разной степенью надежности. Одни создаются крупными компаниями и являются оригинальными, другие – очевидные китайские подделки. Так или иначе, все накопители являются устройствами, а любое устройство, даже самое надежное, может в любой момент выйти из строя, унеся с собой все ваши файлы. В идеале, все пользователи ПК должны заботиться о дублировании хранящейся на компьютере информации, но на практике таких людей не много.

Разновидности резервных копий

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

Резервная копия диска (системы или образ Windows) - это дубликат всего тома диска, то есть логического раздела, на котором установлена Windows. Чаще всего, это может быть содержимое каждого сектора носителя информации, упакованное в единый файл-контейнер. Для его хранения требуется значительное место на диске, сравнимое с размером данных самого диска. Конечно, если у вас объемы хранилищ большие, то это не проблема. Однако, хранение нескольких дубликатов может оказаться затратным. К тому же, создание backup"а всего тома может потребовать существенно больше времени, чем копирование отдельных директорий. К достоинству можно отнести быстрое восстановление всей системы и установленных программ, а к недостаткам - невозможность восстановить только отдельно выбранные директории.

Резервная копия папки - это дубликат папки на диске, созданный в определенный момент времени. Как правило, пользователя ПК не интересует сохранность операционной системы Windows, так как ее можно переустановить без особых проблем. Гораздо более важными для человека являются рабочие документы, бухгалтерские базы 1С , личные фото и видео материалы , e-mail переписка, настройки к различным программам и т.п. В этом случае потребуется гораздо меньше дискового пространства, чем при копировании тома целиком.

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

4 простых способа создания резервных копий файлов на ПК или ноутбуке

Существуют 4 основных способа, как создавать резервные копии. Посмотрим на них, оценим плюсы и минусы этих способов, в том числе создания образа диска.

Способ 1 . Копирование файлов вручную (из одной папки в другую)

выполняется без использования каких-либо программ или инструментов.

Плюсы : Ничего устанавливать не нужно. Просто открываете два окна Windows (с директорией-источником и приемником), выделяете нужные файлы и папки и перетаскиваете их мышью из окна в окно.

Минусы :

• Требуется часто отвлекаться от текущих дел, чтобы скопировать рабочие папки
• Можно забыть вовремя сделать back up важных данных (человеческий фактор)
• Сложно, если исходные данные нужно копировать из нескольких разных папок
• Неудобно управлять бэкапами

Способ 2 . Копирование с помощью bat-файлов

Файлы с расширением.bat являются исполняемыми в операционной системе Windows, имеют текстовый формат и могут выполнить последовательность команд, в том числе и копирование из одной папки в другую. Данный способ можно назвать полуавтоматическим, т.к. обычно bat запускают вручную и они довольно сильно уступает программам автоматического "бэкапирования".

Плюсы : Не нужен какой-либо софт. Достаточно самостоятельно создать bat-файлы и настроить Task Scheduler в Панели управления Windows для запуска.bat в определенное время.

Минусы : Требуются определенные знания и время, чтобы создать.bat, которые по удобству, функциям и гибкости сильно уступают специализированным бэкап-программам.

Способ 3 . С помощью специального софта - программы для создания "бэкапов"

3. Исходные данные

На этом этапе необходимо выбрать папки и файлы, которые нужно копировать. При этом вы можете указать как локальные директории компьютера, так и сетевые, на FTP-сервере или внешнем устройстве. Для копирования из Linux в Windows обычно используют FTP или SSH протокол. Для каждой выбранной папки вы можете указать маски, например все (*.*) или все, кроме "~*.pps". В данном примере указана локальная папка с рабочими документами и фотографиями.

Выбор папок, которые необходимо копировать

4. Сжатие в ZIP

Вам необходимо решить, архивировать ли исходные файлы в стандартный формат ZIP или же обойтись простым копированием "как есть". Даже если учесть, что фотографии или аудио-файлы очень плохо сжимаются, все же рекомендуется включить опцию сжатия в ZIP по следующим причинам:

• Удобно, что backup всех данных хранится в одном ZIP-архиве
• В платных версиях есть возможность указать пароль на архив и выбрать метод шифрования, тем самым скрыть ваши рабочие документы от посторонних глаз
• Типы плохо сжимаемых форматов (JPG, MP3, AVI, MOV и т.п.) можно указать ниже, где перечислены форматы, к которым не будет применено сжатие – это ускорит выполнение задания

Параметры сжатия в ZIP и шифрование

5. Куда сохранять

Как мы и договорились, будем сохранять файлы на внешнем жестком диске (HDD или SSD), подключенному к порту USB (пусть это будет диск H:\, так он обозначился в системе при подключении). В платных версиях вы можете указать неограниченное количество мест, где будут храниться backup"ы папок (локальные, сетевые диски, FTP-серверы) и таким образом повысить надежность хранения.

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

Где хранить резервные копии файлов? Выбор места для хранения

6. Расписание

Встроенный планировщик позволяет достаточно гибко указать 1 или несколько (даже 100) расписаний запуска задания, например каждый день в 12:00, а по пятницам в 18:00. Кроме того, мы можем указать запуск задания при подключении внешнего диска, чтобы создание резервной копии началось сразу при подключении диска к USB-порту. При желании, можно не указывать расписание, чтобы самостоятельно запускать задание по кнопке в программе.

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

• Каждый день, в 08:00
• Каждый второй день, каждый час с 08:00 до 12:00
• Пн, Вт, Ср, Чт, Пт в 15:00, в Сб, Вс в 11:00
• В 1-й день месяца и 15-го числа в 17:00

Уведомление

Кроме того, что программа все действия записывает в журнал, вы можете указать способ уведомления о выполнении задания как по e-mail (или SMS на мобильный телефон), так и по локальной сети (Net send) или простым сообщением на экран поверх всех окон. Более того, вы можете выбрать, в каком случае нужно присылать уведомление: когда бекап данных создан и всё хорошо или только в случае ошибок и предупреждений в журнале. В теме сообщения допускаются переменные: имя ПК, где работает программа, имя выполненного задания и результат. Благодаря всем этим настройкам, вы можете контролировать процесс резервирования, где бы вы ни находились.

Готово. Задание создано!

Нажмите кнопку "Готово" - задание создано! Войдите в общие настройки программы (кнопка "Настройки" расположена вверху главного окна) и убедитесь, что включена опция "[x] Загружать программу при старте Windows", затем нажмите OK.

Запуск задания

Теперь, при подключенном к ПК внешнего диска с заданным именем, начнет выполняться наше задание. Можете свернуть программу в область уведомлений (System Tray) и заниматься своими делами. При выполнении задания над областью уведомлений плавно появится панель, показывающая процесс выполнения задания. После завершения задания панель плавно исчезнет.

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

Восстановление файлов из резервной копии

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

Exiland Backup имеет 3 версии: Free (бесплатная), Standard и Professional, разработана как для домашних пользователей, так и для бизнеса, обеспечивая безопасность данных на рабочих станциях и серверах .

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

сли объема памяти на выбранном для хранения носителе недостаточно для переноса файлов, то используется архивирование со сжатием. К тому же сжатие данных сокращает расходы на хранение и передачу данных по сети или в Интернете. Сжатие данных выполняется с помощью специальных программ-архиваторов, таких как Zip, Rar, Arj и пр. В зависимости от выбора степени сжатия исходные файлы (особенно текстовые) могут уменьшаться в объеме примерно в четыре-пять раз. При этом следует учесть, что упаковка данных происходит значительно медленнее, чем их восстановление, и что при современной производительности компьютеров можно сжимать не только редко используемые данные и программы, но и активно эксплуатируемые.

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

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

Базовые средства операционных систем

птимальная организация резервирования предполагает автоматическое копирование: файлы помещаются на предназначенные для них носители таким образом, что в процессе работы пользователь этого даже не замечает. Взрывообразный рост емкости используемых винчестеров привел к тому, что организация программно-аппаратного комплекса для сохранения таких объемов информации значительно усложнилась. Традиционные накопители на магнитной ленте, а также Jaz- и Zip-диски уже не выдерживают конкуренции с жесткими дисками и мало подходят для резервирования. Болванки CD-R/RW и появившиеся относительно недавно записываемые DVD-диски обладают несколько большей емкостью, но тоже не справляются с современными объемами в десятки и сотни гигабайт. Можно, конечно, решить эту проблему, создав несколько отдельных систем резервирования, каждая из которых будет работать по своему графику и с собственным носителем.

Например, с помощью утилиты Мicrosoft Backup можно сделать один резервный файл для копирования каталога Windows и корневых каталогов, другой - каталога Program Files, третий - файлов данных и т.д., но в этом случае пользователю придется выполнять вручную множество операций. Средства автоматизированного резервирования появились еще в Windows 95, где был установлен пакет Microsoft Plus, а для запуска Microsoft Backup использовалась утилита System Agent, добраться до которой можно было из меню «Пуск», пунктов «Программы»/«Стандартные»/«Служебные программы»/«Архивация данных». Чтобы указать, какие файлы нужно копировать, достаточно было выбрать в правой и левой панелях открывшегося окна соответствующие опции, потом выбрать нужный дисковый либо ленточный накопитель, а также каталог для хранения резервных копий и указать, что программу резервирования следует закрыть после завершения ее работы. Для автоматизации работы этой программы следовало отключить вывод на экран запроса на подтверждение перед началом операции. Таким образом, задав однажды во вкладке Backup меню «Параметры» все необходимые настройки и указав в пункте «Файл»/«Сохранить как» имя и местонахождение будущей резервной копии (другой диск или каталог), вы могли организовать автоматический процесс резервирования. Поскольку SET-файлы по умолчанию были ассоциированы с утилитой Microsoft Backup, простое добавление файла в список приводило к запуску Backup. Там же задавался график резервирования (When to Run - когда запускать System Agent). Если же требовалось запланировать несколько сеансов резервирования для различных наборов файлов и разных накопителей, то данную процедуру следовало повторить, задавая различные имена SET-файлам и иной график выполнения.

Версия Microsoft Backup, поставлявшаяся вместе с операционной системой Windows 98, уже не позволяла установить автоматическое архивирование. Конечно, можно было запускать Microsoft Backup с помощью планировщика заданий, но для того, чтобы он сделал резервную копию, ему требовались некоторые вводные данные.

Операционные системы семейства Windows NT поставлялись с утилитой NTBACKUP.EXE, которую можно было использовать в большинстве случаев для резервного копирования данных и которая поддерживала следующие пять видов создания резервных копий:

Нормальная резервная копия, которая сохраняла выбранные файлы и помечала их как резервные;

Пошаговая резервная копия, сохранявшая только те файлы, которые изменились со времени создания последней резервной копии, а после копирования они помечались как резервные;

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

Копирование файлов в архив, как для создания резервной копии (что то же самое, что и выборочная резервная копия, только файлы здесь не помечаются как резервированные);

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

Как видите, это был уже вполне профессиональный подход, который сохранился и в операционных системах Windows 2000/XP, но тем не менее возможности стандартной Вackup-утилиты очень ограниченны. Для более гибкого резервирования применяются и другие программы.

Утилиты резервного копирования дисков

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

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

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

Пользователи Windows наверняка замечали, что чем больше они устанавливают новых программ (прежде всего это касается компьютерных игр), тем медленнее и неустойчивее работает вся система. Иногда к разрушению системы приводит инсталляция новых устройств или просто какие-то несанкционированные компанией Microsoft эксперименты, и уж совсем плачевно выглядит рабочая среда после вирусной атаки. Часто даже резервная копия не помогает восстановлению (не успели зарезервировать или вообще потеряли рабочую копию), и тогда приходится устанавливать операционную систему заново. В этом случае вам поможет только полное сохранение рабочей копии системного диска (например, на CD-R/RW) с возможностью ее восстановления в первозданном виде. Такую копию следует сделать после первой установки системы, всех необходимых программ и драйверов и проверки ее работоспособности.

Самыми популярными решениями для репликации содержимого жестких дисков до последнего времени были утилиты Norton Ghost и PowerQuest Drive Image. Однако появившиеся недавно отечественные разработки в области резервного копирования не только не уступают, но во многом и превосходят вышеперечисленные программы - речь идет прежде всего о продуктах компании Acronis (http://www.acronis.com , http://www.acronis.ru). К тому же разработчики большинства продуктов Acronis находятся в Москве (в отличие от своих конкурентов PowerQuest и Symantec), поэтому все программы обладают русскоязычным интерфейсом. Кроме того, продукты компании Acronis в России проще купить, чем украсть: при цене 50-70 долл. на мировом рынке, все они продаются у нас за 299-399 руб. По-моему, совсем недорого за чистую совесть и поддержку отечественного производителя, а кроме того, за русскоязычную поддержку самого продукта от производителя.

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

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

True Image

Для Windows 95/98/Me/NT (включая Server)/2000 (включая Server)/XP

Acronis True Image 6.0 — лучший на сегодняшний день продукт для полного резервного копирования, позволяющий создавать точные образы жесткого диска и/или отдельных разделов прямо в Windows без перезагрузки. Образ диска, включающий абсолютно все данные, приложения и операционные системы, может быть восстановлен на жесткий диск в случаях внезапной «кончины» жесткого диска, вирусных атак и любых других фатальных ошибок программного и аппаратного обеспечения, причем даже в тех ситуациях, когда обычные средства резервного копирования файлов уже не помогают.

Основные возможности:

Быстрое создание точного образа диска с гарантией полной сохранности данных (поддерживаются жесткие диски любых размеров);

Восстановление как жестких дисков целиком, так и отдельных разделов или файлов и папок на них (восстанавливаются и обычные разделы с данными, и системные);

Удобное копирование точного образа жесткого диска на CD-R/RW, ZIP, JAZ или на какое-либо другое устройство хранения данных со сменным носителем в дружественной среде с пошаговыми инструкциями и с интерфейсом в стиле Windows XP;

Полное клонирование жесткого диска на новый компьютер.

Эксклюзивные возможности:

Возможность создания и восстановления полного образа диска непосредственно в Windows без необходимости перезагрузки в DOS или в другую систему;

Наличие дружественного пользовательского интерфейса с пошаговыми инструкциями в стиле Windows XP, делающего работу доступной для пользователя любой квалификации;

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

Прочие особенности:

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

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

Задание пользователем уровня сжатия; разбивание архива на несколько томов; установление пароля;

Задание комментария к создаваемому образу раздела;

Создание загрузочной дискеты, компакт-дисков CD-R/RW или DVD-R/RW, с помощью которых можно восстановить работоспособность компьютера даже в случае, если все операционные системы на нем уничтожены;

Возможность менять в процессе восстановления типы раздела, файловой системы, размеры и расположение диска (поддерживаются файловые системы Windows FAT16/32 и NTFS, а также Linux Ext2, Ext3, ReiserFS и SWAP, а для разделов других типов обеспечивается специальная посекторная поддержка);

Полная поддержка жестких дисков и пишущих приводов с интерфейсами IDE, SCSI, PCMCIA, USB 2.0 и FireWire.

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

Следует подчеркнуть, что при запуске Acronis True Image не требуется выполнять перезагрузку компьютера, более того - вы можете продолжать работу с приложениями в обычном режиме, однако при этом не следует запускать ресурсоемких приложений. Хотя компания Acronis утверждает, что с помощью ее уникальных технологий при создании образа обеспечивается целостность данных, структур жесткого диска и файловых систем, но лучше все же минимально использовать компьютер при этом процессе. Кроме того, Acronis True Image не гарантирует целостности данных на уровне таких сложных приложений, как Microsoft SQL Server, Oracle и Microsoft Exchange.

Drive Image

Для Windows DOS/95/98/Me/NT/2000/XP

Утилита Drive Image Pro предназначена для резервного копирования информации с жесткого диска в файл или на другие носители информации (Jaz, Zip, CD-R/RW и пр.) и вполне обоснованно считается не только одним из лучших решений для клонирования жестких дисков, но и весьма удобным инструментом для резервного копирования.

Drive Image позволяет создать сжатый образ винчестера, защитить информацию паролем и зашифровать ее в случае необходимости. При восстановлении можно скопировать весь диск или отдельные файлы, а также разбить диск на логические разделы (этим занимается утилита PartitionMagic Pro). Drive Image поддерживает все известные файловые системы: FAT, FAT32, NTFS и HPFS.

Хотя Drive Image инсталлируется практически во всех версиях Windows, на самом деле это DOS-приложение - программа запускается из MS-DOS и имеет малый размер (может быть записана на дискету). При этом не имеет значения, как вы загрузитесь в DOS, поскольку Drive Image можно запустить из инсталляционного каталога или с CD-ROM при помощи утилиты QuickImage, которая создает виртуальную дискету в памяти вашего компьютера. Drive Image загружается с этой виртуальной дискеты и выполняет выбранные вами задачи по резервному копированию и восстановлению файлов.

Самое главное преимущество этой программы состоит в том, что она может самостоятельно записать образ диска на CD-R/RW и сделать его загрузочным. Поддерживаются и другие съемные накопители, а в состав Drive Image входят все необходимые драйверы. Реализована функция для создания набора из двух гибких загрузочных дисков, которые обеспечат запуск программы в том случае, если нет CD-R или память не позволяет сформировать виртуальную дискету. Интерфейс программы выполнен в виде мастера, интуитивно понятен и даже не требует обращения к руководству пользователя.

При подготовке образа диска Drive Image оценивает размер конечного файла (в зависимости от выбранного режима компрессии), а затем позволяет протестировать его целостность. Кроме основного диска, можно сохранить и образы скрытых разделов, что помогает защитить их от случайного повреждения.

Отметим, что полное восстановление диска программой Drive Image занимает значительно меньше времени, чем инсталляция системы Windows (не говоря уже о необходимых драйверах и приложениях и о последующей настройке). Кроме того, восстановление диска из образа благодаря технологии SmartSector (программа работает на уровне секторов, в обход файловой системы) происходит даже быстрее, чем необходимо для обычного копирования информации, а размер файла образа более чем вдвое меньше объема сохраненных в нем данных.

Восстановление информации никаких затруднений не вызывает (особенно если вы выбрали опцию копирования «диск в диск»), однако если вы захотите восстановить рабочую среду на компьютере с другой аппаратной конфигурацией, то вам потребуется профессиональная версия Drive Image Pro, куда входят такие вспомогательные утилиты, как PowerCast (программа для одновременного тиражирования информации на произвольное число компьютеров в локальной сети) и полная версия PartitionMagic Pro. А для работы с файлами образов нужна утилита Drive Image File Editor, при помощи которой можно копировать разделы из одного образа в другой, сжимать образ диска, удалять из него информацию, разбивать на несколько файлов (что необходимо, например, для копирования большого диска на различные сменные накопители) или, наоборот, объединять несколько файлов в один, а также выборочно восстанавливать разделы и считывать необходимую информацию из файла образа диска. Для извлечения отдельных файлов предназначена утилита Image Explorer, поставляемая вместе с Drive Image.

Кроме того, в состав Drive Image входит отдельная программа DataKeeper, которая может использоваться для организации автоматического резервного копирования измененной информации в уже созданный образ диска, то есть при каждом изменении содержимого файлов (на целом диске или в избранных каталогах) они будут сохраняться в файл образа автоматически. При этом различные версии файлов могут накапливаться практически без ограничений. По умолчанию копируются все файлы, кроме программных модулей, однако можно явно указать необходимые расширения или шаблоны. Можно также составить расписание для автоматического выполнения задач резервного копирования и восстановления, например для того, чтобы каждую ночь общедоступная машина приводилась в рабочее состояние либо чтобы какой-то раздел диска копировался на CD-R/RW (или на другой съемный носитель) или в сжатый файл, находящийся в другом разделе того же жесткого диска.

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

Последняя версия PowerQuest Drive Image 7.0 отличается от предыдущих рядом новых возможностей. В частности, она позволяет сохранять образы целых дисков или отдельных разделов на носители DVD-R/RW и DVD+R/RW, а также поддерживает разнообразные внешние накопители с интерфейсами USB (в том числе версии 2.0) и FireWire. Некоторые улучшения произошли и в области сетевой поддержки, вследствие чего пользователи могут сохранять образы и восстанавливать содержимое с дисков по сети. Кроме того, благодаря технологии Virtual Volume Imaging (V2i) имеется возможность оформления резервных образов в виде виртуальных жестких дисков.

Norton Ghost

Для Windows XP/2000/NT WS/Me/98

Программа Norton Ghost 2003 корпорации Symantec (первоначально она была разработана компанией Binary Research) может защитить информацию от различных проблем, связанных с аварийными сбоями в работе компьютера. Norton Ghost хотя и не самая удобная программа для создания копии диска, но наиболее полная по своим возможностям. Она позволяет копировать и восстанавливать как отдельные разделы, так и весь диск полностью, причем образ диска можно считывать и записывать по сети, через параллельный или USB-порт, а также сохранять на CD-R/RW или на других сменных носителях.

Данная программа реализует все основные функции, которых только можно ждать от такого рода решения: копирование данных с жесткого диска на другой жесткий диск или в файл (образ диска), копирование дисковых разделов на жесткий диск, на сменные носители и в файлы, защищенные с помощью пароля и сжатые. В пакете имеется очень хороший редактор образа диск Ghost Explorer, который позволяет просматривать образ диска и восстанавливать отдельные файлы. Программа также обеспечивает функции проверки поверхности диска на наличие ошибок и сбойных секторов и имеет возможность копирования «сектор в сектор», если пользователь желает получить точную копию диска. Достаточно простой и интуитивно понятный интерфейс позволяет с легкостью делать резервные копии жесткого диска и упрощает впоследствии процедуру его восстановления. В окне Ghost Explorer можно перемещать мышью файлы и папки в файл образа или из него. Запускаемая из командной строки утилита форматирования диска Gdisk содержит уникальный набор функций, рассчитанных на опытных пользователей, знающих, как с ними обращаться.

Программа также может регулярно создавать резервные копии, просто и надежно восстанавливать файлы и упрощать любую модернизацию системы. Ghost может записывать копии на жесткие или съемные диски, включая приводы CD-R/RW и DVD+RW, а также на сменные устройства типа Iomega Zip и Jaz. Запись может также осуществляться непосредственно на поддерживаемые устройства USB или FireWire (IEEE-1394), а быстрое соединение между несколькими компьютерами через локальную сеть, USB или высокоскоростные параллельные порты обеспечивает возможность создания разнообразных клонов.

Однако следует отметить, что, в отличие, например, от Drive Image, перед выполнением любых операций по созданию образа или восстановлению диска программу Norton Ghost нужно загрузить с гибкого диска или с загрузочного компакт-диска, а также ввести серийный номер программы перед восстановлением образа. При этом один загрузочный диск вы должны создать для записи копий образов на CD-RW, а другой - для считывания их с диска CD-RW. Нельзя использовать один и тот же гибкий диск для чтения и записи, хотя в ходе подготовки второго диска можно копировать его содержимое на диск CD-RW.

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

Программа имеет подробное учебное пособие и обладает надлежащей поддержкой на сайте компании Symantec в Интернете.

Розничная цена программы — около 70 долл.

Paragon Drive Backup

Для Windows: 9х/Me/NT/2000/XP

Drive Backup — утилита для резервного копирования данных, в том числе для создания копий разделов с целью их быстрого восстановления в случаях аварии, вирусной атаки или при необходимости перенести все данные, включая операционную систему и установленное программное обеспечение, на новый жесткий диск. Переустановка операционной системы и приложений после выхода из строя аппаратуры или вирусной атаки не отнимет у вас много времени и сил. Наилучший путь защитить систему –– сделать резервную копию системного раздела с установленной на нем операционной системой и всеми необходимыми приложениями. Копии могут создаваться на жестком диске и сменных носителях (ZIP, JAZ, Sequest, CD-R/RW), а также на дисках, подключенных по сети.

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

Правда, утилита Paragon Drive Backup не смогла достичь столь серьезного коммерческого успеха, как это удалось Acronis True Image. И причина здесь, по-видимому, в интерфейсе пользователя и удобстве работы с пакетом: очевидно, что компания Acronis создала более дружественную по отношению к пользователю программу.

Universal Backup

Для Windows 95/98/Mе/NT/2000/XP

Если у вас не окажется 300 руб. на покупку Acronis True Image, то для резервного копирования можно воспользоваться бесплатно распространяемой программой с русскоязычным интерфейсом, которая так и называется - Universal Backup (универсальный «резерватор»). Эта многофункциональная программа предназначена в первую очередь для создания архивов, содержащих любые файлы и каталоги, с возможностью их последующего восстановления как из-под «глухого» DOS, так и непосредственно из Windows. Утилита позволяет сканировать любые файлы, каталоги, ключи и переменные реестра, а также DOS-файлы и файлы настройки Windows. Информация о сканировании сохраняется в отчетные файлы, которые впоследствии можно сравнивать и на основе различий создавать архивы. Хотя программа очень маленькая (189 Кбайт) и не требует инсталляции, она вполне годится для резервирования как какой-либо отдельной программы, так и операционной системы в целом.

Основные возможности:

Создание архивов, содержащих любые файлы, каталоги, ключи и переменные системного реестра;

Восстановление файлов, каталогов, ключей и переменных реестра в их исходные места расположения (как из DOS, так и непосредственно из Windows);

Сканирование любых каталогов, ключей реестра, файлов настройки Windows (control.ini, system.ini, win.ini) и системных файлов MS-DOS (boot.ini, winstart.bat, dosstart.bat, autoexec.bat, config.sys, msdos.sys);

Сравнение отчетов о произведенных ранее сканированиях с целью выявления различий между ними (создание, удаление и изменение файлов, каталогов, ключей и переменных реестра);

Создание архивов на основе выявленных изменений (в архив включаются созданные и измененные файлы, каталоги, ключи и переменные реестра);

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

Доустановление необходимых компонентов системы.

Данная программа облегчит жизнь огромному количеству пользователей, а умещается всего на одной дискете. Вы только представьте себе: полная переустановка Windows из-под DOS займет у вас считанные минуты! Обычно большую часть времени занимает не столько установка самой операционной системы, сколько ее дальнейшая настройка и оптимизация, а с помощью Universal Backup вы эту проблему решите. Все, что вам необходимо, - это инсталлировать операционную систему, настроить ее по своему усмотрению, установить необходимые программы, а затем создать посредством Universal Backup резервный архивный файл.