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

01.07.2023

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

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

Если база данных в состоянии онлайн, ограничьте доступ к ней, переключив режим доступа (в окне свойств) на RESTRICTED_USER. Таким образом доступ к базе данных будет разрешен только членам группы базы данных db_owner и членам групп сервера dbcreator и sysadmin.
Исправьте ошибку, вызвавшую крушение базы данных.
Если возможно, примените все сохраненные в резервных копиях журналы транзакций с параметром 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’

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

Если база данных в состоянии онлайн, ограничьте к ней доступ, переключив режим доступа (в окне свойств) на RESTRICTED_USER. Тем самым доступ к базе данных будет разрешен только членам группы базы данных db_owner и членам групп сервера dbcreator и sysadmin.
Выполните резервирование заключительного фрагмента журнала.
Исправьте ошибку, вызвавшую сбой базы данных.
Выполните восстановление полной резервной копии с параметром NORECOVERY.
Выполните восстановление последней имеющейся разностной резервной копии с параметром NORECOVERY.
Выполните восстановление резервной копии заключительного фрагмента журнала с параметром 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 работает немного по другому – база данных готова к использованию сразу после повторения изменений, не дожидаясь фазы отмены незавершенных транзакций.

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

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

Введение

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

Для защиты от потери информации используются системы резервного копирования и восстановления данных (Backup & Recovery). Система резервного копирования и восстановления данных - это программный или программно-аппаратный комплекс для создания копий данных с определенной периодичностью для их последующего восстановления. Помимо защиты от потери данных системы резервного копирования также позволяют обеспечить организовать непрерывность работы сотрудников за счет быстрого восстановления операционной системы (при наличии ее образа) или восстановления данных на другом компьютере.

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

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

Главные разделительные линии между различными системами резервного копирования и восстановления данных проходят по сферам их использования – для персональных нужд, в небольших компаниях и «домашних офисах» (SMB/SOHO/ROBO) или в средних (Enterprise) и крупных компаниях (Large Enterprise). В зависимости от этого различается цена систем резервного копирования и восстановления данных, используемые типы хранилищ, типы платформ, предоставляемые функции и т.д. Рассмотрим некоторые из этих критериев.

Одно из основных различий для систем резервного копирования и восстановления данных – это тип носителей для хранения данных. Для хранения резервных копий может использоваться лента, оптические диски (CD, DVD, Blu-Ray и т.д.), «жесткие» диски (HDD), твердотельные диски (SSD), сетевые хранилища. Каждый из них имеет свои достоинства и недостатки. Например, хранение данных на лентах только на первый взгляд кажется анахронизмом. Современные ленточные устройства достаточно дешевы и гарантируют длительное хранение данных. Но вот восстановление данных с таких носителей может быть очень долгим. Поэтому они больше подходят для архивации данных. «Жесткие» диски позволяют выполнять резервное копирование и восстановление достаточно быстро, однако у них высокая цена и не самое долгое время жизни.

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

Еще одно различие – это тип используемых платформ. Система резервного копирования и восстановления данных может быть реализована в виде программного обеспечения, программно-аппаратного комплекса или в виде услуги (software-as-a-service). Программное обеспечение стоит дешевле и требует отдельных систем хранения. Поэтому такие системы подходят для персонального использования и небольших компаний. Для крупных компаний такие системы могут использоваться в связке со специальными хранилищами данных. Для средних и крупных предприятий больше подходят системы резервного копирования и восстановления данных, выполненные в виде программно-аппаратных комплексов (PBBA, Purpose-Built Backup Appliance). Данные устройства подразделяются на две категории:

PBBA target systems (целевые системы ). Данные комплексывыступает только в качестве целевого устройства для резервного копирования. Такое решение требует использования дополнительного программного обеспечения для автоматизации, управления и консолидации резервного копирования, которое, в свою очередь, должно быть размещено на дополнительном серверном оборудовании с развернутой операционной системой для интеграции всех перечисленных компонент. К таким устройствам относятся EMC Data Domain, HP StoreOnce и т.д.
PBBA integrated systems (интегрированные системы). Это полностью законченные решения, не требующее дополнительных составляющих для полноценной работы. Они включают в себя сервера, дисковые массивы и программное обеспечение для осуществления резервного копирования. Такие системы имеют большую интеграцию между аппаратурой и программным обеспечением и могут включать дополнительные инструменты для работы с сетью (например, балансировку нагрузки). Такие решения не требуют дополнительных инвестиций в инфраструктуру, имеют меньшие затраты на развертывание и интеграцию, а также проще сопровождать и администрировать. К таким устройствам относятся EMC Avamar, Symantec Appliance BE+NBU и т.д.

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

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

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

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

