LVM snapshots на Linux VDS: создание, backup и rollback без лишнего риска

LVM snapshots — один из тех инструментов, которые выглядят простыми ровно до первого неудачного rollback. Команда lvcreate действительно создаёт снимок за секунды, но дальше начинаются важные детали: сколько места выделить, можно ли снимать базу «на горячую», что будет при переполнении snapshot, как откатить root-раздел и почему snapshot не заменяет нормальный backup.

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

Главная мысль: LVM snapshot — это короткоживущий технический снимок для страховки и консистентного backup. Это не архив, не защита от удаления диска и не замена правилу 3-2-1.

Что такое LVM snapshot и когда он полезен на VDS

LVM, Logical Volume Manager, добавляет между диском и файловой системой слой управления томами. Вместо того чтобы работать напрямую с разделом вроде /dev/vda2, вы работаете с логическими томами: например, /dev/vg0/root, /dev/vg0/var, /dev/vg0/mysql. Snapshot в LVM фиксирует состояние такого тома на момент создания.

Классический snapshot использует принцип copy-on-write. Пока данные на основном томе не меняются, snapshot почти не занимает место. Когда блок на основном томе перезаписывается, старая версия блока сохраняется в области snapshot. Поэтому размер snapshot — это не размер всего тома, а запас под изменения, которые произойдут за время его жизни.

Типовые задачи, где LVM snapshots действительно удобны:

• перед обновлением ядра, PHP, PostgreSQL, MySQL, панели управления или большого набора пакетов;
• перед миграцией приложения, сменой структуры каталогов, массовым rsync или деплоем;
• для снятия файлового backup с замороженного состояния тома, пока приложение продолжает работать;
• для быстрой проверки: «если обновление сломается, смогу ли я вернуть том назад?»;
• для тестового клонирования данных на отдельный mount point без остановки основного сервиса.

Но есть и ограничения. Snapshot находится на том же VDS-диске и обычно в той же volume group. Если сломается сам виртуальный диск, snapshot не поможет. Если вы держите snapshot неделями, он может переполниться из-за фоновой записи логов, базы данных, очередей и кешей. Если откатить том, все изменения после создания snapshot будут потеряны. Поэтому LVM snapshot — хороший инструмент для операции «сейчас делаем изменение и быстро проверяем», но плохой инструмент для долговременного хранения.

Проверяем, есть ли LVM и как называются тома

Сначала нужно понять, используется ли LVM на сервере. На разных образах Linux VDS разметка может отличаться: где-то root находится на обычном разделе, где-то на LVM, где-то используется cloud-init с growpart, а где-то отдельные тома вынесены под /var, /home или базы.

lsblk -f
pvs
vgs
lvs -a -o +devices
findmnt /
findmnt /var

Если lvs показывает логические тома, а findmnt указывает устройство вида /dev/mapper/vg0-root или /dev/vg0/root, значит нужный mount point расположен на LVM. Если root находится на /dev/vda1 без LVM, создать LVM snapshot для него не получится без переразметки и миграции данных.

Проверьте свободное место в volume group. Snapshot требует свободных extents в той же группе томов, если речь о классическом LVM snapshot.

vgs
vgdisplay vg0
lvs -o lv_name,vg_name,lv_size,origin,data_percent,metadata_percent,lv_attr

В выводе vgs особенно важна колонка VFree. Если свободного места мало, snapshot будет маленьким и рискованным. Если свободного места нет, lvcreate не сможет создать снимок, пока вы не увеличите диск, не расширите volume group или не освободите место.

Установка инструментов LVM

На большинстве серверных образов пакет LVM уже установлен. Если команды lvs, vgs и lvcreate не найдены, установите пакет lvm2. Команды отличаются только менеджером пакетов.

Debian и Ubuntu

sudo apt update
sudo apt install lvm2

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux и Fedora

sudo dnf install lvm2
sudo systemctl enable --now lvm2-monitor.service

На старых RHEL-based системах вместо dnf может использоваться yum, но логика та же. Сервис lvm2-monitor полезен для мониторинга и некоторых операций с thin pool, но наличие самого пакета важнее.

