Снапшоты: LVM, ZFS и диски в облаке

Почему это мгновенно

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

Первая, copy-on-write: при записи в блок, входящий в снапшот, старое содержимое сначала уезжает в отдельную область, и только потом пишутся новые данные. Так работают LVM и теневые копии Windows.

Вторая, redirect-on-write: блок вообще не перезаписывается, новые данные ложатся в свободное место, а старый остаётся жить, пока на него ссылается снапшот. Так устроены ZFS и Btrfs.

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

Отсюда практическое следствие: снапшот, забытый на активной базе, разрастается и в какой-то момент упирается в отведённое место.

LVM

В LVM снапшот делается на уровне логического тома:

lvcreate --size 10G --snapshot --name db-snap /dev/vg0/db

Размер здесь это место под изменения, а не под копию данных. И оно резервируется из группы томов сразу: десять гигабайт становятся недоступны в момент создания снапшота, даже пока он пустой.

Кончилось зарезервированное место — классический снапшот становится недействительным. У тонких (thin) снапшотов ведёт себя иначе: переполняется уже сам пул, и запись начинает отдавать ошибки ввода-вывода.

Дальше снапшот можно смонтировать и спокойно скопировать данные, пока основной том продолжает работать. Это классический приём: снапшот на минуту, копирование с него, удаление снапшота.

ZFS и Btrfs

В файловых системах с copy-on-write снапшоты устроены естественнее, потому что механизм используется постоянно, а не включается специально:

zfs snapshot tank/data@2026-08-23
zfs list -t snapshot

Плюс в том, что такие снапшоты умеют отправляться на другой сервер потоком:

zfs send tank/data@2026-08-23 | ssh backup-host zfs recv backup/data

Принимающий набор данных должен либо не существовать, либо принимать поток с флагом -F; иначе zfs recv откажется писать поверх существующего.

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

Снапшоты дисков в облаке

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

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

Поэтому облачные снапшоты хороши как быстрый откат и слой номер один, но правило 3-2-1 они не закрывают.

Консистентность: главный подвох

Снапшот тома фиксирует диск таким, каким он был в этот момент, включая незавершённые записи.

Crash-consistent — состояние как после внезапного отключения питания. Файловая система при монтировании прокрутит журнал, база при старте проиграет свой журнал транзакций. Обычно это работает, но гарантий нет: данные приложения могут оказаться в промежуточном состоянии.

Application-consistent — перед снимком приложение попросили привести данные в согласованный вид: сбросить буферы на диск и на мгновение придержать запись.

У Postgres для этого есть низкоуровневый интерфейс:

SELECT pg_backup_start('snapshot');
-- здесь делается снапшот тома
SELECT * FROM pg_backup_stop(wait_for_archive => true);

Тут три подвоха. Соединение должно жить между вызовами: оборвалось — бэкап считается прерванным. pg_backup_stop() возвращает запись из трёх полей, и её содержимое нужно сохранить рядом с копией в файлы backup_label и tablespace_map, иначе копия не поднимется. И запись база при этом не замораживает: согласованность даёт не пауза, а журнал WAL, который придётся приложить к снимку.

Эти функции называются так с PostgreSQL 15; раньше они были pg_start_backup и pg_stop_backup, и в старых статьях встречается именно тот вариант.

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

На Windows ту же задачу решает VSS, но не сам по себе: согласованность обеспечивает writer внутри приложения, который перед снимком завершает транзакции и сбрасывает кеши. У облачных провайдеров для этого есть агенты и pre-скрипты.

Когда снапшот уместен

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

Как единственная защита данных — нет, по причинам из первого урока трека: живёт рядом с оригиналом, удаляется теми же правами, зависит от того же провайдера.

Что важно запомнить

Снапшот мгновенен, потому что не копирует данные: он фиксирует блоки, а дальше работает copy-on-write (LVM) или redirect-on-write (ZFS, Btrfs).

Забытый снапшот на активном томе растёт и способен забить хранилище.

zfs send превращает снапшот в настоящую копию на другой машине, обычный снапшот копией не является.

Crash-consistent снимок это состояние «как после выдёргивания шнура»; для базы предпочтителен application-consistent.

Снапшоты это быстрый откат, а не замена бэкапу.

Дальше разберём RAID: от чего он защищает на самом деле и почему ребилд большого массива это отдельное событие.