Количество систем резервного копирования и восстановления данных в мире достаточно ограничено. Магический квадрат от компании Gartner указывает, что первые места на рынке занимают такие компании, как CommVault, EMC, IBM и Symantec.

Рисунок 1. «Магический квадрат» Gartner для систем резервного копирования и восстановления данных

В 2013 году аналитическая компания IDC выпустила подробный отчет (Worldwide Quarterly Purpose Built Backup Appliance Tracker) о рынке специализированных устройств для резервного копирования (PBBA, Purpose Built Backup Appliance). Согласно его данным, выручка компаний в данном сегменте за второй квартал 2013 года составила 720,2 млн. $, что на 7,3% больше, чем год назад.

Таблица 1. Доходы производителей в сфере специализированных устройств резервного копирования (в миллионах долларов)

Производитель	2 квартал 2012		2 квартал 2013
Производитель	Объем продаж	Доля рынка	Объем продаж	Доля рынка

Из приведённой таблицы видно, что более половины рынка занимает компания EMC (62.6%). На второй позиции находится компания Symantec (12.4%), третье место занимает IBM с долей рынка 7.3%. Четвертое и пятое место занимают компании HP (5.3%) и Quantum (2.5%), все остальные компании занимают на рынке менее 2% и в сумме составляют 10% рынка. Из заметных тенденций можно указать на уменьшение доли рынка компании IBM на 40.4% и увеличение доли компании Symantec на 71.3%.

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

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

На российском рынке представлены основные мировые игроки рынка систем резервного копирования и восстановления данных, которые продвигают свои решения через региональных партнеров. На рынке представлены продукты компаний EMC, IBM, HP, Symantec, Dell, NetApp, CA Technologies, которые в большинстве ориентированы на крупные компании. Компания CommVault представлена на российском рынке в меньшем объеме, в основном ее решения предлагает компания КРОК. Также популярностью пользуются решения российских производителей Acronis и Paragon Software Group. Их решения особенно актуальны в связи с политикой экономии многих компаний, которые начинают уделять особое внимание показателям «цена/качество». Для защиты только виртуальных систем используются решения российской фирмы Veeam Software, однако их мы рассмотрим в рамках следующей специализированной статьи.

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

EMC

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

Для оптимизации управления данными используется дополнительное программное обеспечение EMC Data Protection Adviso . Оно автоматизирует мониторинг и анализ резервных копий, обеспечивает отправку оповещений администраторам при возникновении различных событий и позволяет создавать отчеты о работе резервного копирования.

Системы резервного копирования и восстановления данных являются достаточно «гибкими» и при необходимости могут масштабироваться за счет увеличения дискового пространства. EMC Avamar также могут интегрироваться с системами хранения данных EMC Data Domain . Данные системы представлены большой линейкой продуктов от небольших устройств (DD160, DD620), способных хранить несколько терабайт, до очень больших хранилищ (DD990) на несколько петабайт.

IBM

В сфере резервного копирования компания IBM представлена продуктом IBM Tivoli Storage Manager . Это программный продукт, который занимается созданием резервных копий и управлением устройствами хранения. IBM Tivoli Storage Manager совместим с большим количеством различных систем хранения данных. Он обеспечивает работу в локальных (LAN), глобальных (WAN) сетях и развивающихся сейчас сетях хранения данных (SAN).

Tivoli Storage Manager включает в себя средства для удалённого администрирования из любой точки сети или через Интернет. Администратор может автоматизировать различные этапы работы системы резервного копирования и восстановления данных за счет создания политик хранения. Набор политик, настроенный администратором, позволяет не только проводить штатные операции, но и оперативно реагировать на возникновение различных незапланированных ситуаций. За счет использования иерархической системы хранения в системе под управлением Tivoli Storage Manager могут использоваться различные типы устройств хранения (например, ленты и «жесткие» диски).

Tivoli Storage Manager позволяет проводить оптимизацию хранящихся данных за счет их сжатия, консолидации и использования «инкрементного» копирования. Для корпоративного программного обеспечения (базы данных, электронная почта) используются дополнительные клиенты, оптимизирующие работу с конкретным типом приложений.

Symantec

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