Сколько места выделять под snapshot

Самый частый вопрос: если root-том 40 ГБ, какого размера делать snapshot? Ответ зависит не от размера тома, а от объёма изменений, которые произойдут до удаления snapshot или до rollback.

Для короткого окна перед обновлением пакетов часто хватает 10–20% от размера тома. Для активной базы данных, почтового сервера, Docker-хоста или приложения с большим количеством логов лучше закладывать больше. Если вы собираетесь делать backup несколько часов, а на сервере активно пишутся данные, snapshot должен выдержать весь объём изменённых блоков за это время.

Примерные ориентиры для классического snapshot:

• короткое обновление пакетов на спокойном сервере: 2–5 ГБ;
• деплой приложения с умеренной записью: 10–20% от origin-тома;
• backup большого каталога с активной базой или медиа: считать по реальной скорости записи, а не «на глаз»;
• долгий snapshot на сервере с Docker, логами и базами: лучше пересмотреть задачу и использовать отдельный backup-подход.

Если snapshot переполнится, он становится invalid. В лучшем случае вы потеряете возможность отката и backup со снимка. В худшем — получите аварийный сценарий во время и без того рискованной операции.

Перед важной работой посмотрите текущую активность записи. Это не даст идеального прогноза, но поможет не ошибиться на порядок.

df -h
journalctl --disk-usage
du -sh /var/log /var/lib/mysql /var/lib/postgresql /var/lib/docker 2>/dev/null
iostat -xz 1 5

В последней команде используется iostat из пакета sysstat. Если утилиты нет, её можно поставить отдельно, но для базовой работы с LVM она не обязательна.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Создаём классический LVM snapshot через lvcreate

Допустим, root-том находится в /dev/vg0/root, а свободного места в vg0 достаточно. Создадим snapshot размером 5 ГБ с именем root_before_upgrade.

sudo lvcreate -s -n root_before_upgrade -L 5G /dev/vg0/root
sudo lvs -a -o lv_name,vg_name,lv_size,origin,data_percent,lv_attr

Ключ -s означает snapshot, -n задаёт имя, -L задаёт размер области copy-on-write, а последним аргументом указывается origin-том — тот самый том, состояние которого фиксируем.

Для отдельного тома с данными команда будет такой же. Например, если база лежит на /dev/vg0/mysql:

sudo lvcreate -s -n mysql_before_migration -L 20G /dev/vg0/mysql
sudo lvs -a -o lv_name,lv_size,origin,data_percent,devices

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

Монтируем snapshot для проверки или backup

Snapshot можно смонтировать read-only, чтобы проверить файлы или снять резервную копию. Сначала определите тип файловой системы.

sudo blkid /dev/vg0/root_before_upgrade
findmnt -no FSTYPE /

Для ext4 обычно используем read-only mount. Опция noload запрещает проигрывать журнал, что полезно при монтировании снимка только для чтения.

sudo mkdir -p /mnt/root-snap
sudo mount -o ro,noload /dev/vg0/root_before_upgrade /mnt/root-snap
ls -la /mnt/root-snap

Для XFS при монтировании копии той же файловой системы нужен параметр nouuid, иначе система может отказаться монтировать snapshot из-за совпадающего UUID.

sudo mkdir -p /mnt/root-snap
sudo mount -o ro,nouuid /dev/vg0/root_before_upgrade /mnt/root-snap
ls -la /mnt/root-snap

Теперь можно сделать файловый backup. Например, архивировать содержимое snapshot, а не живого root-тома. В реальной схеме архив лучше отправлять на внешний storage, другой сервер или объектное хранилище, а не оставлять на том же диске. Для регулярных удалённых копий полезно отдельно изучить подходы из инструкции по backup в S3-совместимое хранилище через Restic и Borg.

sudo mkdir -p /backup
sudo tar --xattrs --acls --one-file-system -cpf /backup/root-before-upgrade.tar /mnt/root-snap
sudo sync
sudo umount /mnt/root-snap

Параметр --one-file-system важен для root-раздела: он не даёт архиватору уйти в примонтированные псевдофайловые системы и другие тома. Для backup отдельного каталога или отдельного тома набор параметров можно адаптировать.

