Стратегии резервного копирования

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

Суть концепции резервного копирования виртуальных систем заключается в полном сохранении гостевых систем через хост-систему в виде моментальных снимков (Snapshot). Благодаря этому не приходится оснащать каждую виртуальную машину дополнительными агентами резервного копирования. Сохранение данных возможно сразу после установки виртуальной машины, поскольку оно реализуется через (физическую) хост-систему на сервер резервного копирования. VMware и Citrix XenServer предоставляют для своих виртуальных решений специализированные интерфейсы API резервного копирования, посредством которых соответствующее программное обеспечение получает доступ к уровню управления гипервизора. В результате создание резервных копий отдельных виртуальных машин становится независимым от физического хоста. Достаточно лишь однажды указать серверу резервного копирования ферму VMware или Citrix XenServer, чтобы новые хост-системы или виртуальные машины регистрировались через нее автоматически, после чего можно будет выполнять их резервное копирование (см. Рисунки 1 и 3).

Рисунок 1. При наличии соответствующего интерфейса API сервер резервного копирования автоматически распознает новые хосты и гостевые системы.

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

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

ОГРАНИЧЕНИЯ ПРИ ИСПОЛЬЗОВАНИИ МОМЕНТАЛЬНЫХ СНИМКОВ

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

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

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

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

Единственная возможность получения полноценной резервной копии при таком сценарии — традиционное использование онлайн-клиента для баз данных или систем коллективной работы, который устанавливается на виртуальную гостевую систему (см. Рисунок 2). Этот клиент создает резервную копию без остановки работы системы и отправляет ее на носитель через локальную сеть, а не через гипервизор.

Рисунок 2. Пример использования API резервного копирования: при сохранении данных для гостевой системы на Citrix XenServer отображаются все гостевые системы, располагающиеся в ферме Citrix, при- чем независимо от их физических хост-систем.

Еще одно слабое место — восстановление отдельных файлов. Метод сохранения данных через API резервного копирования предоставляет полный снимок всей гостевой системы, поэтому в случае необходимости понадобится восстанавливать весь снимок, чтобы получить доступ к содержащимся в нем файлам. На практике это означает, что администратору придется, к примеру, восстановить снимок объемом 200 Гбайт, чтобы восстановить файл размером 2 Мбайт.

Эта проблема частично снимается при использовании VMware в качестве гипервизора с гостевыми системами Windows. Системы резервного копирования, такие как SEP Sesam, могут восстанавливать отдельные файлы с помощью API и собственных логических схем, правда, это функционирует только с гостевыми системами Windows и не работает с Linux, Unix или NetWare.

С помощью службы Volume Shadow Copy Service (VSS) компании Microsoft можно создавать целостные моментальные снимки без прерывания работы системы, причем это действительно как для гостевых операционных систем, так и для баз данных или систем коллективной работы, запущенных на виртуальной машине, поскольку перед созданием снимка соответствующая команда VSS «замораживает» базу данных или систему коллективной работы. Эта технология пригодна для всех приложений с поддержкой VSS, однако и в этом случае создается моментальный снимок всего сервера MS-SQL или MS Exchange, так что при необходимости приходится восстанавливать его полностью.

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

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

РАСПРЕДЕЛЕННЫЕ СРЕДЫ

В средах Windows очень важно учитывать еще один момент: данные все большего числа приложений Windows распределяются по разным серверам. Так, системе SharePoint, как правило, требуется ферма из трех серверов: сервер для контроллеров домена (Domain Controller), сервер баз данных и сервер Web.

Резервное копирование, осуществляемое через интерфейс API гипервизора с помощью VSS, предоставляет целостный моментальный снимок одного-единственного сервера, к примеру сервера базы данных MS SQL или MS Exchange. Однако этот снимок не будет соотноситься с данными, полученными, например, от сервера с контроллером домена. В результате при необходимости аварийного восстановления данных возникнут серьезные затруднения, так как на указанных серверах представлены массивы данных на разные моменты времени и синхронизировать их невозможно, поскольку для создания резервных копий не использовался интерфейс базы данных. Аналогичные проблемы могут возникнуть, если служба каталогов Active Directory распределена по нескольким серверам. Поэтому во всех приведенных примерах рекомендуется осуществлять резервное копирование через специализированные клиенты — они поддерживают сохранение без остановки работы систем, и их можно инсталлировать прямо на виртуальные гостевые системы.

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

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

Хуберт Швайнесбайн — директор по работе с каналом продаж в регионе ЕМЕА в компании SEP.