Отдельно стоит упомянуть дополнительные технологии по работе с виртуальными машинами. Технология виртуализации Symantec V-Ray объединяет в себе виртуальные и физические резервные копии и дает пользователям единый доступ ко всем резервным копиям, включая VMware, Hyper-V и физические устройства, позволяя быстро восстанавливать виртуальные машины, приложения, базы данных, файлы, папки и даже отдельные элементы приложений. Встроенная технология bare metal recovery позволяет восстанавливать данные на оборудовании, отличном от исходного, и включает в себя функцию резервного копирования в виртуальную машину (B2V) и преобразования в виртуальную машину (P2V), давая пользователям возможность восстановить отказавшие системы в VMware или Hyper-V окружении.

Для удобства работы с системами резервного копирования и восстановления данных Symantec также выпустила на рынок программно-аппаратные устройства Symantec Backup Exec 3600 , Symantec NetBackup 5230 . Одним из преимуществ их использования является минимальное время для их развертывания на предприятии. Утверждается, что администратору понадобится 20-30 минут, чтобы устройства начали работать и полноценно выполнять свои функции.

CommVault

Компания CommVault предлагает систему управления данными, выполненную в виде программного обеспечения и построенную по модульному принципу. Модули обеспечивают архивацию, защиту, резервное копирование и управление данными. Для работы с данными используется единая консоль управления.

Функции резервного копирования в CommVault Simpana включают в себя дедупликацию, создание образов системы, автоматизацию резервного копирования, централизованное управление резервными копиями, создание отчетов, предоставление пользователям самостоятельного доступа к резервным копиям, использование политик для иерархического хранения данных, балансировку нагрузки и т.д. CommVault Simpana обеспечивает глубокую интеграцию в виртуальную инфраструктуру для расширенных средств управления данными для платформ Microsoft Hyper-V, VMware vCenter и VMware vCloud Director.

CommVault поддерживают большинство имеющиеся операционных систем и приложений (в частности, базы данных Oracle, Microsoft, PostgreSQL и MySQL, Documentum, SAP) для того, чтобы создавать резервные копии в процессе работы приложений с минимальной нагрузкой на них.

HP

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

дедупликацию данных в соответствии с технологией HP StoreOnce Federated Deduplication как на клиентах (source based), так и на отдельно выделенном сервере (backup server) или же на системах хранения данных(target based);
резервное копирование и восстановление виртуальных сред, включая защиту как целиком виртуальных машин, так и отдельных данных внутри них;
интеграцию с функциональностью дисковых массивов по созданию аппаратных снимков (snapshots) для осуществления резервного копирования с нулевым простоем Zero Downtime Backup и мгновенного восстановления информации Instant Recovery (IR);
возможность восстановления отдельных элементов резервной копии (например, отдельного файла из бэкапа виртуальной машины).

Для хранения резервных копий используется линейка дисковых библиотек с дедупликацией HPStoreOnce. Решение базируется на серверной платформе HP Proliant Gen8, модели имеют емкость от 8ТБ до 2.2ПБ (до 35ПБ с учетом дедупликации) и поддерживают скорость резервного копирования до 139ТБ/час. Оно может одновременно работать в режиме VTL (Virtual Tape Library), эмулируя ленточные приводы, и выступать в качестве файлового хранилища с доступом по CIFS/NFS.

Dell

В последнее время компания Dell нарастила портфель решений для резервного копирования и восстановления за счет приобретения компаний Quest Software и AppAssure. Для крупных предприятий и компаний Dell предлагает решение NetVault для организации резервного копирования всей инфраструктуры, а для компаний малого и среднего бизнеса более простое решение Appasure. Для резервного копирования виртуальных машин используется приложение vRanger. Российские разработчики подразделения Dell представляют также специализированные решения Dell Software для гранулярного восстановления AD и Exchаnge, а также уникальную технологию автоматизированного восстановления Active Directory при потере данных.

Для примера рассмотрим устройства Dell PowerVault серии DL и DR (актуальны модели - DL4000 и Dell DR4100). Устройства позволяют выполнять следующие функции:

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

Устройства могут работать под управлением программного обеспечения других производителей, например EMC или Symantec.

Quantum

Компания Quantum поставляет системы резервного копирования и хранения данных. Поставляются ленточные (SuperLoader; Scalar i40, i80, i500, i6000) и дисковые (DXi V1000, 4000, 6500, 6700, 8500) устройства и устройства резервного копирования для виртуальных машин Quantum vmPRO 4000.

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

NetApp

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

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

