Что на самом деле защищает наши данные? Снапшоты, которые создаются за секунды и позволяют мгновенно откатиться к предыдущему состоянию? Регулярные резервные копии, которые хранятся на отдельном хранилище? Или репликация, которая обеспечивает непрерывность работы даже при сбое площадки?
Каждая из этих технологий решает свою задачу. Но бывает и такое, что снапшоты используют как бэкапы, бэкапы хранят вместе с основными данными, а репликацию считают полноценной заменой резервному копированию.
В этой статье расскажем, почему снапшот — это вообще не бэкап, почему репликация не заменяет резервное копирование, какие требования предъявляются к современной системе защиты данных, и покажем, как эти принципы реализованы в связке VMmanager и RuBackup.
Он вам не бэкап
На первый взгляд снимки и бэкапы действительно похожи — ведь после создания снапшота появляется возможность вернуться к предыдущему состоянию виртуальной машины. Ну и чем это вам не бэкап? Но, если серьезно, с технической точки зрения снапшот и резервная копия решают принципиально разные задачи и по-разному реализуются.
При создании снапшота гипервизор фиксирует состояние виртуальной машины на определенный момент времени. После этого новые записи выполняются через механизм copy-on-write или redirect-on-write — в зависимости от реализации конкретной платформы. Вместо копирования всего виртуального диска создаются структуры, позволяющие сохранить исходное состояние и отдельно фиксировать последующие изменения.
Именно поэтому создание снапшота обычно занимает считанные секунды и практически не зависит от объема виртуального диска — данные не копируются целиком. Если снапшот создается с сохранением памяти, дополнительно фиксируются содержимое оперативной памяти и состояние виртуальных устройств. Это позволяет после восстановления вернуть виртуальную машину практически в то же состояние, в котором она находилась в момент создания снимка.
При обращении к данным гипервизор определяет, где находится актуальная версия каждого блока — в исходном образе виртуального диска или в файлах изменений, созданных после снапшота.
Обратите внимание — снапшот не является самостоятельной копией данных. Он лишь фиксирует состояние существующего хранилища в определенный момент времени. Пока снапшот существует, он остается связанным с исходными данными и способом их хранения. Именно поэтому снапшоты отлично подходят для кратковременного отката изменений, тестирования, обновлений или клонирования виртуальных машин, но сами по себе не могут заменить полноценное резервное копирование.
Деградация производительности
Создание одного снапшота само по себе обычно практически не влияет на производительность. Проблемы начинают проявляться при длительном использовании снапшотов без их последующей консолидации или удаления.
Во многих платформах виртуализации снапшоты реализованы через цепочки изменений. По мере накопления таких цепочек системе приходится выполнять дополнительные обращения, чтобы определить, где находится актуальная версия каждого блока данных. Чем длиннее цепочка, тем выше потенциальные накладные расходы при операциях чтения и записи.
На небольшом количестве снапшотов это влияние обычно незаметно. Однако длинные цепочки могут увеличивать задержки операций ввода-вывода, создавать дополнительную нагрузку на подсистему хранения и замедлять консолидацию снапшотов после их удаления. Особенно заметно это на высоконагруженных виртуальных машинах — например, с базами данных или файловыми сервисами, — где даже небольшое увеличение задержек дисковой подсистемы способно сказаться на времени отклика приложений.
Именно поэтому снапшоты стоит рассматривать как временный инструмент и удалять их сразу после завершения операции, ради которой они были созданы.
Хрупкость цепочки
Еще одна особенность снапшотов заключается в том, что во многих платформах виртуализации они образуют цепочку зависимых состояний. Каждый новый снапшот хранит только изменения относительно предыдущего состояния, а не полную копию виртуального диска.
В таких реализациях повреждение одного из элементов цепочки может сделать недоступными и последующие состояния, поскольку они зависят от предыдущих уровней. Именно поэтому снапшоты и нельзя считать самостоятельными резервными копиями — они зависят от целостности исходных данных и всей цепочки изменений.
Здесь же стоит отметить и сложности, которые могут возникнуть при удалении снапшотов. В этом случае системе необходимо выполнить консолидацию накопленных изменений, чтобы интегрировать их в основное хранилище данных. Современные гипервизоры обычно выполняют эту операцию без остановки виртуальной машины, однако при больших объемах измененных данных консолидация может сопровождаться интенсивными операциями чтения и записи, увеличивая нагрузку на подсистему хранения и временно снижая производительность.
Иллюзия консистентности
Даже если снапшот создан успешно, это еще не означает, что его можно без проблем использовать для восстановления приложения.
Снапшот фиксирует состояние данных в определенный момент времени, однако это состояние не всегда совпадает с тем, которое приложение считает консистентным. Многие современные приложения активно используют оперативную память для буферизации операций и записывают данные на диск асинхронно.
В результате можно получить так называемый crash-consistent снапшот — снимок, фиксирующий состояние системы так, как если бы виртуальная машина была аварийно выключена в этот момент. Большинство журналируемых файловых систем способны автоматически восстановить согласованность собственных метаданных после такого события. Многие современные СУБД также выполняют восстановление с использованием журналов транзакций, однако часть еще не записанных на диск изменений может быть потеряна.
Чтобы получить снапшот с консистентностью на уровне приложения (application-consistent), перед его созданием необходимо согласовать состояние приложения и файловой системы. В этом случае перед созданием снапшота приложение завершает текущие транзакции (или переводит их в согласованное состояние), обеспечивает запись кэшированных данных на диск и временно приостанавливает операции записи.
Снапшоты остаются исключительно полезным инструментом: они позволяют быстро откатить неудачное обновление, протестировать изменения, создать клон виртуальной машины или зафиксировать состояние системы перед рискованными работами. Однако использовать их как полноценную стратегию защиты данных нельзя. Они не создают независимую копию информации, могут влиять на производительность при длительном хранении — и самое главное — и не гарантируют согласованное состояние приложений без дополнительной координации с гостевой ОС и самими приложениями.
Для полноценного резервного копирования необходима отдельная система, которая хранит данные независимо от продуктивной инфраструктуры, поддерживает политики хранения, дедупликацию, работу с различными типами хранилищ и обеспечивает гарантированное восстановление.
Какой должна быть современная система резервного копирования
Хорошо, со снапшотами разобрались. А какой вообще должна быть современная система резервного копирования виртуальной инфраструктуры?
Безагентное резервное копирование
Исторически резервное копирование строилось на установке специального агента в каждую операционную систему. Такой подход остается актуальным для физических серверов и отдельных приложений, однако в виртуальной инфраструктуре он создает дополнительные сложности. Каждый агент необходимо установить, обновлять, контролировать его совместимость с операционной системой и отслеживать его работоспособность. При десятках или сотнях виртуальных машин это превращается в отдельную эксплуатационную задачу. Кроме того, агент использует ресурсы гостевой ОС и становится еще одним компонентом, отказ которого может привести к проблемам при создании бэкапов.
Поэтому современные платформы виртуализации все чаще используют безагентный подход. В этом случае система резервного копирования взаимодействует непосредственно с гипервизором через его API, инициирует создание снапшотов через API гипервизора и копирует виртуальные диски без установки специализированного агента резервного копирования внутри гостевых операционных систем.
Эффективность хранения
Современная система резервного копирования должна не только создавать резервные копии, но и эффективно управлять их жизненным циклом.
Для этого используются инкрементные схемы резервного копирования, позволяющие после первой полной копии сохранять только изменившиеся данные. Дополнительно применяются дедупликация и сжатие, которые уменьшают объем хранимой информации и снижают требования к емкости хранилища.
Не менее важны и политики хранения — они автоматически определяют, как долго необходимо хранить ежедневные, еженедельные или ежемесячные резервные копии и когда их можно безопасно удалить без нарушения требований бизнеса или регуляторов.
Кроме того, современные системы резервного копирования должны обеспечивать защиту самих резервных копий — поддерживать шифрование как при передаче данных, так и при их хранении. Это снижает риск компрометации резервных копий даже в случае получения злоумышленником доступа к сети или физическим носителям.
Консистентность приложений
Получить резервную копию виртуальной машины недостаточно — важно, чтобы после восстановления корректно запускались приложения.
Если резервное копирование выполняется без согласования с приложением, создается crash-consistent-копия — то есть копия, эквивалентная аварийному завершению работы виртуальной машины.
Для современных СУБД, таких как PostgreSQL или MySQL, подобная ситуация обычно не критична — при следующем запуске они выполняют восстановление с использованием журналов транзакций. Однако этот процесс требует дополнительного времени, а для некоторых приложений такого уровня консистентности недостаточно. Поэтому для критически важных сервисов используют резервное копирование с консистентностью на уровне приложения (application-consistent).
Независимое хранение резервных копий
Даже качественно созданный бэкап бесполезен, если он хранится в том же контуре, что и продуктивная инфраструктура.
Современные программы-вымогатели стремятся не только зашифровать рабочие данные, но и уничтожить резервные копии — чтобы не оставить жертве ни единого шанса. Если сервер резервного копирования доступен из той же сети и использует те же административные учетные записи, злоумышленник с высокой вероятностью сможет вывести из строя и систему восстановления.
Поэтому сегодня все чаще используют не только классическое правило 3-2-1, но и его современную модификацию — 3-2-1-1-0. Она предполагает наличие как минимум одной неизменяемой или физически изолированной копии, а также регулярную проверку возможности восстановления.
В качестве такого хранилища могут использоваться ленточные библиотеки, S3-совместимые объектные хранилища с поддержкой Object Lock или удаленные площадки с собственной инфраструктурой хранения.
При этом современная система резервного копирования должна поддерживать работу сразу с несколькими типами хранилищ. Например, оперативные резервные копии могут храниться на локальном дисковом массиве для быстрого восстановления, а затем автоматически переноситься в объектное хранилище или на ленточную библиотеку для долговременного хранения и защиты от программ-вымогателей.
Проверка возможности восстановления
Сам факт успешного создания резервной копии еще не означает, что из нее удастся восстановить систему. Повреждение носителя, ошибки передачи данных, нарушение цепочки инкрементальных копий или проблемы с репозиторием — о таких неприятных вещах, увы, можно узнать уже после того, как бэкапы вам очень-очень понадобились. Именно поэтому одной из важнейших функций современной системы резервного копирования становится автоматическая проверка возможности восстановления из резервных копий. Такая проверка может включать проверку контрольных сумм, чтение данных из репозитория и автоматическую верификацию целостности резервной копии.
Репликация не заменяет резервное копирование
При проектировании системы защиты данных важно учитывать, что резервное копирование и репликация решают разные задачи.
Резервная копия позволяет восстановить данные после случайного удаления, логической ошибки, повреждения файлов или атаки программ-вымогателей. Репликация, напротив, предназначена для быстрого восстановления работоспособности после отказа оборудования, системы хранения или целой площадки.
Если инфраструктура предъявляет жесткие требования к времени восстановления (RTO), одного резервного копирования может быть недостаточно, ведь даже при наличии готового бэкапа восстановление большого количества виртуальных машин может занять значительное время. В таких случаях используется репликация на резервную площадку. Она синхронно или асинхронно передает изменения и позволяет быстро переключить сервисы на резервную инфраструктуру в случае аварии. Большинство механизмов репликации воспроизводят изменения практически без задержки, поэтому случайное удаление данных, логические ошибки или шифрование файлов вредоносным ПО обычно реплицируются на резервную площадку.
Как правило, в зрелых инфраструктурах обе технологии применяются совместно — репликация обеспечивает непрерывность работы сервисов, а резервное копирование дает возможность восстановления данных в различных сценариях отказа.
Как эти принципы реализованы в VMmanager и RuBackup
До этого мы говорили о требованиях, которым должна соответствовать современная система резервного копирования виртуальной инфраструктуры. Посмотрим, как эти принципы реализованы на практике на примере интеграции VMmanager и RuBackup.
Ниже речь пойдет не о полном обзоре возможностей продуктов, а только о тех механизмах, которые непосредственно влияют на надежность резервного копирования и восстановление виртуальных машин.
Интеграция на уровне платформы виртуализации
Одно из ключевых требований современной системы резервного копирования — возможность работать с виртуальной инфраструктурой без установки специализированных агентов внутри каждой гостевой операционной системы.
В связке VMmanager и RuBackup эта задача решается за счет интеграции через API платформы виртуализации. RuBackup получает полную информацию о виртуальной инфраструктуре из VMmanager, платформы согласовывают процесс создания резервных копий без остановки ВМ и работающих приложений, а интеграция на уровне гипервизора обеспечивает высокую скорость и минимальное влияние на производительность.
Такой подход уменьшает количество обслуживаемых компонентов, упрощает сопровождение инфраструктуры и снижает вероятность пропуска резервного копирования из-за проблем с отдельными агентами.
Гибкие политики резервного копирования
Оперативное восстановление требует частых инкрементальных копий, долгосрочное хранение — периодических полных резервных копий, а требования отдельных подразделений могут предусматривать собственные сроки хранения данных.
RuBackup поддерживает полные, инкрементальные и дифференциальные резервные копии, позволяя объединять их в единые политики хранения. Расписание резервного копирования задается централизованно и применяется автоматически ко всем выбранным объектам, что позволяет строить различные сценарии защиты данных без ручного управления отдельными заданиями.
Эффективная работа с хранилищем
По мере роста виртуальной инфраструктуры объем резервных копий становится одним из основных факторов стоимости эксплуатации. Поэтому современная система резервного копирования должна не только создавать резервные копии, но и эффективно использовать дисковое пространство.
В RuBackup для этого применяются механизмы сжатия данных, дедупликации, автоматическое перемещение резервных копий на другие носители и удаление устаревших копий. В частности, реализована поточная глобальная дедупликация — возможность размещать резервные копии в блочных устройствах (диск, RAID, LUN СХД) со значительной экономией пространства, при этом в системе резервного копирования может быть несколько пулов для дедупликации с разными характеристиками (размер блока, алгоритм и длина хэш-функции).
Многоуровневая стратегия хранения
Одним из требований современной защиты данных является возможность использовать несколько типов хранилищ одновременно.
RuBackup поддерживает хранение резервных копий в СХД, ленточных библиотеках и, облаке S3. Это позволяет реализовать единую политику хранения, при которой резервные копии автоматически перемещаются между различными носителями в зависимости от срока хранения и требований к скорости восстановления.
Контроль возможности восстановления
Создать резервную копию недостаточно — необходимо быть уверенным, что из нее действительно можно восстановить данные. RuBackup автоматически проводит верификацию резервных копий, чтобы проверить целостность файлов. Система контролирует корректность сохраненных данных и позволяет обнаружить возможные проблемы до возникновения аварийной ситуации.
При восстановлении виртуальной машины восстанавливаются не только виртуальные диски, но и связанные параметры конфигурации, необходимые для ее корректного запуска в инфраструктуре.
Репликация как дополнение к резервному копированию
Если резервное копирование отвечает за сохранность данных, то репликация позволяет сократить время восстановления после отказа оборудования или площадки.
RuBackup поддерживает непрерывную удаленную репликацию данных — все изменения источника данных передаются на резервный хост или резервную виртуальную машину и применяются к резервному источнику данных. Возможность доступна для большинства поддерживаемых RuBackup источников данных — файловых систем, виртуальных машин и т.п.
Использование в регулируемых инфраструктурах
Для организаций, работающих в регулируемых отраслях, важны не только технические возможности системы резервного копирования, но и соответствие требованиям российского законодательства.
RuBackup включен в реестр российского программного обеспечения и сертифицирован ФСТЭК России по 4 уровню доверия. Это позволяет использовать решение при построении защищенных информационных систем в случаях, предусмотренных действующими нормативными требованиями.
Интеграция
Интеграция VMmanager и RuBackup построена максимально просто и не требует разработки дополнительных модулей взаимодействия. После подключения к API VMmanager система резервного копирования автоматически получает доступ к объектам виртуальной инфраструктуры и позволяет централизованно управлять резервным копированием виртуальных машин.
Благодаря интеграции на уровне платформы виртуализации, поддержке различных типов хранилищ и средств автоматизации она позволяет построить систему защиты данных, соответствующую требованиям как коммерческих организаций, так и инфраструктур с повышенными требованиями к безопасности и отказоустойчивости.
При этом выбор конкретного решения всегда должен определяться архитектурой инфраструктуры, требованиями к RPO и RTO, нормативными ограничениями и эксплуатационными задачами организации. Независимо от используемого программного обеспечения именно архитектура резервного копирования остается главным фактором, определяющим возможность успешного восстановления после инцидента.