Резервное копирование виртуальных машин — это не то же самое, что бэкап файлов на сервере. Виртуальная машина — целый образ со своей ОС, приложениями и состоянием, и от того, как его копируют и восстанавливают, напрямую зависит, сколько бизнес простоит после сбоя, шифровальщика или ошибки администратора. Разберём, чем бэкап виртуализации отличается от обычного, какие есть способы защиты, что такое правило 3-2-1 и как резервное копирование устроено в платформе AirCloud.
Чем резервное копирование ВМ отличается от обычного
Когда копируют файлы, достаточно сохранить данные. С виртуальной машиной задача шире: нужно сохранить весь образ — диск, конфигурацию, а в идеале и согласованное состояние приложений внутри. Отсюда несколько особенностей:
- Образ целиком. Восстанавливать приходится не отдельные файлы, а работоспособную машину — чтобы она поднялась и сразу заработала.
- Консистентность приложений. Бэкап, снятый «на лету», может застать базу данных в промежуточном состоянии. Нужна согласованность на уровне приложения, а не просто «слепок диска».
- Нагрузка и масштаб. Виртуальных машин десятки и сотни — копирование не должно ронять производительность кластера и должно укладываться в окно резервного копирования.
Поэтому бэкап — часть архитектуры платформы, а не отдельная «пристройка». Общий обзор платформы — в разборе системы виртуализации.
Способы защиты: снапшоты, бэкап и репликация
На практике используют три механизма, и они дополняют друг друга:
- Снапшоты. Мгновенные снимки состояния машины. Позволяют быстро откатить её к недавнему состоянию — удобно перед обновлением или рискованной операцией. В AirCloud снапшоты бывают с памятью и классические, их можно выстраивать в ветки. Но снапшот хранится рядом с самой машиной и не заменяет резервную копию: если выйдет из строя хранилище, пропадут и машина, и её снапшоты.
- Полный и инкрементный бэкап. Полная копия образа плюс последующие инкременты — только изменения. Хранится отдельно от продуктивного хранилища. Это и есть настоящая защита от потери данных.
- Репликация. Поддержание копии машины на другой площадке для быстрого переключения. Защищает от отказа площадки, но реплика повторяет и логические ошибки, поэтому не отменяет бэкап.
Выбор определяют два показателя: RPO — сколько данных допустимо потерять, глубина «отката во времени», — и RTO — за какое время нужно восстановиться. Чем строже требования, тем чаще копии и тем важнее репликация.
Правило 3-2-1 и согласованность копий
Базовый ориентир для надёжного резервного копирования — правило 3-2-1: хранить три копии данных на двух разных носителях, и одну копию — вне основной площадки. Это защищает сразу от отказа диска, аварии хранилища и потери всего дата-центра.
Второй важный момент — консистентность. Согласованная на уровне приложения копия фиксирует корректное состояние — например, «замораживает» базу данных на момент снимка. Копия «как при внезапном выключении» — просто слепок диска. Для критичных систем нужен именно первый вариант, иначе восстановление может оказаться нерабочим.
Резервное копирование в платформе AirCloud
В AirCloud резервное копирование вынесено в отдельный модуль — это следствие микросервисной архитектуры платформы. Благодаря этому возможны два сценария:
- Использовать встроенный сервис — если у заказчика ещё нет своей системы резервного копирования. Задания резервного копирования настраиваются из той же консоли, что и всё остальное; параметры заданий — согласованность на уровне приложений, место и срок хранения копий, проверка восстановления — уточняем при проектировании.
- Подключиться к уже работающей у заказчика системе. Если в инфраструктуре стоит сторонняя система резервного копирования, платформа может работать с ней вместо собственного модуля — и бэкап остаётся в привычной заказчику технологии. Совместимость с вашей системой резервного копирования проверяем на пилоте; официальной сертификации вендоров пока нет.
Это и есть практическая гибкость: платформа встраивается в существующий «зоопарк» инфраструктуры, а не требует выбросить то, что уже работает. Для монолитных систем «вытащить одну шестерёнку» обычно сложно — модульная архитектура позволяет заменить встроенный модуль внешней системой, совместимость с которой проверена на пилоте.
> Резервное копирование у нас — отдельный модуль. Если у заказчика уже стоит своя система, мы можем подключиться к ней вместо своей — после проверки совместимости на пилоте бэкап идёт в привычной ему технологии.
>
> — команда разработки AirCloud
Резервные копии встроенного модуля по умолчанию шифруются. Ключи шифрования нужно резервировать отдельно от инсталляции — иначе при её потере копии не восстановить; порядок экспорта ключей уточняем при проектировании. Если копии нужно выносить наружу, опция без шифрования включается отдельно.
Не только бэкап: восстановление управления через Event Sourcing
Помимо классического резервного копирования, в платформе работает механизм Event Sourcing: про каждый ресурс, в том числе виртуальную машину, хранится вся цепочка произошедших событий. Это позволяет вернуть незавершённую операцию к исходному состоянию и восстановить конфигурацию управления, если что-то пошло не так.
Если операция в инфраструктуре не достигла желаемого конечного состояния — например, из-за ошибки настройки — система возвращает её к исходной точке. На реальных инсталляциях это уже не раз спасало от последствий человеческого фактора. Содержимое дисков и памяти ВМ так не восстанавливается — только из резервной копии: такой откат не заменяет бэкап, но закрывает класс проблем, которые обычное резервное копирование не ловит. Как это устроено на уровне всего управляющего слоя — в статье про кластер виртуализации.
Что бэкапить в VDI
Для виртуальных рабочих столов схема своя. Закреплённые машины сотрудников — живут до удаления, их берут в общую политику резервного копирования наравне с серверами. Плавающие машины пересоздаются из золотой реплики по политике пула — данные, оставшиеся внутри такой машины, при пересоздании теряются, и бэкапить её бессмысленно; вместо этого данные пользователей выносят на сетевые папки и перемещаемые профили, а в резервную копию идут сама реплика и эти папки.
Частые ошибки при резервном копировании ВМ
Большинство инцидентов с потерей данных — это не «не делали бэкап вообще», а делали его неправильно. Вот что встречается чаще всего:
- Снапшоты принимают за бэкап. Снимок хранится рядом с машиной — при отказе хранилища исчезают и машина, и снимки.
- Нет копии вне площадки. Если все копии в одном дата-центре, пожар, затопление или шифровальщик с правами администратора уничтожат и продуктив, и бэкап разом.
- Восстановление ни разу не проверяли. Бэкап, из которого не пробовали восстановиться, — это не бэкап, а надежда. Регулярный тест восстановления обязателен.
- Игнорируют консистентность приложений. Копия «на лету» без согласования с базой может оказаться нерабочей при восстановлении.
- Копия на то же хранилище. Бэкап на тот же массив, что и продуктив, не защищает от отказа этого массива.
- Не мониторят задания. Молча «отвалившийся» по ночам бэкап обнаруживают только в момент аварии — когда восстанавливать уже нечего.
Как подойти к резервному копированию ВМ
Коротко, рабочая схема защиты виртуальных машин выглядит так:
- снапшоты — для быстрых откатов перед изменениями, но это не бэкап;
- полный и инкрементный бэкап на отдельном хранилище — основная защита данных;
- репликация на вторую площадку — против отказа дата-центра;
- правило 3-2-1 и согласованные копии — как обязательный минимум;
- гибкая интеграция: собственный модуль AirCloud либо привычная заказчику система, совместимость с которой проверена на пилоте.
Резервное копирование дополняет, а не заменяет отказоустойчивость и защиту рабочих мест. Хотите заранее заложить корректную схему под ваши RPO и RTO — напишите нам.