CA Technologies

Для резервного копирования и восстановления данных CA Tehnologies предлагает программное обеспечение CA ARCserve Backup . Оно позволяет выполнять достаточно большой объем функций:

дупликацию данных для сокращения объемов используемых хранилищ;
поддержку резервного копирования при работе с виртуальными машинами под управлением VMware, Microsoft Hyper-V™ и Citrix® XenServer;
поддержка резервного копирования в «облаке» для быстрого переноса данных между физически удаленными объектами;
использование резервного копирования на основе мгновенных снимков (ARCserve D2D) совместно с решением традиционного резервного копирования файлов (CA ARCserve Backup). При этом используется общий каталог резервных копий, чтобы ускорить и упростить процесс восстановления;
возможность централизованного управления процессами копирования и восстановления данных из единой консоли.

Для реализации специализированных задач используются дополнительные модули (CA ARCserve Central Reporting, CA ARCserve Replication , CA ARCserve High Availability), расширяющие функциональность CA ARCserve Backup.

Acronis

Компания Acronis предоставляет целую линейку программного обеспечения для организации резервного копирования и восстановления данных. Для домашнего использования предназначено приложение Acronis True Image , для малых предприятий используется Acronis Backup & Recovery Server for Windows, а для крупных предприятий - for Windows.

Наиболее функциональным является корпоративный продукт Acronis Backup & Recovery Advanced Server , позволяющий выполнять большое количество функций:

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

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

Paragon

Еще одна российская компания, выпускающая системы резервного копирования и восстановления данных. В ее портфеле целый ряд продуктов для резервного копирования и обслуживания жестких дисков – Paragon Hard Disk Manager 12 Suite, Professional, Business, Premium editions (для персональных пользователей и SMB); Paragon Protect and Restore 3 (для крупных компаний); Drive Backup 11 Workstation; Drive Backup 11 Server и т.д. На весну 2014 года на российском рынке анонсируется выпуск Paragon Hard Disk Manager 14, который уже продается на западе.

При помощи данных продуктов можно организовывать полнофункциональный процесс резервного копирования и восстановления данных. Для быстрой миграции или восстановления системы после сбоя используются образы системы. Причем их можно ставить и на компьютеры, аппаратное обеспечение которых отличается от исходного компьютера. Реализованы различные схемы копирования – инкрементное и дифференцированное, позволяющие сокращать объемы копируемых данных. Используется гранулярное восстановление данных и мощный набор фильтров, позволяющий настраивать автоматическое восстановление данных. Поддерживается работа как с реальными, так и виртуальными устройствами. Однако полноценная дедупликация отсутствует. Централизованное управление резервным копированием возможно после установки дополнительного приложения Paragon Remote Management .

Большинство продуктов компании Paragon рассчитаны на персональных пользователей и маленькие и средние компании. Однако последние продукты компании, такие как Hard Disk Manager 12 Premium, выходят за рамки SMB и предоставляет дополнительные инструменты для работы в крупных компаниях.

Перечисленными решениями полностью не ограничивается рынок систем резервного копирования и восстановления данных в России. Есть менее распространенные продукты, например, Handy Backup Server Network (компания «Новософт») или BakBone NetVault . Однако их представленность на российском рынке мала или не поддается точной оценке, поэтому они и не попали в список рассматриваемых нами решений.

В наш обзор не вошли бесплатные системы для резервного копирования и восстановления данных, т.к., не имея данных об объемах продаж сложно оценить их присутствие на рынке. Из наиболее популярных бесплатных программ для резервного копирования на российском рынке отметим приложение Clonezilla . Оно позволяет создавать образы системы или копии данных на локальном или удалённом компьютере. Корпоративная версия Clonezilla Server позволяет управлять резервным копированием в локальной сети компании.

Выводы

Системы резервного копирования и восстановления данных являются необходимым элементом безопасности любых рабочих мест – как личных, так и корпоративных. Сегодняшний уровень этого класса решений позволяет сделать процесс резервного копирования быстрым и удобным для пользователей. Внимание также уделяется не только быстроте создания резервных копий, но и скорости их восстановления. При использовании специализированных алгоритмов время восстановления данных существенно уменьшается. Используемые для этого алгоритмы позволяют существенно сокращать время восстановления данных. Представленные на рынке системы постоянно развиваются и включают в себя новые технологии работы с данными. Так многие системы предлагают возможность хранить данные в облаке, использовать виртуальные машины, позволяют работать с новыми типами протоколов и устройств хранения данных. Это говорит о взаимном интересе производителей и потребителей данного класса решений. Стоит отметить, что в будущем системы резервного копирования и восстановления будут все теснее интегрироваться с решениями по хранению резервных копий и решениями для организации совместного доступа и удаленной работы с данными в «облаке».

