Резервное копирование виртуальных машин

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

Резервное копирование виртуальных машин

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

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

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

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

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

Вариант 1. Копирование изнутри

Первый способ полностью аналогичен работе с физическими серверами. То есть, бэкап осуществляется через операционную систему виртуальной машины. Для этого можно использовать любое программное обеспечение для резервного копирования. Например, для ARCServe [1] при сохранении ресурсов файл-сервера достаточно установить программу агента и создать задание. Если имеем дело с более сложными приложениями, например MS SQL Server или Exchange Server, устанавливаем агента и дело, как говорится, в шляпе. Не сложнее дело обстоит и с копированием всей системы целиком в целях Disaster Recovery (аварийного восстановления). Например, при помощи Acronis True Image Backup & Restore снимаем образ нужных разделов или всего сервера целиком.

Какие плюсы у этого подхода?

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

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

А в чем же минусы?

Как известно, идеальных систем не бывает. И в этом случае тоже есть немалый изъян – при восстановлении необходимо создать виртуальную машину вновь. То есть, сначала готовим гостевую, в точности соответствующую исходной, а уже потом отправляем в нее данные. При этом необходимо учесть не только общие характеристики: количество процессоров, объем ОЗУ (RAM), размер виртуального жесткого диска, но и гораздо более тонкие нюансы. Например, в какой resource pool входила виртуальная машина, был ли настроен overcommitting и с какими параметрами, где находился файл подкачки, был ли настроен автостарт этой виртуалки и в какую очередь и так далее.

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

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

Статью целиком читайте в журнале «Системный администратор», №10 за 2013 г. на страницах 27-31.

Комментарии могут оставлять только зарегистрированные пользователи