5.1 Причины резервного копирования й восстановления данных
Резервное копирование проводится по ряду причин, которые обычно оправдывают инвестиции, вложенные в соответствующее оборудование. Основная цель создания резервных копий – это обеспечение гарантированной доступности данных. Чем важнее постоянный доступ к данным, тем больше инвестиций потребуется. Например, одна из популярных методик резервного копирования заключается в зеркальном копировании дисков, при котором каждая операция записи дублируется для второго диска, что гарантирует доступность данных при отказе в работе первого диска.
Кроме того, архивирование данных проводится для выполнения различных корпоративных требований, при которых данные не должны быть обязательно доступными мгновенно, но могут быть затребованы позднее. В таких случаях доступность данных должна быть обеспечена в течение разумного периода времени, который измеряется в часах, днях или неделях.
Резервные копии иногда используются для перемещения данных, например при создании удаленного центра хранения данных в другом географическом регионе. Такой же причиной будет перенос данных на новое аппаратное обеспечение или, что случается реже, на другую серверную платформу.
5.2 Проблемы при резервном копировании
Перед подробным обсуждением различных способов резервного копирования и восстановления желательно разобраться в проблемах, которые необходимо решить для получения требующегося результата. Далее перечислены основные проблемы.
Сокращение промежутка времени, который называется окном резервного копирования, в течение которого должна быть завершена операция резервного копирования.
Постоянно увеличивающееся количество программных интерфейсов приложений (API), которые должны поддерживаться приложениями резервного копирования.
Невозможность резервного копирования файлов, которые открыты и активно используются приложениями.
Более подробно эти проблемы рассматриваются в разделах 5.2.1–5.2.3.
Исторически сложилось так, что серверные приложения запускались только в рабочее время. Операции резервного копирования соответственно выполнялись в нерабочее время, т.е. ночью, когда работу приложений можно остановить, не оказывая влияния на пользователей. Как только работа приложения прекращена, сервер можно отключить от сети и провести резервное копирование данных. С этим подходом связаны две проблемы.
Значительное увеличение объема данных усложняет завершение резервного копирования в выделенный период времени. Как ни странно, но запись на магнитную ленту в контексте как затрачиваемых машино- часов, так и времени обслуживающего персонала весьма неэффективна. Необходимо найти ленту, вставить ее в накопитель и перемотать на нужную позицию. Как только позиция будет найдена, запись данных на ленту будет проводиться намного медленнее, чем на жесткий диск. Интерфейсы жестких дисков поддерживают запись со скоростью на порядок больше 80 Мбайт/с, а самые быстрые накопители на магнитной ленте поддерживают максимальную скорость передачи 30 Мбайт/с. Для управления несколькими накопителями могут использоваться роботизированные библиотеки, которые весьма недешевы и помогают сократить затраты времени только на поиск и загрузку ленты. Такие библиотеки не в состоянии увеличить скорость чтения данных или их записи на ленту.
Вторая проблема заключает в том, что все больше приложений, а также создаваемые, управляемые и модифицированные ими данные рассматриваются как важные, если не критические, для выживания компании в конкурентной среде. Это означает, что время, в течение которого можно отключить сервер от сети для резервного копирования, сокращается.
Потребители используют все больше корпоративных приложений, которые очень редко, если это вообще возможно, разрешено останавливать для резервного копирования. По этой причине каждый поставщик приложений предоставляет API для резервного копирования и восстановления файлов с данными приложения. Хотя создание таких API выглядит весьма оптимистично, на самом деле ситуация только ухудшилась.
На рис. 5.1 представлена проблема поддержки все увеличивающегося количества API для резервного копирования и восстановления данных. Как видите, потребители обычно используют несколько приложений, и очень часто применяется несколько версий одного и того же приложения. Каждый поставщик систем резервного копирования должен создавать программный код, использующий API, предоставленный для каждого корпоративного приложения. Поскольку многие поставщики приложений отдельно лицензируют агенты резервного копирования для различных приложений, сам процесс отслеживания лицензий на программное обеспечение и их стоимости может вызвать смятение у менеджера отдела информационных технологий. Более того, следует учесть развертывание инфраструктуры, обучение персонала и четкое выполнение инструкций, необходимых для эффективного резервного копирования.