Рынок систем резервного копирования и восстановления данных достаточно зрел. На мировом уровне уже достаточно давно сложился набор лидеров в данной области, которые год от года стремятся поддерживать высокий уровень своих решений. Это компании EMC, CommVault, Symantec, IBM, HP, Quantum, NetApp, CA Technologies. На российском рынке представлены продукты всех указанных лидеров. Спецификой рынка является присутствие российских игроков – Acronis и Paragon, продукты которых занимают свои ниши и востребованы на рынке.

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

Обследование инфраструктуры

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

Выявление потребностей бизнеса и IT

Перед внедрением системы резервного копирования необходимо сначала определиться с тем, насколько критичными являются те или иные сервисы. Это позволит в будущем выработать оптимальные, с точки зрения резервного копирования, значения RPO (Recovery Point Objective) и RTO (Recovery Time Objective).

Выработка оптимального плана резервного копирования

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

Внедрение систем резервного копирования

Разворачивание серверов и/или устройств резервного копирования

На этом этапе осуществляется согласование плана резервного копирования. Затем разворачиваются один или несколько серверов для РК, подключаются СХД и/или ленточные библиотеки. Устанавливаются агенты для РК, если необходимо.

Выполнение резервного копирования, решение возникших проблем и корректировка плана резервного копирования

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

Обучение и документация

Оптимизация имеющейся системы резервного копирования

Обследование имеющихся серверов резервного копирования

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

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

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

Создание плана Disaster Recovery

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

Обучение и документация

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

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

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

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

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

Основной принцип работы и варианты функционирования

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

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

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

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

«Родная» программа для резервного копирования Windows

Итак, для начала остановимся на собственном средстве Windows-систем. Многие считают, что встроенная в систему программа резервного копирования Windows работает, мягко говоря, не очень хорошо. В основном ее не хотят использовать только в связи с тем, что утилита затрачивает слишком много времени на создание копии, а сама копия занимает достаточно много места.

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

Получить доступ к этой утилите проще всего можно из стандартной "Панели управления", где выбирается раздел резервного копирования и восстановления. Здесь можно использовать три основных пункта: создание образа, создание диска и настройку копирования. Первый и второй сложностей не вызывают. Зато третий достаточно интересен. Система предложит сохранить копию на съемном носителе, предварительно определив само устройство. Но если посмотреть на параметры, можно сохранить копию и в сети, что прекрасно подойдет для «локалок». Так что в некоторых случаях такая программа для резервного копирования системы станет неплохим средством для создания бэкапа с возможностью последующего восстановления Windows именно из этой копии.

Самые популярные утилиты

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

Acronis True Image.
Norton Ghost.
Back2zip.
Comodo BackUp.
Backup4all.
ABC Backup Pro.
Active Backup Expert Pro.
ApBackUP.
File Backup Watcher Free.
The Copier.
Auto Backup и многие другие.

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

Acronis True Image

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

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

Вот что интересно: утилита показывает достаточно высокие показатели по скорости создания бэкап-копии, времени, сжатию. Так, например, на сжатие данных порядка 20 Гб понадобится в среднем 8-9 минут, а размер конечной копии составить чуть более 8 Гб.

Norton Ghost

Перед нами еще одна мощнейшая утилита. Как обычно, после старта программы запускается "Мастер", помогающий пройти все шаги.

Данная утилита примечательна тем, что с ее помощью можно создать на винчестере скрытый раздел, где будет храниться копия (причем из нее можно восстановить и данные, и систему). Кроме того, в ней можно изменять множество параметров: тип контроль считывания, тип записи, сжатие, число точек для одновременного доступа и т. д. Что же касается производительности, те же 20 Гб приложение сжимает до размера чуть более 7,5 Гб, что по времени занимает около 9 минут. В общем, результат довольно неплохой.

Back2zip

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

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

Comodo BackUp

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

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

Backup4all

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

