Представьте, что вы фотографируете страницу альбома: сама страница остается, но любые дальнейшие правки записываются на отдельной кальке поверх. Через час, день, неделю можно вернуться к этому фото и увидеть данные ровно такими, какими они были в момент съемки. Так работает снимок состояния — он же snapshot, он же снапшот. В отличие от полной резервной копии, делается за секунды и почти не занимает места — пока в томе не начнут меняться данные. В статье разберем, как технически устроены CoW и RoW, сколько реально весит точка восстановления на OLTP-нагрузке, чем consistency group отличается от обычного снимка и почему такой инструмент нельзя считать заменой бэкапа.
Что такое снапшот СХД простым языком
Снимок — это моментальная запись состояния тома или LUN на дисковом массиве. Создается за секунды, занимает на старте почти нулевой объем, позволяет в любой момент вернуть данные к зафиксированному состоянию. Технически реализуется на уровне массива, а не приложения, и потому не требует остановки сервиса.
Зачем нужен моментальный снимок тома
Когда система хранения создает такую точку, она запоминает не сами данные, а указатели на блоки, существовавшие на момент фиксации. Сам том продолжает работать как обычно — приложения пишут и читают. Но как только в блок происходит запись, массив сохраняет старую версию этого блока отдельно, чтобы по запросу вернуть тот вид данных, который был зафиксирован.
Чем снимок отличается от резервной копии
Резервная копия — это полный отдельный файл или набор файлов, физически лежащий на другом носителе. Может быть прочитан без оригинальной СХД, переносится между площадками, выживает после полного отказа массива. Снапшот — это надстройка над живым томом на той же системе хранения. Быстро создается, мгновенно откатывается, но умирает вместе с массивом. Поэтому правильный сценарий — моментальные точки для оперативного отката (часы и сутки) плюс полноценный бэкап для долгосрочного хранения и защиты от физической потери.
Чем точка состояния отличается от клона LUN
Клон — это полная копия тома с независимым набором блоков. Занимает столько же места, сколько оригинал, создается дольше (минуты для терабайтных томов), но дальше живет своей жизнью: изменения в клоне не влияют на источник и наоборот. Точка фиксации шарит блоки с оригиналом и зависит от него. На основе такой точки часто создают «легкие клоны» (link clone, thin clone) — они выглядят как полноценные тома, но реально хранят только дельту. Подробнее про разные классы систем хранения данных с поддержкой клонов и снимков можно посмотреть в каталоге.
Как технически работают снимки
Внутри массива механизм реализуется одним из двух способов. Выбор между ними влияет на производительность и сложность фоновых операций.
Copy-on-write (CoW) — запись блока копируется в дельту
При CoW любая запись в исходный том запускает дополнительную операцию: старая версия блока сначала копируется в отдельную область, и только потом новые данные пишутся на оригинальное место. Получается «два IO вместо одного» — оверхед на запись 10–30%. Зато чтение из основного тома идет без накладных расходов: данные лежат на тех же местах, что и до фиксации. Классическая схема, исторически реализованная в большинстве enterprise-массивов.
Redirect-on-write (RoW) — новые записи идут в отдельную область
При RoW логика обратная: оригинальные блоки остаются нетронутыми, а все новые записи отправляются в свободную область. Указатели в метаданных перестраиваются так, чтобы основной том «видел» новые блоки на новых местах. Оверхед на запись 0–5% — почти ничего. Но усложняется фоновое уплотнение (compaction) и сборка мусора: когда фиксация удаляется, старые блоки нужно либо переиспользовать, либо вернуть в свободный пул.
Сравнение CoW и RoW по производительности
CoW предсказуем по объему оверхеда и проще в реализации, но просаживает запись. RoW почти не влияет на запись, но требует более сложного движка под капотом. Большинство современных all-flash массивов (NetApp ONTAP, RAIDIX ERA, Yadro Tatlin) реализуют RoW или гибридную модель. Старые массивы и снимки на уровне ФС (LVM, ZFS old-style) — чаще CoW. На SSD-стораджах разница в производительности почти стерлась за счет высоких IOPS, на HDD CoW все еще заметно тормозит запись.
Сколько места занимает снимок состояния
Главный миф — «снимок делает копию тома». Это не так. Дельта растет постепенно, по мере изменений.
Базовая идея — занимает только дельту с момента фиксации
В момент создания точка весит почти ноль: только метаданные, несколько килобайт. Каждый последующий измененный блок добавляет в дельту место, равное размеру блока (обычно 4–64 КБ). Если за сутки изменилось 5% блоков тома 10 ТБ — дельта займет 500 ГБ. Если ничего не менялось — так и останется на уровне нескольких килобайт.
Расчет на типовых нагрузках OLTP и видеоархив
OLTP-нагрузка (база данных 1С, MS SQL, PostgreSQL) обычно меняет 5–15% блоков тома в сутки. На томе 1 ТБ за неделю точка состояния наберет 350–1000 ГБ. Видеоархив — наоборот, почти не меняет старые блоки (записи идут в новые), поэтому за неделю наберется столько же, сколько добавилось новых данных. Архивные тома с редкими изменениями — самый выгодный случай: за месяц весит десятки ГБ при томе в сотни ТБ.
Как растет объем при удлинении глубины хранения
Линейно, пока интенсивность изменений постоянна. Точка недельной глубины весит в 7 раз больше суточной. Месячная — в 30 раз. Поэтому при планировании важно понимать, какой реальной глубины снимки нужны: для оперативного отката хватает 24–72 часов, для длинных откатов разумнее делать редкие фиксации (раз в неделю, раз в месяц), а не держать все 30 промежуточных. Современные блочные массивы поддерживают 256–1024 точек на том, у некоторых платформ — до миллиона на массив.
Согласованность данных — crash-consistent vs application-consistent
Сама по себе фиксация ничего не знает о состоянии приложения. Если в этот момент база данных писала транзакцию, на диске она окажется наполовину. Чтобы избежать этого, есть два уровня согласованности.
Crash-consistent — моментальный срез без участия приложения
Фиксация делается «как есть»: что записано на диск — то и в дельте, что осталось в буферах СУБД — потеряно. Приложение при восстановлении окажется в состоянии, эквивалентном выключению питания посреди работы. БД восстановится через обычный механизм recovery — откат незавершенных транзакций. Для большинства приложений этого достаточно, но крупные распределенные системы могут не вернуться к рабочему состоянию автоматически.
Application-consistent — с заморозкой через VSS, pre/post-скрипты
Перед фиксацией приложение получает сигнал «остановиться»: для Windows — через службу VSS (Volume Shadow Copy Service), для MS SQL — через VSS-writer базы, для Oracle — через RMAN или скрипт ALTER SYSTEM SUSPEND. Приложение сбрасывает буферы на диск, замораживает IO на 1–3 секунды, точка создается, и работа продолжается. На выходе — версия данных, из которой база поднимается мгновенно и без recovery. Поддерживается всеми зрелыми системами хранения и большинством ПО резервного копирования вроде Veeam, RuBackup, Кибер Бэкап.
Consistency group — согласованная фиксация нескольких томов
Если приложение использует несколько томов (база данных на одном LUN, лог-файлы на другом), отдельные фиксации каждого тома дадут рассинхронизацию: они будут сделаны в разные доли секунды, и при восстановлении лог не совпадет с базой. Consistency group решает это: массив делает срезы всех томов группы как одну атомарную операцию. Обязательная функция для серьезных СУБД, кластеров баз и распределенных приложений вроде серверов виртуализации с несколькими виртуальными дисками.
Сценарии применения снимков
Это не «дополнительная фича», а ежедневный рабочий инструмент. Четыре главных сценария.
Быстрый откат базы перед обновлением приложения
Перед накатом обновления 1С, MS SQL, прикладной системы делается фиксация. Если что-то пошло не так — откат за секунды, без долгого восстановления из бэкапа. Это критично для апдейтов в выходные, где счет идет на часы простоя. После успешного теста точка удаляется, освобождая место.
Тестовые стенды на основе клонов из точки фиксации
Из продуктивной базы создается тонкий клон. Получаешь полноценную копию данных для разработчиков, аналитиков, тестирования — без удвоения объема хранения. Клон ведет себя как обычный том, разработчики могут писать в него что угодно, продуктив не страдает. Удалили стенд — место вернулось.
Защита от ошибок оператора и шифровальщиков
Случайно удалили таблицу, дропнули LUN, файл уехал в неизвестные дали. Часовая фиксация — мгновенный возврат к рабочему состоянию. С шифровальщиками сложнее: если атакующий получил root-сессию на массиве, он удалит все точки вместе с данными. Поэтому такая защита работает только против ошибок и против шифровальщиков, не имеющих прав на массив. Серьезная защита — это иммутабельные репозитории и система резервного копирования с air-gap-копией поверх дисковых срезов.
Репликация между площадками
Точки можно отправлять на вторую СХД в другом ЦОД — инкрементально, только дельту с прошлой передачи. Это база для распределенных DR-схем. NetApp ONTAP SnapMirror, RAIDIX ERA Replication, Huawei OceanStor HyperReplication — все умеют это с RPO от 30 секунд до нескольких минут. Полезно использовать сетевое хранилище с поддержкой репликации «из коробки» — это упрощает архитектуру DR.
Восстановление — RTO и RPO
Главный плюс этого механизма — скорость возврата к точке. Но есть нюансы, которые отличают его от полноценного восстановления из бэкапа.
Возврат файла или тома целиком за секунды
Откат тома 10 ТБ — 5–30 секунд. Массив меняет указатели в метаданных, и том сразу видит данные на нужный момент. Это совершенно несравнимо с восстановлением из бэкапа, где те же 10 ТБ восстанавливаются часами. По метрике RTO мы близки к нулю — для большинства задач это десятки секунд.
Откат против rollforward из бэкапа
Есть ограничение: можно вернуться только к зафиксированным точкам. Если делал срезы в 12:00 и 18:00, а ошибка произошла в 17:30 — придется откатиться на 12:00 и потерять 5,5 часов работы. Бэкап-системы умеют point-in-time recovery: восстановили вечернюю копию, накатили логи транзакций до 17:29:59. Дисковая фиксация в этом проигрывает. Поэтому правильная схема — частые точки (раз в час) + ежедневный бэкап с логами для гранулярного восстановления.
Когда механизм не спасет — физическое повреждение СХД
Все живет на той же системе хранения, где исходные данные. Сгорел контроллер, отказали два диска одновременно в RAID 5, массив залило в серверной — точки ушли вместе с данными. Такая защита работает против логических ошибок (удаление, шифровальщик без прав на массив, неудачное обновление), но никак не против физических. От физических защищает только бэкап на другом носителе и в другом месте.
Реализации в разных СХД и гипервизорах
Решения отличаются по возможностям, лимитам и поведению под нагрузкой.
Блочные СХД (RAIDIX, BAUM, NetApp, Huawei OceanStor)
Блочные массивы выдают тома по iSCSI или Fibre Channel. Точки фиксируются на уровне LUN, поддерживают CoW или RoW, лимиты 256–1024 на том. RAIDIX ERA и Yadro Tatlin — российские игроки с RoW-движком и иммутабельными версиями. NetApp ONTAP — классика с WAFL и встроенной репликацией SnapMirror. Huawei OceanStor — стек с HyperReplication и HyperSnap. Все эти системы хранения интегрируются с VMware через VASA и с ПО резервного копирования вроде Veeam через прямой API.
Файловые СХД (BeeGFS, TrueNAS, Astra Storage)
Файловые системы (NAS) фиксируют состояние на уровне директорий или томов файловой системы. TrueNAS на ZFS — самый известный пример: моментальные точки с дедупликацией и шифрованием, репликация через ZFS send/receive. Astra Storage — российский NAS с поддержкой подобного механизма и репликации. BeeGFS — параллельная файловая система для HPC и AI-кластеров. Файловые реализации обычно дешевле в обслуживании, но менее производительны под OLTP. Ориентир для выбора: блочная СХД — под OLTP, виртуализацию и задачи с жестким RPO; файловая (NAS/ZFS) — под неструктурированные данные, архивы и HPC где важна простота управления.
Срезы в VMware vSphere и российских гипервизорах
VMware vSphere делает фиксацию на уровне виртуальной машины (vmsnapshot). Это не то же самое, что аналогичный механизм СХД: Важно: vSphere-точка хранится в дельта-файлах VMDK и заметно просаживает производительность при удержании дольше 24–72 часов — это системное ограничение архитектуры vmsnapshot, не баг конкретной версии. Хорошая практика — не держать VM-snapshot дольше 24–72 часов, для длинных точек использовать срезы массива через VASA. Hyper-V checkpoint работает аналогично. Российские гипервизоры (zVirt, РЕД Виртуализация) поддерживают подобную фиксацию через KVM external snapshot — с теми же ограничениями по длительности удержания.
Правила работы и типовые ошибки
Три ошибки, которые встречаются в каждом втором проекте.
Удалять старые срезы вовремя — рост места и просадка
Чем дольше живет фиксация, тем больше места она занимает и тем сильнее тормозит запись на исходный том (особенно при CoW). Сценарий «забыли удалить точку месячной давности» приводит к тому, что массив раздувается, IOPS падают, дисковое пространство кончается в самый неподходящий момент. Стандартная политика: автоматическое удаление по retention — например, держать 24 часовых, 7 ежедневных, 4 еженедельных.
Не использовать как замену бэкапов
Самая частая и опасная ошибка. Дисковая фиксация не уезжает с массива, не защищает от шифровальщика с root-доступом, не выживает после физического отказа СХД. Это инструмент быстрого отката, не страховка от катастрофы. Полноценный бэкап делается отдельно по правилу 3-2-1: 3 копии, на 2 разных носителях, 1 копия off-site.
Регулярная репликация на вторую СХД
Если бизнес критичный и требует короткого RPO — настройте передачу точек на вторую площадку. SnapMirror, ERA Replication, HyperReplication умеют отправлять только дельту: первая передача может занять часы, дальше — минуты или секунды на инкремент. При сценарии «упала основная СХД» вторая площадка поднимается с RPO в минуты, а не часы.
Подбираете СХД с поддержкой моментальных срезов под 1С, виртуализацию или видеоархив? Наши инженеры подберут блочную или файловую систему хранения с CoW/RoW, рассчитают глубину фиксаций и спроектируют репликацию. Закажите подбор оборудования под задачу — после расчета будет понятна реальная стоимость инфраструктуры.
Заключение
Моментальные срезы — ключевой инструмент операционной защиты данных: создаются за секунды, откатывают том за 5–30 секунд, занимают место только под изменения. Точка создается за секунды, занимает место только под изменения, позволяет вернуть данные за десятки секунд. Технически реализована через CoW (просто, но тормозит запись на 10–30%) или RoW (без оверхеда на запись, но сложнее в реализации). Главное правило — такая фиксация не заменяет бэкап: она живет на той же СХД, что и оригинал, и при физическом отказе массива умирает вместе с данными. Рабочая схема — частые точки для оперативного отката (24–72 часа), редкие фиксации для длинных откатов (недели и месяцы), и поверх всего полноценный бэкап с off-site копией. Для критичных систем — репликация на вторую площадку с RPO в минуты. И отдельная гигиена — автоматическое удаление по retention, иначе массив раздуется.
Ответы на частые вопросы
Чем снапшот отличается от резервной копии?
Это надстройка над живым томом на той же СХД. Создается за секунды, откатывается мгновенно, но умирает вместе с массивом. Резервная копия — отдельный файл на другом носителе, выживает после полного отказа массива, но создается и восстанавливается долго. Эти инструменты дополняют друг друга, а не заменяют.
Сколько места занимает один снимок?
В момент создания — почти ноль (несколько килобайт метаданных). Дальше растет на размер дельты — изменившихся блоков. На OLTP-нагрузке 1 ТБ за сутки набирает 50–150 ГБ, за неделю — 350–1000 ГБ. На статичных архивах — десятки мегабайт за месяц.
Что эффективнее для производительности — CoW или RoW?
RoW почти не влияет на производительность записи (0–5% оверхеда). CoW дает 10–30% просадки при активной точке. На современных all-flash массивах разница нивелируется высокими IOPS, на HDD-системах RoW заметно выгоднее.
Можно ли откатить базу 1С из снимка СХД?
Да. Если фиксация делалась как application-consistent (через VSS-writer), база поднимается мгновенно. Если crash-consistent — пройдет обычный recovery с откатом незавершенных транзакций, занимает минуты. Для 1С это полностью рабочая схема отката перед обновлениями.
Сколько точек можно держать одновременно?
Современные блочные массивы поддерживают 256–1024 фиксации на том. У некоторых платформ — до миллиона на весь массив. Практический предел — не лимит, а место и просадка производительности. Реально держат 24 часовых + 7 ежедневных + 4 еженедельных = около 35 активных версий на том.
Защитит ли дисковая фиксация от шифровальщика?
Частично. Если шифровальщик работает на гостевой ОС без прав на массив — точки выживут, можно откатиться. Если атакующий получил доступ на уровне массива (root или admin СХД) — он удалит все версии вместе с данными. Полная защита — иммутабельные репозитории и air-gap-копии в отдельной системе резервного копирования.
Можно ли реплицировать снимки на удаленный ЦОД?
Да, это стандартная функция enterprise-СХД. NetApp ONTAP SnapMirror, RAIDIX ERA Replication, Huawei OceanStor HyperReplication отправляют только дельту между фиксациями. RPO — от 30 секунд до 15 минут в зависимости от настроек и пропускной способности канала между ЦОД.
Чем снимок отличается от клона LUN?
Срез шарит блоки с оригиналом и занимает только дельту. Клон — независимая копия с собственным набором блоков, занимает столько же места, сколько оригинал. На основе фиксации можно создать тонкий клон (link clone), который ведет себя как полноценный том, но хранит только дельту. Тонкие клоны — основа тестовых стендов из боевых данных.
