Откат тома данных через снимок LVM с проверкой результата

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

1. Определите целевой том и границы отката

В статье рассматриваются Debian 13, файловая система ext4 и классический том данных LVM. Процедура не распространяется на корневую файловую систему, загрузочные тома и тонкие пулы. Стандартная конфигурация CloudUDP включает два накопителя NVMe по 1 ТБ, каждый с прямым подключением, без аппаратного RAID. Это не означает, что в системе уже настроен LVM: фактическую схему хранения необходимо проверить на сервере.

Сначала зафиксируйте источник монтирования, тип файловой системы, атрибуты логических томов и свободное место в группе томов:

findmnt -T /srv/appdata -o SOURCE,TARGET,FSTYPE,OPTIONS
sudo lvs -a -o vg_name,lv_name,lv_attr,segtype,origin,data_percent
sudo vgs -o vg_name,vg_size,vg_free
sudo lsblk -f

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

Далее предполагается, что том данных — vgdata/appdata, точка монтирования — /srv/appdata, а связанная служба — app.service. Замените эти имена фактическими значениями и убедитесь, что нет вложенных точек монтирования и других процессов, выполняющих запись. Команды следует выполнять по этапам, а не копировать и запускать всю статью целиком.

Снимок не заменяет резервную копию

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

Слияние снимка отменит все записи на том, выполненные после его создания. Если после обновления приложение уже принимало рабочие запросы, сначала экспортируйте новые данные, которые необходимо сохранить, и убедитесь в их совместимости со старой версией программы. Выполнять откат сразу нельзя.

2. Остановите службы и создайте согласованную точку восстановления

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

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

sudo systemctl stop app.service
sudo fuser -vm /srv/appdata
sudo sync
sudo umount /srv/appdata

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

sudo lvcreate --snapshot --size 20G \
  --name preupgrade /dev/vgdata/appdata
sudo lvs -o lv_name,lv_attr,origin,data_percent vgdata
sudo mount /srv/appdata

Значение 20G здесь задаёт демонстрационный размер пространства снимка. Это не характеристика продукта и не универсальная рекомендация. Перед выполнением команды убедитесь, что в группе томов достаточно свободного места и что том preupgrade ещё не существует. Размер снимка следует оценивать по объёму блоков, которые будут изменены за период наблюдения, в течение которого допускается откат, а не автоматически выбирать как долю общей ёмкости исходного тома.

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

3. Проверьте снимок в режиме только для чтения и следите за заполнением

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

sudo mkdir -p /mnt/app-preupgrade
sudo mount -t ext4 -o ro,noload \
  /dev/vgdata/preupgrade /mnt/app-preupgrade
sudo sha256sum /mnt/app-preupgrade/manifest.json \
  | sudo tee /root/app-preupgrade.sha256
sudo umount /mnt/app-preupgrade

manifest.json обозначает выбранный стабильный файл с данными приложения. Заранее убедитесь, что он существует и подходит для проверки восстановления. Файл с контрольной суммой хранится вне целевого тома. После отката сравнивайте только поле с контрольной суммой, а не путь монтирования.

Оценивайте риск по объёму изменений

sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata
sudo vgs -o vg_name,vg_free

Data% показывает долю занятого пространства классического снимка, а не заполнение файловой системы исходного тома. Регулярно снимайте показания до и после обновления и следите за скоростью роста. Массовая перестройка индексов, перезапись больших файлов и подобные операции могут быстро израсходовать доступное место.

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

sudo lvextend -L +10G /dev/vgdata/preupgrade

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

4. Выполните слияние без доступа к тому и проверьте восстановление

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

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

sudo systemctl stop app.service
sudo umount /srv/appdata
sudo lvchange -an /dev/vgdata/appdata
sudo lvconvert --merge /dev/vgdata/preupgrade
sudo lvchange -ay /dev/vgdata/appdata
sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata

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

sudo mount /srv/appdata
sudo sha256sum /srv/appdata/manifest.json
sudo cat /root/app-preupgrade.sha256

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

5. Превратите результаты репетиции в контрольный список обновления

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

• Целевой объект — существующий классический том данных LVM; источник монтирования соответствует имени тома.
• Все процессы, выполняющие запись, можно остановить; исходный том штатно размонтируется; независимая резервная копия проверена.
• Размер снимка обоснован ожидаемым объёмом изменений, а в группе томов оставлен запас для расширения.
• Доступны старая версия программы, конфигурация вне тома и перечень данных для проверки восстановления.
• Определены способ сохранения новых записей и условия возобновления работы приложения.

После успешной проверки обновления и окончания периода наблюдения для возможного отката убедитесь, что снимок не смонтирован. Если он ещё существует, удалите его командой lvremove /dev/vgdata/preupgrade. Снимок, который уже был объединён с исходным томом, повторно удалять не нужно.

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

Часто задаваемые вопросы