Эта утилита интересна тем, что позволяет сохранять копии не только на внешних или внутренних носителях, но и в сетях, или даже на FTP-серверах. Здесь имеется достаточно много редактируемых параметров и настроек, среди которых можно выделить четыре метода копирования, а также поддержку Кроме того, интерфейс очень прост, а отображение папок и заданий представлено в виде древовидной структуры по типу "Проводника". Также пользователь может разделять копируемые данные по категориям вроде документов, рисунков и т. д., присваивать каждому проекту собственный ярлык. Естественно, имеется и "Планировщик задач", в котором можно указать, например, создание копий исключительно в момент низкой нагрузки на процессор.

Решения для серверных систем

Для серверных систем и сетей также имеются специализированные программы резервного копирования. Среди всего этого многообразия можно выбелить три самых мощных:

Symantec Backup Exec 11d System Recovery.
Yosemite Backup Standard Master Server.
Shadow Protect Small Business Server Edition.

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

Вместо послесловия

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

АЛЕКСЕЙ БЕРЕЖНОЙ, системный администратор. Главные направления деятельности: виртуализация и гетерогенные сети. Еще одно увлечение помимо написания статей – популяризация бесплатного ПО

Резервное копирование
Теория и практика. Краткое изложение

Чтобы организовать систему резервного копирования наиболее эффективно, нужно выстроить настоящую стратегию сохранения и восстановления информации

Резервное копирование (или, как его еще называют, бэкап – от английского слова «backup») является важным процессом в жизни любой ИТ-структуры. Это парашют для спасения в случае непредвиденной катастрофы. В то же время резервное копирование используется для создания своего рода исторического архива бизнес-деятельности компании на протяжении определенного периода ее жизни. Работать без бэкапа – все равно, что жить под открытым небом – погода может испортиться в любой момент, а спрятаться негде. Но как его правильно организовать, чтобы не потерять важных данных и не потратить на это фантастические суммы?

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

В данной статье речь пойдет как раз об обратном: основное внимание уделено общим понятиям, а технические средства будут затронуты только в качестве примеров. Это позволит абстрагироваться от аппаратного и программного обеспечения и ответить на два главных вопроса: «Зачем мы это делаем?», «Можем ли мы это делать быстрее, дешевле и надежнее?».

Цели и задачи резервного копирования

В процессе организации резервного копирования ставятся две основные задачи: восстановление инфраструктуры при сбоях (Disaster Recovery) и ведение архива данных в целях последующего обеспечения доступа к информации за прошлые периоды.

Классическим примером резервной копии для Disaster Recovery является образ системной партиции сервера, созданный программой Acronis True Image.

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

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

Период хранения данных. У архивных копий он достаточно длительный. В некоторых случаях регламентируется не только требованиями бизнеса, но и законодательно. У копий для аварийного восстановления он сравнительно небольшой. Обычно создают одну или две (при повышенных требованиях к надежности) резервные копии для Disaster Recovery c максимальным интервалом в сутки-двое, после чего они перезаписываются свежими. В особо критичных случаях возможно и более частое обновление резервной копии для аварийного восстановления, например, раз в несколько часов.
Быстрота доступа к данным. Скорость доступа к длительно хранящемуся архиву в большинстве случаев не критична. Обычно необходимость «поднять данные за период» возникает в момент сверки документов, возврата к предыдущей версии и т.д., то есть не в аварийном режиме. Другое дело – аварийное восстановление, когда необходимые данные и работоспособность сервисов должны быть возвращены в кратчайшие сроки. В этом случае скорость доступа к резервной копии является крайне важным показателем.
Состав копируемой информации. В архивной копии обычно содержатся только пользовательские и бизнес-данные за указанный период. В копии, предназначенной для аварийного восстановления, помимо этих данных, содержатся либо образы систем, либо копии настроек операционной системы и прикладного программного обеспечения, а также другой информации, необходимой для восстановления.

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

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

Приведу другой пример. Молодой специалист на протяжении всего периода своей работы создавал посредством программы ntbackup одну-единственную копию файлового сервера под управлением Windows Server 2003, включая данные и System State в общую папку другого компьютера. По причине дефицита дискового пространства эта копия постоянно перезаписывалась. Через некоторое время его попросили восстановить предыдущий вариант многостраничного отчета, который был поврежден при сохранении. Понятное дело, что, не имея архивной истории с выключенным Shadow Copy , он не смог выполнить этот запрос.

На заметку

Shadow Copy , дословно – «теневая копия». Обеспечивает создание мгновенных копий файловой системы таким образом, что дальнейшие изменения оригинала никак не оказывают на них влияния. С помощью данной функции возможно создавать несколько скрытых копий файла за определенный период времени, а также на лету резервные копии файлов, открытых для записи. За работу Shadow Copy отвечает служба Volume Copy Shadow Service.