Консистентность: что делать с базами данных и приложениями

LVM snapshot фиксирует блоковое состояние диска. Это не означает, что каждое приложение внутри тома окажется в логически консистентном состоянии. Файловая система обычно восстановит журнал, но база данных может иметь незавершённые транзакции, буферы в памяти и собственные WAL/binlog-механизмы.

Для простого сайта с PHP-файлами и статикой snapshot часто достаточно безопасен. Для MySQL, MariaDB, PostgreSQL, Redis, RabbitMQ и почтовых хранилищ лучше подготовить приложение к снимку: сбросить данные на диск, на короткое время остановить запись или использовать штатный механизм backup.

Пример осторожного подхода для MySQL или MariaDB: перед snapshot выполнить flush и заблокировать таблицы на короткое время в отдельной сессии. Но держать глобальный lock долго нельзя: приложение может начать зависать. На практике для баз часто удобнее использовать специализированные инструменты, а LVM snapshot применять как дополнительный слой для файловой консистентности.

Для PostgreSQL лучше использовать штатные механизмы резервного копирования и WAL. Если всё же делаете snapshot тома с данными, убедитесь, что понимаете режим восстановления после crash-consistent состояния. PostgreSQL обычно умеет подниматься после аварийного снимка, но это не отменяет проверки restore. Для критичных баз посмотрите отдельный материал про PITR и восстановление PostgreSQL по WAL.

Для системных обновлений сценарий проще: создаём snapshot root-тома, обновляем пакеты, проверяем сервисы. Если всё хорошо — удаляем snapshot. Если плохо — делаем rollback.

Контроль заполнения snapshot

После создания снимка обязательно следите за Data%. Это процент заполнения области snapshot. Чем ближе к 100%, тем выше риск, что снимок станет бесполезным.

sudo lvs -a -o lv_name,origin,lv_size,data_percent,metadata_percent,lv_attr
watch -n 5 sudo lvs -a -o lv_name,origin,lv_size,data_percent,lv_attr

Если Data% растёт быстрее ожиданий, не продолжайте рискованную операцию вслепую. Возможные варианты: срочно завершить backup и удалить snapshot, увеличить snapshot, если есть свободное место, или остановить изменение данных.

Увеличить классический snapshot можно командой lvextend. Например, добавить ещё 5 ГБ:

sudo lvextend -L +5G /dev/vg0/root_before_upgrade
sudo lvs -a -o lv_name,origin,lv_size,data_percent

Это работает только если в volume group есть свободное место. Если VFree уже ноль, расширять snapshot некуда. Поэтому лучше заранее оставить запас, особенно на VDS с активной записью.

Rollback через lvconvert: откат к snapshot

Rollback в LVM обычно выполняется через merge snapshot обратно в origin. Команда называется lvconvert --merge. После merge состояние origin-тома возвращается к моменту создания snapshot, а сам snapshot исчезает.

Для отдельного тома данных, который можно остановить и размонтировать, порядок такой:

1. остановить сервисы, которые пишут на том;
2. размонтировать файловую систему;
3. запустить merge snapshot;
4. активировать и снова смонтировать том;
5. проверить данные и запустить сервисы.

sudo systemctl stop myapp.service
sudo umount /srv/data
sudo lvconvert --merge /dev/vg0/data_before_change
sudo lvchange -ay /dev/vg0/data
sudo mount /srv/data
sudo systemctl start myapp.service

С root-томом всё сложнее, потому что он активен и смонтирован. LVM не сможет немедленно слить snapshot в используемый origin так, как с отключенным томом. Обычно merge будет запланирован на следующую активацию тома, то есть на reboot.

sudo lvconvert --merge /dev/vg0/root_before_upgrade
sudo reboot

После перезагрузки система должна активировать origin уже в откатанном состоянии. Если сервер не загрузился из-за повреждённого bootloader, ошибки initramfs или другой проблемы вне LVM-тома, понадобится rescue-режим. Поэтому перед рискованным изменением убедитесь, что у вас есть доступ к консоли VDS и понятный план восстановления.

