Снапшот и бэкап: разбираемся в защите данных

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

На практике эти механизмы нередко путают. На самом деле у каждого подхода своя задача. В этой статье разберемся, чем они отличаются, какие требования предъявляются к современной системе резервного копирования и как эти принципы реализованы при совместной работе VMmanager и RuBackup.

Снапшот фиксирует состояние виртуальной машины в определенный момент времени. После его создания записи выполняются через механизм copy-on-write или redirect-on-write — в зависимости от реализации платформы. Поэтому снимок создается за несколько секунд: данные не копируются целиком.

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

Снапшоты оптимально подходят для временных задач:

Сам по себе один снапшот обычно не становится серьезной нагрузкой для инфраструктуры. Проблемы могут появиться, если долго не удалять их после создания.

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

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

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

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

Риски также может создать и удаление снапшотов — системе может потребоваться объединить накопленные изменения с основным хранилищем. При больших объемах данных это сопровождается дополнительными операциями чтения и записи и увеличивает нагрузку на систему хранения.

Итак, вы успешно создали снапшот, но его не всегда можно использовать для восстановления приложения. Снапшот фиксирует состояние виртуальной машины в конкретный момент. Проблема в том, что приложение не всегда считает это состояние консистентным. В результате после восстановления можно получить состояние, эквивалентное аварийному завершению работы системы — так называемый crash-consistent snapshot.

Для критичных сервисов предпочтительнее application-consistent backup — когда перед созданием копии система согласует состояние приложения и файловой системы, завершает или приостанавливает необходимые операции и сбрасывает буферизованные данные на диск.

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

Для полноценного резервного копирования требуется отдельная система.

Теперь самое время разобрать, какой должна быть современная и безопасная система резервного копирования.

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

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

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

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

Резервная копия виртуальной машины ценна только в том случае, если после восстановления запустятся необходимые сервисы. Для некоторых приложений crash-consistent-копии достаточно. Например, современные СУБД обычно умеют восстанавливаться с помощью журналов транзакций. Но и этот процесс требует дополнительного времени.

Но для критичных систем может потребоваться копирование с консистентностью на уровне приложения — application-consistent backup.

Хранение резервных копий в одном контуре с продуктивной инфраструктурой делает их уязвимыми: современные программы-вымогатели стремятся уничтожить бэкапы, доступные через общую сеть или учетные записи. Для защиты применяется правило 3-2-1-1-0. Оно требует наличия как минимум одной неизменяемой или физически изолированной копии.

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

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

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

Репликацию часто рассматривают как еще один способ резервирования. Однако ее назначение отличается от резервного копирования.

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

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

Теперь посмотрим, как описанные принципы реализуются на практике в связке VMmanager и RuBackup. Детальнее погрузимся не в полный обзор возможностей продукта, а в механизмы, которые влияют на надежность резервного копирования.

Мы уже говорили выше, что от современных систем резервного копирования ожидают работу без специальных агентов. RuBackup интегрируется с VMmanager на уровне API.

В такой связке RuBackup получает полную информацию о виртуальной инфраструктуре из VMmanager. Процесс создания резервных копий происходит без остановки ВМ, а интеграция на уровне гипервизора обеспечивает высокую скорость и минимальное влияние на производительность.

Подход упрощает сопровождение инфраструктуры и снижает вероятность пропуска резервного копирования из-за проблем с отдельными агентами.

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

В решении реализована поточная глобальная дедупликация на блочных устройствах (дисках, RAID, СХД). При этом система позволяет настраивать несколько дедупликационных пулов с индивидуальными параметрами, такими как размер блока, алгоритм и длина хэш-функции.

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

RuBackup поддерживает полные, инкрементальные и дифференциальные резервные копии, позволяя объединять их в единые политики хранения.

От современных систем резервного копирования ожидают возможности использовать несколько типов хранилищ. Так, RuBackup поддерживает хранение копий в СХД, ленточных библиотеках или облаке S3.

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

RuBackup включен в реестр российского программного обеспечения и сертифицирован ФСТЭК России по 4 уровню доверия. Это позволяет использовать решение организациям, предъявляющим повышенные требования к защите данных.

Интеграция VMmanager и RuBackup работает напрямую через API и не требует сторонних модулей. Система резервного копирования автоматически получает доступ к виртуальной инфраструктуре, позволяя централизованно управлять бэкапами ВМ.

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

RuBackup также выполняет верификацию созданных резервных копий и позволяет выявлять проблемы с целостностью данных до возникновения аварии.

При восстановлении виртуальной машины речь идет не только о самих виртуальных дисках: система восстанавливает связанные параметры конфигурации, необходимые для запуска ВМ в инфраструктуре.

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

Снапшот, резервная копия и репликация решают разные задачи:

Снапшот нужен прежде всего для быстрого отката и временной фиксации состояния виртуальной машины.

Резервное копирование позволяет восстановить данные из сохраненного состояния.

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

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