System State , дословно – «состояние системы». Копирование System State создает резервные копии критических компонентов операционных систем семейства Windows. Это позволяет восстановить инсталлированную ранее систему после разрушения. При копировании System State происходит сохранение реестра, загрузочных и других важных для системы файлов, в том числе для восстановления Active Directory, Certificate Service database, COM+Class Registration database, SYSVOL-директории. В ОС семейства UNIX непрямым аналогом копирования System State является сохранение содержимого каталогов /etc, /usr/local/etc и других необходимых для восстановления состояния системы файлов.

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

При небольших объемах данных и не очень сложной ИТ-инфраструктуре можно попытаться совместить обе эти задачи в одной, например, делать ежедневное полное копирование всех дисковых разделов и баз данных. Но все же лучше различать две цели и подбирать под каждую из них правильное средство. Соответственно под каждую задачу используется свой инструмент, хотя есть и универсальные решения, как тот же пакет Acronis True Image или программа ntbackup

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

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

В одних случаях необходимо прямое восстановление системы на «голое железо» (bare metal). Это можно выполнить, к примеру, с помощью программы Acronis True Image в комплекте с модулем Universal Restore. В этом случае конфигурацию сервера удается вернуть в строй за очень короткий срок. Например, раздел с операционной системой в 20 Гб вполне реально поднять из резервной копии за восемь минут (при условии, что архивная копия доступна по сети 1 Гб/с).

В другом варианте целесообразнее просто «вернуть» настройки на только что проинсталлированную систему, как, например, копирование в UNIX-подобных системах конфигурационных файлов из папки /etc и других (в Windows этому приблизительно соответствует копирование и восстановление System State). Конечно, при таком подходе сервер введется в работу не ранее, чем будет проинсталлирована операционная система и восстановлены необходимые установки, что займет гораздо более длительный срок. Но в любом случае решение, каким быть Disaster Recovery, проистекает из потребностей бизнеса и ресурсных ограничений.

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

Это еще один интересный вопрос, который хотелось бы затронуть. Под системами избыточного резервирования оборудования подразумевается внесение некоторой избыточности в аппаратное обеспечение с целью сохранения работоспособности в случае внезапного выхода из строя одного из компонентов. Прекрасный пример в данном случае – RAID-массив (Redundant Array of Independent Disks). В случае отказа одного диска можно избежать потери информации и безопасно произвести замену, сохранив данные за счет специфичной организации самого дискового массива (подробнее о RAID читайте в ).

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

Кстати

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

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

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

Андрей Васильев, генеральный директор компании Qnap Россия

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

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

Единственное, что может выступить в качестве неполноценной замены резервного копирования для Disaster Recovery, – наличие зеркального резервного сервера с постоянным реплицированием данных с основного сервера на резервный (по принципу Primary  Standby). В этом случае при выходе из строя основного сервера его задачи будут подхвачены резервным, и даже не придется переносить данные. Но такая система является довольно дорогостоящей и трудоемкой при организации. Не забываем еще про необходимость постоянной репликации.

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

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

Понятие «окно бэкапа»

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

Выход при решении этих вышеописанных проблем напрашивается сам собой: перенести запуск процесса создания копий на неактивный период времени, когда взаимное влияние резервного копирования и других работающих систем будет минимально. Этот временной период называется «окно бэкапа». Например, для организации, работающей по формуле 8х5 (пять восьмичасовых рабочих дней в неделю), таким «окном» обычно являются выходные дни и ночные часы.

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

Виды резервного копирования

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

Полное резервное копирование (или Full backup)

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

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

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

Для чего используется этот вид копирования? В случае создания архивных копий он необходим, чтобы сократить расходуемые объемы на устройствах хранения информации (например, сократить число используемых ленточных носителей). Также это позволит минимизировать время выполнения заданий резервного копирования, что может быть крайне важно в условиях, когда приходится работать в плотном графике 24х7 или прокачивать большие объемы информации.

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

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

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

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

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

Топология резервного копирования

Рассмотрим какие бывают схемы резервного копирования.

Децентрализованная схема