Перед lvconvert --merge остановитесь и проверьте имя snapshot. Merge — разрушительная операция для изменений, сделанных после снимка. Нельзя «чуть-чуть откатить только один файл», если вы сливаете snapshot всего тома.

Проверить доступные snapshot и их origin можно так:

sudo lvs -a -o lv_name,vg_name,origin,lv_size,data_percent,lv_attr,devices

Если нужно вернуть отдельные файлы, а не весь том, лучше не делать merge. Смонтируйте snapshot read-only и скопируйте нужные файлы вручную.

sudo mkdir -p /mnt/root-snap
sudo mount -o ro,noload /dev/vg0/root_before_upgrade /mnt/root-snap
sudo cp -a /mnt/root-snap/etc/nginx/nginx.conf /etc/nginx/nginx.conf
sudo umount /mnt/root-snap

Для XFS в этом примере вместо ro,noload используйте ro,nouuid. После восстановления отдельных файлов проверьте права, контекст SELinux на RHEL-based системах и синтаксис конфигурации соответствующего сервиса.

Удаление snapshot после успешной операции

Если обновление прошло успешно и rollback больше не нужен, snapshot нужно удалить. Не оставляйте его «на всякий случай» на недели: он будет занимать место, ухудшать предсказуемость I/O и может переполниться в неподходящий момент.

sudo lvs -a -o lv_name,origin,lv_size,data_percent,lv_attr
sudo lvremove /dev/vg0/root_before_upgrade
sudo lvs -a

Если snapshot был смонтирован, сначала размонтируйте его:

sudo umount /mnt/root-snap
sudo lvremove /dev/vg0/root_before_upgrade

Если система сообщает, что устройство занято, найдите процессы, которые держат файлы на mount point.

sudo lsof +f -- /mnt/root-snap
sudo fuser -vm /mnt/root-snap

Не удаляйте snapshot, пока с него идёт backup или пока вы используете его как источник восстановления файлов. Но и не держите его дольше необходимого.

Thin snapshots: чем отличаются от классических

В современных установках LVM может использовать thin provisioning: есть thin pool, а внутри него thin volumes. Для thin snapshots не нужно заранее выделять отдельный размер под каждый снимок той же логикой, что у classic snapshot. Место расходуется из thin pool, а snapshot создаётся очень быстро.

Проверить, есть ли thin pool, можно по атрибутам LVM:

sudo lvs -a -o lv_name,vg_name,lv_size,pool_lv,origin,data_percent,metadata_percent,lv_attr

Если том находится в thin pool, snapshot обычно создаётся так:

sudo lvcreate -s -n root_thin_before_upgrade /dev/vg0/root
sudo lvs -a -o lv_name,pool_lv,origin,data_percent,metadata_percent,lv_attr

У thin snapshots другой основной риск: заполнение самого thin pool или его metadata. Если thin pool заполнится, последствия могут быть неприятнее, чем у обычного snapshot. Поэтому мониторить нужно не только snapshot, но и Data%, Metadata% у pool.

Если thin pool растёт, его можно расширить при наличии свободного места в volume group:

sudo lvextend -L +10G /dev/vg0/thinpool
sudo lvextend --poolmetadatasize +1G /dev/vg0/thinpool
sudo lvs -a -o lv_name,lv_size,data_percent,metadata_percent

Для production-сервера с thin pool желательно настроить autoextend, но это отдельная тема. В контексте rollback перед обновлением главное — не создавать много snapshot и не забывать удалять их после проверки.

Практический сценарий: безопасное обновление Linux VDS

Ниже — рабочий runbook для типовой задачи: перед обновлением системы создать snapshot root-тома, выполнить upgrade, проверить сервисы и либо удалить snapshot, либо откатиться.

1. Проверить состояние диска и LVM

df -h
lsblk -f
sudo vgs
sudo lvs -a -o lv_name,vg_name,lv_size,origin,data_percent,lv_attr

Убедитесь, что root действительно на LVM, а в volume group есть свободное место. Если свободного места мало, сначала решите вопрос с диском. Делать snapshot на последние гигабайты — плохая идея.

2. Создать snapshot

