Снимки LVM и btrfs: резервное копирование без простоя

Знаете это чувство, когда нужно сделать полный бэкап базы данных на продакшене, но сервер нельзя выключать даже на минуту? Раньше приходилось либо мириться с простоем, либо использовать сложные скрипты, которые часто давали сбои. Сейчас всё изменилось благодаря механизмам мгновенных снимков в LVM и файловой системе btrfs. Эти инструменты позволяют создать копию состояния диска за доли секунды, не останавливая работу приложений.

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

Как работают снимки дисков

Чтобы понять разницу между LVM и btrfs, сначала нужно уяснить общий принцип работы снимков (snapshots). Ни одна из этих систем не копирует все данные сразу. Это было бы слишком долго и дорого по месту.

Вместо этого используется техника Copy-on-Write (CoW). Когда вы создаете снимок, система просто помечает текущие блоки данных как «общие». Пока файл или база данных не изменяются, оригинал и снимок указывают на одни и те же физические секторы на диске. Как только приложение пытается изменить данные, система делает следующее:

• Копирует старый блок данных в свободную область пространства снимка.
• Записывает новые данные в исходный том.
• Обновляет метаданные так, чтобы снимок ссылался на старую копию, а рабочий том - на новую.

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

LVM Snapshot: классика для блочных устройств

Logical Volume Manager (LVM) - это менеджер томов, который работает на уровне блочных устройств, ниже файловой системы. Он позволяет создавать снимки любого логического тома, независимо от того, какая файловая система внутри него (ext4, xfs и т.д.).

Команда создания снимка выглядит так:

lvcreate -L 10G -s -n my_snapshot /dev/vg0/my_volume

Здесь мы создаем снимок размером 10 ГБ. Почему именно столько? Потому что вам нужно место только для изменений, произошедших за время бэкапа. Если ваша база данных обновляется интенсивно, 10 ГБ могут закончиться через несколько минут. Мониторинг использования снимка обязателен.

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

btrfs Snapshots: нативная поддержка в файловой системе

Если вы используете btrfs, вам не нужен внешний слой вроде LVM для создания снимков. Эта файловая система изначально спроектирована вокруг концепции Copy-on-Write. Здесь нет понятия «фиксированный размер снимка». Снимок в btrfs - это просто еще один подтом (subvolume), который разделяет большинство блоков с родительским томом.

Создание снимка выполняется командой:

btrfs subvolume snapshot /mnt/data /mnt/snapshots/data_backup_$(date +%F)

Это действие происходит мгновенно. Главное преимущество btrfs в том, что снимок не имеет собственного лимита размера. Он растет вместе с вашими изменениями, пока в общем пуле хранения есть свободное место. Это снимает головную боль с выбором размера, которая мучает администраторов LVM.

Однако есть подводные камни. Btrfs известна своим агрессивным использованием памяти и CPU при больших объемах данных. Кроме того, восстановление после сбоя питания в старых версиях ядра Linux могло приводить к повреждению метаданных. В современных дистрибутивах (Ubuntu 22.04+, RHEL 9+) эта проблема решена, но надежность все равно зависит от качества железа и правильности настройки.

Стратегия бэкапа без простоя для баз данных

Просто скопировать файлы базы данных со снимка - плохая идея. Файлы БД должны быть консистентны. Если вы скопируете файлы MySQL или PostgreSQL «на лету», даже со снимка, вы рискуете получить битые таблицы, потому что журнал транзакций (redo log) мог не успеть синхронизироваться с данными на диске.

Вот проверенная схема действий для MySQL/MariaDB:

1. Блокировка таблиц: Выполните команду FLUSH TABLES WITH READ LOCK;. Это остановит запись на короткое время (секунды).
2. Создание снимка: Запустите команду создания снапшота LVM или btrfs. Она выполнится мгновенно.
3. Разблокировка: Сразу после создания снимка выполните UNLOCK TABLES;. База данных снова готова к работе.
4. Копирование: Монтируйте снимок в другую папку и копируйте файлы оттуда.
5. Удаление снимка: После завершения копирования удалите снимок, чтобы освободить ресурсы.

Для PostgreSQL подход немного отличается. Лучше использовать встроенный инструмент pg_basebackup или утилиту barman, которые умеют работать с потоковой репликацией. Но если вы хотите именно файловый бэкап, убедитесь, что база данных остановлена корректно перед созданием снимка, либо используйте режим «warm standby» для снятия лога.

Инкрементальные бэкапы и ротация

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

В LVM для этого используется флаг -s с указанием родительского снимка. В btrfs можно создавать снимки друг друга, формируя дерево версий. Инструменты вроде Snapper автоматизируют этот процесс для btrfs, автоматически удаляя старые снимки согласно политике ротации.

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

Типичные ошибки администраторов

Самая частая ошибка - недооценка скорости роста снимка. Представьте, что вы сделали снимок утром, а вечером начали массовую миграцию данных или обновление ПО. Изменения могли составить десятки гигабайт. В LVM такой снимок станет «invalid» (недействительным), и вы потеряете возможность восстановить состояние на утро.

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

Третья ошибка - игнорирование производительности. На HDD массивах большое количество снимков может замедлить чтение, так как контроллеру приходится агрегировать данные из разных мест. На SSD влияние минимально, но нагрузка на контроллер все равно возрастает.

Практические рекомендации

Выбирайте LVM, если:

• Вы используете ext4 или XFS.
• Вам нужна стабильная, проверенная временем технология.
• Вы готовы тщательно мониторить размер снимков.

Выбирайте btrfs, если:

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

Независимо от выбора, настройте алерты. В Zabbix или Prometheus добавьте метрики отслеживания свободного места в пуле снимков. Если заполненность превысит 80%, пора бить тревогу.