Резервное копирование виртуальных машин: как устроен бэкап виртуализации

Резервное копирование виртуальных машин — это не то же самое, что бэкап файлов на сервере. Виртуальная машина — это целый образ со своей ОС, приложениями и состоянием, и от того, как его копируют и восстанавливают, напрямую зависит, сколько бизнес простоит после сбоя, шифровальщика или ошибки администратора. В этом материале разберём, чем бэкап виртуализации отличается от обычного, какие есть способы (снапшоты, полный и инкрементный бэкап, репликация), что такое правило 3-2-1 и как резервное копирование устроено в платформе Inscale — включая возможность использовать уже привычный заказчику Кибер Бэкап.

Чем резервное копирование ВМ отличается от обычного

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

• Образ целиком. Восстанавливать приходится не отдельные файлы, а работоспособную ВМ — чтобы она поднялась и сразу заработала.
• Консистентность приложений. Бэкап, снятый «на лету», может застать базу данных в промежуточном состоянии. Нужна согласованность на уровне приложения (application-consistent), а не просто «слепок диска».
• Нагрузка и масштаб. Виртуальных машин десятки и сотни — копирование не должно ронять производительность кластера и должно укладываться в окно резервного копирования.

Поэтому бэкап — это часть архитектуры платформы виртуализации, а не отдельная «пристройка». Общий обзор платформы — в разборе российской системы виртуализации.

Способы защиты: снапшоты, полный бэкап и репликация

На практике используют три механизма, и они дополняют друг друга:

• Снапшоты (мгновенные снимки). Позволяют быстро откатить ВМ к недавнему состоянию — удобно перед обновлением или рискованной операцией. Но снапшот хранится рядом с самой ВМ и не заменяет резервную копию: если выйдет из строя хранилище, пропадут и ВМ, и её снапшоты.
• Полный и инкрементный бэкап. Полная копия образа плюс последующие инкременты (только изменения). Хранится отдельно от продуктивного хранилища — это и есть настоящая защита от потери данных.
• Репликация. Поддержание копии ВМ на другой площадке для быстрого переключения. Защищает от отказа площадки, но реплика повторяет и логические ошибки, поэтому не отменяет бэкап.

Выбор определяют два показателя: RPO (сколько данных допустимо потерять — глубина «отката во времени») и RTO (за какое время нужно восстановиться). Чем строже требования, тем чаще копии и тем важнее репликация.

Правило 3-2-1 и согласованность копий

Базовый ориентир для надёжного резервного копирования — правило 3-2-1: хранить 3 копии данных на 2 разных носителях, и 1 копию — вне основной площадки. Это защищает сразу от отказа диска, аварии хранилища и потери всего ЦОДа.

Второй важный момент — консистентность. Application-consistent бэкап фиксирует согласованное состояние приложений (например, корректно «замораживает» БД на момент снимка), тогда как crash-consistent — это просто слепок, как при внезапном выключении. Для критичных систем нужен именно первый вариант, иначе восстановление может оказаться нерабочим.

Резервное копирование в платформе Inscale

В Inscale резервное копирование вынесено в отдельный модуль — это следствие микросервисной архитектуры платформы. Благодаря этому возможны два сценария:

• Использовать встроенный сервис Inscale — если у заказчика ещё нет своей системы резервного копирования.
• Подключиться к уже работающему у заказчика решению. Например, если в инфраструктуре установлен популярный в России Кибер Бэкап, платформа может работать с ним вместо собственного модуля — и резервное копирование остаётся в привычной заказчику технологии.

Это и есть практическая гибкость: платформа встраивается в существующий «зоопарк» инфраструктуры, а не требует выбросить то, что уже работает. Для монолитных систем «вытащить одну шестерёнку» обычно невозможно — у микросервисной платформы такой проблемы нет.

Такой подход делает Кибер Бэкап для платформы виртуализации полноценным внешним модулем резервного копирования: заказчик не отказывается от привычного инструмента, а платформа просто отдаёт ему задачи бэкапа.

Не только бэкап: откат через event sourcing

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

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

Устойчивость хранения и геораспределённость

Надёжность восстановления зависит и от того, как устроено само хранение состояния кластера. В Inscale все узлы кластера управления хранят данные консистентно, а кластер может работать геораспределённо — был реальный опыт инсталляции с географически разнесёнными узлами в разных городах. Пока жив хотя бы один узел, кластер управления восстанавливается из актуальных персистентных данных.

Подробнее про архитектуру отказоустойчивости — в материале про систему виртуализации и требования приказа ФСТЭК № 117.

Частые ошибки при резервном копировании ВМ

Большинство инцидентов с потерей данных — это не «не делали бэкап вообще», а делали его неправильно. Вот что встречается чаще всего:

• Снапшоты принимают за бэкап. Снимок хранится рядом с ВМ — при отказе хранилища исчезают и машина, и снимки. Снапшот — это про быстрый откат, а не про резервную копию.
• Нет копии вне площадки. Если все копии в одном ЦОДе, пожар, затопление или шифровальщик с правами администратора уничтожат и продуктив, и бэкап разом.
• Восстановление ни разу не проверяли. Бэкап, из которого не пробовали восстановиться, — это не бэкап, а надежда. Регулярный тест восстановления обязателен.
• Игнорируют консистентность приложений. Копия «на лету» без согласования с БД может оказаться нерабочей при восстановлении.
• Копия на то же хранилище. Бэкап на тот же массив, что и продуктив, не защищает от отказа этого массива.
• Не мониторят задания. Молча «отвалившийся» по ночам бэкап обнаруживают только в момент аварии — когда восстанавливать уже нечего.

Правильная схема закрывает все эти пункты: отдельное хранилище, копия вне площадки по правилу 3-2-1, application-consistent копии и регулярная проверка восстановления.

Как подойти к резервному копированию ВМ

Коротко, рабочая схема защиты виртуальных машин выглядит так:

• снапшоты — для быстрых откатов перед изменениями (но это не бэкап);
• полный и инкрементный бэкап на отдельном хранилище — основная защита данных;
• репликация на вторую площадку — против отказа ЦОДа;
• правило 3-2-1 и application-consistent копии — как обязательный минимум;
• гибкая интеграция: собственный модуль Inscale либо привычный заказчику Кибер Бэкап.

Если планируете переход на российскую платформу и хотите заранее заложить корректную схему резервного копирования — напишите нам, поможем подобрать сценарий под ваши RPO/RTO.