sudo lvcreate -s -n root_pre_upgrade -L 8G /dev/vg0/root
sudo lvs -a -o lv_name,origin,lv_size,data_percent

Размер 8 ГБ здесь условный. Для вашего VDS подберите размер по активности записи и объёму изменений. Если обновление затрагивает много пакетов, Docker images или базы, запас должен быть больше.

3. Выполнить обновление

Для Debian и Ubuntu:

sudo apt update
sudo apt upgrade
sudo systemctl --failed

Для AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux и Fedora:

sudo dnf upgrade
sudo systemctl --failed

После обновления проверьте ключевые сервисы: web-сервер, PHP-FPM, базу данных, очереди, cron/systemd timers, доступность сайта снаружи, логи ошибок.

sudo systemctl status nginx
sudo systemctl status php-fpm
sudo systemctl status mariadb
sudo journalctl -p warning -n 100
sudo lvs -a -o lv_name,origin,lv_size,data_percent

Названия сервисов отличаются. На Debian/Ubuntu PHP-FPM часто называется вроде php8.3-fpm, а на RHEL-based системах — php-fpm. Проверяйте фактическое имя через systemctl list-units.

4. Если всё хорошо — удалить snapshot

sudo lvremove /dev/vg0/root_pre_upgrade
sudo lvs -a

5. Если всё плохо — выполнить rollback

sudo lvconvert --merge /dev/vg0/root_pre_upgrade
sudo reboot

После reboot проверьте, что система вернулась к ожидаемому состоянию, а snapshot исчез из списка. Затем разберите причину неудачного обновления уже без спешки: конфликт пакетов, несовместимость версии PHP, ошибка конфигурации, нехватка места, проблема с драйвером или initramfs.

Типичные ошибки и как их избежать

Первая ошибка — считать snapshot полноценным backup. Он живёт на том же диске и зависит от той же LVM-структуры. Если вы случайно удалите volume group, потеряете виртуальный диск или повредите thin pool, snapshot не спасёт. Для важных данных нужен внешний backup и регулярная проверка восстановления.

Вторая ошибка — создавать слишком маленький snapshot. На спокойном сервере 2 ГБ могут прожить часами, а на активной базе заполниться за минуты. Следите за Data% сразу после создания снимка и во время операции.

Третья ошибка — делать rollback не того тома. На серверах с несколькими LV легко перепутать root_pre_upgrade, var_pre_upgrade и mysql_pre_upgrade. Перед lvconvert --merge всегда смотрите origin.

Четвёртая ошибка — монтировать XFS snapshot без nouuid. Если видите ошибку про duplicate UUID, не пытайтесь менять UUID основного тома. Смонтируйте snapshot правильно, read-only и с nouuid.

Пятая ошибка — забыть про приложения. Snapshot тома с файлами сайта и snapshot тома с живой базой — разные по риску операции. Для базы данных планируйте консистентность отдельно: dump, WAL/binlog, штатный backup-инструмент, короткая остановка записи или проверенный crash-recovery сценарий.

Мини-чеклист перед использованием LVM snapshot

• Я знаю точное имя origin-тома и snapshot.
• В volume group достаточно свободного места.
• Я понимаю, сколько примерно будет записано данных во время операции.
• Для базы данных есть отдельный план консистентности.
• Snapshot нужен на минуты или часы, а не на недели.
• Есть внешний backup для действительно ценных данных.
• Я проверил доступ к консоли или rescue-режиму VDS на случай проблем с загрузкой.
• Я знаю команду rollback и понимаю, какие изменения будут потеряны.

Итоги

LVM snapshots на Linux VDS — удобный инструмент для быстрых и контролируемых изменений. С их помощью можно зафиксировать состояние тома перед обновлением, снять более аккуратный backup, протестировать миграцию и выполнить rollback через lvconvert --merge, если что-то пошло не так.

Ключ к безопасной работе — дисциплина. Создавайте snapshot осознанно, закладывайте место под изменения, мониторьте Data%, не забывайте про консистентность баз данных и удаляйте снимок сразу после успешной проверки. Тогда lvcreate и lvconvert будут не «магическими командами на удачу», а нормальной частью админского runbook для VDS.