Ядром этой схемы является некий общий сетевой ресурс (см. рис. 1). Например, общая папка или FTP-сервер. Необходим и набор программ для резервного копирования, время от времени выгружающих информацию с серверов и рабочих станций, а также других объектов сети (например, конфигурационные файлы с маршрутизаторов) на этот ресурс. Данные программы установлены на каждом сервере и работают независимо друг от друга. Несомненным плюсом является простота реализации этой схемы и ее дешевизна. В качестве программ копирования подойдут штатные средства, встроенные в операционную систему, или программное обеспечение, такое как СУБД. Например, это может быть программа ntbackup для семейства Windows, программа tar для UNIX-like операционных систем или набор скриптов, содержащих встроенные команды SQL-сервера для выгрузки баз данных в файлы резервных копий. Еще одним плюсом является возможность использования различных программ и систем, лишь бы все они могли получить доступ к целевому ресурсу для хранения резервных копий.

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

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

Централизованное резервное копирование

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

Именно по такому принципу работает большинство популярных систем резервного копирования, таких как Symantec Backup Exec, CA Bright Store ARCServe Backup, Bacula и другие (см. рис. 2).

Помимо различных агентов для большинства операционных систем существуют разработки для резервного копирования популярных баз данных и корпоративных систем, например, для MS SQL Server, MS Exchange, Oracle Database и так далее.

Для совсем небольших компаний в некоторых случаях можно попробовать упрощенный вариант централизованной схемы резервного копирования без применения программ-агентов (см. рис. 3). Также эта схема может быть задействована, если не реализован специальный агент для используемого ПО резервного копирования. Вместо этого серверный модуль будет использовать уже существующие службы и сервисы. Например, «выгребать» данные из скрытых общих папок на Windows-серверах или копировать файлы по протоколу SSH c серверов под управлением UNIX-систем. Данная схема имеет весьма существенные ограничения, связанные с проблемами сохранения файлов, открытых для записи. В результате подобных действий открытые файлы будут либо пропущены и не попадут в резервную копию, либо скопированы с ошибками. Существуют различные методы обхода данной проблемы, например, повторный запуск задания с целью скопировать только ранее открытые файлы, но нет ни одного надежного. Поэтому такая схема подходит для применения только в определенных ситуациях. Например, в небольших организациях, работающих в режиме 5х8, с дисциплинированными сотрудниками, которые сохраняют изменения и закрывают файлы перед уходом домой. Для организации такой усеченной централизованной схемы, работающей исключительно в среде Windows, неплохо подходит ntbackup. При необходимости использовать подобную схему в гетерогенных средах или исключительно среди UNIX-компьютеров я рекомендую посмотреть в сторону Backup PC (см. ).

Рисунок 4. Смешанная схема резервного копирования

Что такое off-site?

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

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

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

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

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

Описание резервного копирования в системе Windows, в том числе System State – http://www.datamills.com/Tutorials/systemstate/tutorial.htm .
Описание Shadow Copy – http://ru.wikipedia.org/wiki/Shadow_Copy .
Официальный сайт Acronis – http://www.acronis.ru/enterprise/products .
Описание ntbackup – http://en.wikipedia.org/wiki/NTBackup .
Бережной А. Оптимизируем работу MS SQL Server. //Системный администратор, №1, 2008 г. – С. 14-22 ().
Бережной А. Организуем систему резервного копирования для малого и среднего офиса. //Системный администратор, №6, 2009 г. – С. 14-23 ().
Маркелов А. Linux на страже Windows. Обзор и установка системы резервного копирования BackupPC. //Системный администратор, №9, 2004 г. – С. 2-6 ().
Описание VPN – http://ru.wikipedia.org/wiki/VPN .
Дедупликация данных – http://en.wikipedia.org/wiki/Data_deduplication .

Вконтакте

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

EMC

IBM

Symantec

CommVault

HP

Dell

Quantum

NetApp

CA Technologies

Acronis

Paragon

Выводы

Обследование инфраструктуры

Выявление потребностей бизнеса и IT

Выработка оптимального плана резервного копирования

Внедрение систем резервного копирования

Разворачивание серверов и/или устройств резервного копирования

Выполнение резервного копирования, решение возникших проблем и корректировка плана резервного копирования

Обучение и документация

Оптимизация имеющейся системы резервного копирования

Обследование имеющихся серверов резервного копирования

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

Создание плана Disaster Recovery

Обучение и документация

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

Основной принцип работы и варианты функционирования

«Родная» программа для резервного копирования Windows

Самые популярные утилиты

Acronis True Image

Norton Ghost

Back2zip

Comodo BackUp

Backup4all

Решения для серверных систем

Вместо послесловия

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам:

Ваш комментарий (необязательно):