Большой бэкап для маленькой компании

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

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


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


В этой связи одним из ключевых становится вопрос организации/внедрения на предприятиях системы резервного копирования и восстановления (РКиВ). Но у малого бизнеса есть своя специфика, которая, в конечном итоге будет влиять на построение и поддержку полноценной системы РКиВ. Заключается в она в том, что здесь практически нет специализированного прикладного ПО и СУБД, часто используются разнообразные OpenSource (бесплатные) решения. Если есть виртуализация, то строится она на бесплатных версиях гипервизоров, без внедрения серверов централизованного управления виртуальными ресурсами. Зачастую такие компании не имеют своего ИТ-персонала. Все задачи по внедрению и администрированию возлагают на приглашенных специалистов.


С одной стороны всё это может упростить задачу по построению системы РКиВ, но с другой – необходимо решение, которое бы корректно, в автономном режиме, работало со всем этим « зоопарком». И опять же, основной вопрос любого решения для СМБ – строгий контроль затрат на его внедрение, так как стоимость проприетарного решения от именитых вендоров, в некоторых случаях, может превосходить стоимость всей ИТ-инфраструктуры заказчика. Помимо этого необходимо учитывать, что решение по резервному копированию должно покрывать всю серверную инфраструктуру заказчика. Плюс к этому, заказчикам часто интересны многие функциональные возможности, которые присутствуют только в платных версиях систем резервного копирования (возможности full, differential, incremental, работа по расписанию, возможность deduplication данных и т.п.).


Именно с такими запросами и специфическими требованиями заказчик и обратился к нашим специалистам. И с этим набором входных данных мы приступили к реализации проекта. На момент разработки решения у заказчика была развернута классическая (как для офиса СМБ) схема серверной инфраструктуры – физический сервер виртуализации, на базе бесплатной версии VMware ESXi, с несколькими гостевыми виртуальными серверами. Учитывая вышеуказанную специфику, нами изначально делался акцент на по возможности бесплатные, либо частично бесплатные решения и использование классической схемы резервного копирования на основе полных и разностных копий. Эта схема заключается в создании полных резервных копий данных (виртуальных машин) и цепочки зависимых от нее инкрементальных/дифференциальных копий.


На просторах интернета доступно много ПО для резервного копирования VMware ESX, и первым, на котором мы остановили свой выбор – был Veeam Backup Free Edition, который обладает богатыми функциональными возможностями резервного копирования и восстановления виртуальных машин. При более тщательном знакомстве с этим продуктом оказалось, что он не поддерживает бесплатные версии VMware ESXi. А при детальном углублении в разработку решения мы столкнулись с еще одним ограничением, которое присутствуют в бесплатных версиях VMware ESXi – ограниченный доступ к vStorage APIs for Data Protection (VADP). Не сильно углубляясь в детали: VADP – технология, которую используют сторонние продукты резервного копирования и которая позволяет централизованно делать полные и инкрементальные резервные копии виртуальных машин, без установки агентов в гостевые ОС. Без полноценного доступа к этой функции становится невозможным выполнить инкрементальный бэкап виртуальных машин.


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


Было рассмотрено несколько альтернативных решений – Thinware vBackup Client, Unitrends Backup Free Edition; но все они требовали для своей работы установки дополнительного сервера под MS Windows, в качестве сервера управления системой РКиВ. Минусы такого решения – выделение дополнительных физических либо виртуальных ресурсов под управляющий сервер, плюс дополнительные затраты на лицензирование.


В конечном итоге мы остановили свой выбор на XSIBаckup – утилите резервного копирования, работающей как сервис на уровне VMWare ESXi, и которая не требует установки дополнительных серверов. XSIBаckup позволяет создавать полные резервные копии (клоны) и мгновенно восстанавливать данные виртуальных машин, а, благодаря интеграции с ESXi cron, задачи по резервному копированию могут выполняться в автономном режиме. Вопрос с созданием полных копий виртуальных машин мы, таким образом, решили.


