Снапшоты и репликация: почему это не бэкап

Почему снапшот и реплику принимают за бэкап

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

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

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

Снапшот: точка отката рядом с оригиналом

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

Для vSphere это зафиксировано в документации буквально: «не используйте снапшоты VMware как бэкапы; файл снапшота — только журнал изменений исходного виртуального диска», то есть самостоятельной копией данных он не является. Оттуда же — эксплуатационные лимиты: один снапшот не рекомендуется держать дольше 72 часов (файл изменений растёт), цепочка технически поддерживает до 32 снапшотов, но для производительности рекомендуется ограничиваться двумя-тремя.

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

Границы тоже следуют из механики. Погибло исходное хранилище — вместе с ним погибли и снапшоты. Злоумышленник получил права на платформу — он управляет и снапшотами: их можно удалить той же консолью, что и данные. Давнюю порчу снапшоты тоже не закрывают: при рекомендованных лимитах хранения глубокой истории состояний у них нет. У других гипервизоров и СХД механика снапшотов своя, и её стоит проверить по документации конкретной платформы, но общий принцип класса сохраняется: локальный снапшот остаётся зависимым от исходной платформы и хранилища.

Снапшоты ВМ и снапшоты СХД: где они живут

Снапшоты виртуальных машин живут на уровне гипервизора. Их типовые роли — откат обновлений и экспериментов и согласованная фиксация состояния машины на время снятия резервной копии: система резервного копирования создаёт снапшот, копирует зафиксированное состояние и удаляет снапшот. В этой связке снапшот — вспомогательный механизм бэкапа, а не его замена. Как устроена виртуализация серверов в целом — в хабе рубрики «Виртуализация».

Снапшоты СХД живут на уровне массива: механика зависит от конкретной системы, снимки могут создаваться быстро и почти не влиять на продуктив — за это их и любят. Но живут они в том же массиве, что и данные: отказ массива уносит и то и другое, а права администратора СХД дают власть над обоими. Перенос снапшотов на второй массив — это уже репликация, то есть другой механизм со своими границами, о нём ниже. Возможности снапшотов у конкретной модели СХД и выбор самой системы — в гайде по СХД: SAN, NAS, DAS.

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

Репликация: живая вторая копия

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

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

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

Вторая граница — время. Живая реплика отражает недавнее состояние источника; отката «на неделю назад» она не даёт, если у решения нет собственной истории точек восстановления. Такие точки на реплике у ряда платформ существуют, но это свойство конкретного продукта и его настроек — его наличие, глубину и работоспособность проверяют отдельно.

Синхронная и асинхронная репликация: фактический RPO

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

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

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

Какой интервал потерь и какой простой вообще допустимы для конкретной системы — это выбор бизнеса, а не свойство технологии: методика выбора целевых значений — в статье «Как определить RPO и RTO».

Что делает бэкап бэкапом

На фоне двух предыдущих механизмов свойства настоящей резервной копии видны отчётливо. Их три.

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

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

Изолируемость. Копию можно отделить от продуктивной сети: офлайн-носитель, неизменяемое (immutable) хранилище, слой, до которого не дотягиваются учётные записи продуктива. Для атак, которые целятся именно в резервные копии, это решающее свойство; обзор защиты от шифровальщиков — в хабе рубрики.

Что при этом считается полноценной копией, сколько их нужно и как разнести по носителям и площадкам — это архитектура копий по правилу 3-2-1, разобранная в статье о правиле 3-2-1. Здесь важно одно: копия, которая живёт на исходной платформе или послушно синхронизируется с ней, этим критериям не соответствует.

Честная граница есть и у бэкапа: восстановление из копии занимает время — данные нужно вернуть из репозитория, систему поднять и проверить. Мгновенного переключения бэкап не даёт; это цена независимости, и закрывается она либо честным допустимым простоем, либо репликой для действительно критичных систем.

Сводная таблица: от чего защищает каждый механизм

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

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

Как три механизма работают вместе

Правильный вывод из границ — не «выбрать лучший механизм», а собрать связку, где каждый делает своё. Так это формулирует и Veeam: бэкапы — для длительного хранения, неизменяемости и восстановления на уровне файлов и приложений, реплики — для критичных нагрузок; большинство компаний используют оба механизма.

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

Какие системы заслуживают реплики, а каким достаточно ночной копии — это ровно вопрос целевых RPO и RTO по процессам: методика выбора — в статье «Как определить RPO и RTO».

Под независимый слой копий подбирается и отдельное «железо» — хранилище, которое не разделяет судьбу продуктива: системы хранения в каталоге ANDPRO.

Самопроверка: что из этого у вас уже есть

Пять вопросов к вашей текущей схеме — отвечать честно, по факту:

Если на первые три вопроса ответ «нет» — в схеме пока есть точки отката и, возможно, горячая копия, но нет резервного копирования в строгом смысле. Начинать в этом случае стоит не с реплики, а с независимого слоя копий: практические схемы — в статье о правиле 3-2-1, выбор целей под ваши процессы — в статье о выборе RPO и RTO.

Частые вопросы