Но оставался открытым вопрос о возможности создания более частых инкрементных/дифференциальных копий данных, в основном – с файловых ресурсов. Нужно было простое решение по резервированию данных, которое не добавляло бы дополнительную нагрузку на сервер виртуализации и не требовало установку агентов на гостевые системы. Таким решением оказался OpenSource продукт – BackupPC, который мы установили на один из существующих виртуальных серверов. BackupPC написан на Perl и извлекает резервные данные с виртуальных серверов, используя стандартные протоколы smb, ssh/rsh/nfs, rsync. Также есть возможности по автоматизации и сжатию данных. Этот продукт и был применен в качестве сервера РКиВ для общих файловых ресурсов.


Сами резервные копии предложено было сохранять на внешних носителях. Для этих целей был приобретен небольшой внешний СХД и подключен по iSCSI к серверу виртуализации. Дисковое пространство СХД разделили на 2 логических раздела, один – для хранения клонов ВМ; второй – для резервных копий, выполняемых BackupPC. В итоге решение получилось комплексным и состоит, как мы уже упоминали, из двух программных компонентов: XSIBackup – ПО, установленное на сервере виртуализации ESXi и предназначенное для создания резервных копий(клонов) виртуальных машин. BackupPC – высокопроизводительное OpenSource ПО корпоративного уровня для резервного копирования Linux, Windows и MacOSX ПК и серверов. ПО BackupPC установлено на одном из существующих виртуальных серверов.


Аппаратные составляющие реализованного решения системы РКиВ имеют следующий вид:


1. Сервер HP ProLiant ML 350 – сервер виртуализации ESXi.

2. Сетевое дисковое хранилище NAS Synology (2 жестких диска – собраны в RAID1).

Дисковое пространство NAS Synology разбито на два логических диска: iSCSI LUN1 - esx-target01. iSCSI LUN2 – backup-target01.

LUN1 – подключен к серверу виртуализации ESXi и представлен на сервере в виде отдельного iSCSI-хранилища «nas_backup_storage». LUN2 – подключен к виртуальному серверу и презентован как iSCSI-диск /dev/sdb.


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


Рисунок 1. Схема системы РКиВ


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


XSIBackup


Встроенный в ЕSXi планировщик задач (cron) раз в месяц запускает процесс XSIBackup, который, в свою очередь, создает полные копии (клоны) инфраструктурных виртуальных серверов. Место хранения клонов – диск nas_backup_storage (esx-target01), подключенный по iSCSI к серверу виртуализации.


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


BackupPC


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


Каждую субботу (начиная с 20:00) выполняется создание полной резервной копии файлового сервера (содержимое общедоступных папок): ежедневно (кроме субботы), в 20:00 выполняется создание инкрементальных резервных копий. Место хранения резервных копий – диск dev/sdb (iSCSI LUN2 - backup-target01), смонтированный в папку /mnt/iscsi_nas. Глубина бэкапа - 2 недели.


Сетевое дисковое хранилище NAS Synology


В целях экономии электроэнергии и дополнительной безопасности резервных копий настроено автоматическое включение/выключение сетевого дискового хранилища NAS Synology. В это же время автоматически отключается/подключается iscsi-диск к BackupPC серверу.


Процесс запускается встроенным планировщиком задач:

# crontab -l

# Everyday mount/umount iscsi NAS LUN

15 16 * * 2-6 /usr/bin/mount -a

22 45 * * 1-5 /usr/bin/umount /mnt/iscsi_nas


Процесс восстановления


Достаточно скопировать и запустить клон виртуальной машины в его оригинальное месторасположение на сервере виртуализации. Если требуется восстановить отдельные файлы или папки с файловых ресурсов – их можно восстановить из консоли управления BackupPC (как в оригинальное, так и в любое произвольное место). И даже в случае форс-мажорных обстоятельств (или потери основного сервера), заказчику достаточно отключить NAS Synology и оперативно с ним покинуть помещение. Свою ИТ-инфраструктуру он сможет быстро развернуть (из резервных копий) в другом месте и на другом оборудовании/сервере.


Евгений Середович