AlmaLinux и Rocky Linux: dnf history, rollback и snapshots

Привет! На связи Вася из Fastfox. Сегодня разберём практичную тему для админов, которые обслуживают AlmaLinux и Rocky Linux на боевых серверах: как использовать dnf history, чем он отличается от настоящего rollback, где всё ещё встречается yum history и почему snapshots почти всегда надёжнее, чем надежда «DNF сам всё откатит».

AlmaLinux и Rocky Linux наследуют подход Enterprise Linux: пакеты обновляются транзакциями, зависимости рассчитываются менеджером пакетов, а история операций сохраняется. Это удобно: можно посмотреть, что именно изменилось, кто и когда поставил пакет, какие зависимости приехали вместе с обновлением, какие пакеты были удалены.

Но важно понимать границу ответственности: dnf history управляет пакетами, а не состоянием всего сервера. Он не откатывает пользовательские файлы, базу данных, почту, загруженные медиафайлы и ручные изменения конфигурации так, как это делает снимок диска или полноценный backup.

dnf history undo — это откат пакетной транзакции. Snapshot — это откат состояния диска или тома. Для продакшена лучше иметь оба инструмента и понимать, когда применять каждый.

Что такое dnf history в AlmaLinux и Rocky Linux

dnf history — журнал транзакций DNF. В него попадают операции установки, обновления, удаления и переустановки пакетов. Каждая операция получает ID, по которому можно открыть детали: список изменённых пакетов, команду, время, пользователя, статус завершения.

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

sudo dnf history list

Для конкретной транзакции:

sudo dnf history info 42

DNF покажет, какие пакеты были установлены, обновлены, удалены или понижены. В типовой аварии это сразу экономит время: вместо абстрактного «после обновления всё сломалось» вы видите, что менялись, например, openssl-libs, httpd, nginx, php-fpm, mariadb-server или kernel-пакеты.

yum history: почему команда ещё работает

В старых инструкциях по CentOS и RHEL часто встречается yum history. В AlmaLinux и Rocky Linux команда yum обычно является совместимой обёрткой над DNF. Поэтому многие привычные команды работают:

sudo yum history list

sudo yum history info 42

Но для новых систем лучше писать и документировать именно dnf. Так меньше путаницы в командах, логах, runbook и Ansible-ролях. Если команда выполняется на Enterprise Linux 8/9-совместимых системах, ориентируйтесь на dnf history, а yum history воспринимайте как совместимость для старых привычек.

Подготовка перед обновлением: без неё rollback превращается в лотерею

Самая частая ошибка — обновлять продакшен «как на ноутбуке»: зашёл по SSH, выполнил dnf upgrade -y, перезагрузил и надеешься, что всё будет хорошо. Иногда действительно хорошо. Но если сервер обслуживает сайт, почту, базу данных, API или панель управления, лучше подготовить короткий план.

Перед обновлением полезно зафиксировать текущее состояние системы:

cat /etc/os-release

uname -r

sudo dnf repolist

sudo dnf check

sudo dnf history list | head

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

Также проверьте свободное место. Для обновлений, кеша пакетов и snapshots это критично:

df -h

sudo dnf clean expire-cache

sudo du -sh /var/cache/dnf

Если корневой раздел заполнен на 95–100%, rollback может не спасти. DNF не сможет скачать пакеты, RPM-база может остаться в промежуточном состоянии, а LVM snapshot быстро переполнится при активной записи.

Как смотреть историю транзакций DNF

Базовый список выглядит так:

sudo dnf history list

Детальная карточка транзакции:

sudo dnf history info 42

Если нужно понять, какие операции затрагивали конкретный пакет:

sudo dnf history list nginx

sudo dnf history list php-fpm

sudo dnf history list kernel

Для диагностики после инцидента полезно сравнить историю DNF с журналом systemd:

sudo journalctl --since today -p warning

sudo journalctl -u nginx --since today

sudo journalctl -u php-fpm --since today

Так вы увидите не только факт обновления, но и последствия: падение сервиса, ошибку загрузки модуля, конфликт версии библиотеки, проблему с SELinux-контекстом или несовместимый параметр конфигурации.

dnf history undo: откат одной транзакции

Команда dnf history undo пытается отменить выбранную транзакцию. Если пакет был обновлён, DNF попробует вернуть старую версию. Если пакет был установлен, DNF попробует удалить его. Если пакет был удалён, DNF попробует установить его обратно.

sudo dnf history undo 42

Перед реальным выполнением полезно сделать пробный запуск без изменений:

sudo dnf history undo 42 --assumeno

Опция --assumeno отвечает «нет» на подтверждение, но показывает план действий. Это хороший способ проверить, не собирается ли DNF снести половину стека из-за зависимостей.

На практике undo хорошо работает для небольших понятных транзакций: поставили пакет, обновили один сервис, случайно удалили зависимость. Но если транзакция была большой и затронула системные библиотеки, ядро, Python-модули, web stack и зависимости базы данных, откат может быть неполным или рискованным.

dnf history rollback: откат к состоянию до указанной транзакции

dnf history rollback часто понимают неправильно. Это не «верни весь сервер в прошлое». Команда пытается откатить пакетную базу к состоянию на момент выбранной транзакции, отменяя более поздние операции настолько, насколько это возможно.

sudo dnf history rollback 40

Здесь DNF будет пытаться привести набор пакетов к состоянию после транзакции с ID 40. Все транзакции после неё должны быть отменены в рамках возможностей репозиториев и доступных версий пакетов.

Пробный запуск также обязателен:

sudo dnf history rollback 40 --assumeno

Почему rollback может не сработать идеально? Типовые причины такие:

• старая версия пакета уже недоступна в подключённых репозиториях;
• изменились зависимости между пакетами;
• часть пакетов была из сторонних репозиториев;
• конфигурационные файлы в /etc были изменены вручную или скриптами;
• данные приложения или базы данных уже мигрировали в новый формат;
• обновлялось ядро, bootloader или драйверы.

Поэтому rollback — инструмент восстановления пакетной части системы, а не замена backup и snapshot.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Где dnf history действительно помогает

Я бы использовал dnf history в трёх сценариях. Первый — расследование: нужно быстро понять, что менялось перед сбоем. Второй — точечный откат небольшой транзакции. Например, установили не тот пакет, обновили один демон, подключили лишний модуль. Третий — документирование изменений: ID транзакции удобно прикладывать к заявке, инциденту или внутреннему changelog.

Пример аккуратного порядка действий после неудачного обновления сервиса:

1. Посмотреть последние транзакции через dnf history list.
2. Открыть детали подозрительной транзакции через dnf history info ID.
3. Проверить логи конкретного сервиса.
4. Сделать пробный dnf history undo ID --assumeno.
5. Если план безопасен — выполнить undo и перезапустить сервис.
6. Если затронуты системные пакеты или база данных — рассмотреть восстановление из snapshot.

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

Ограничения dnf rollback: важные нюансы

DNF не откатывает содержимое пользовательских данных. Если после обновления приложение выполнило миграцию базы данных, изменило структуру таблиц или перезаписало файлы в /var/lib, команда dnf history undo это не вернёт.

DNF также не является системой контроля версий для /etc. RPM умеет сохранять некоторые конфигурационные файлы как .rpmsave или .rpmnew, но это не полноценный rollback конфигурации. Если вы поменяли nginx.conf, php.ini, unit-файл systemd или настройки базы данных, история DNF не знает вашей логики.

Отдельная тема — ядро. Обновление kernel-пакетов обычно не удаляет старые ядра сразу, а хранит несколько версий. Поэтому безопаснее не откатывать ядро через общий rollback, а выбрать предыдущую рабочую версию при загрузке или настроить её как default.

sudo grubby --info=ALL

sudo grubby --default-kernel

sudo grubby --set-default /boot/vmlinuz-5.14.0-427.13.1.el9_4.x86_64

sudo reboot

Версию в команде нужно подставлять свою из вывода grubby --info=ALL. После загрузки проверьте активное ядро:

uname -r

Snapshots: настоящая страховка перед обновлением

Snapshot — это снимок состояния диска, тома или файловой системы на конкретный момент. В отличие от dnf history, он может вернуть не только пакеты, но и конфиги, данные, кеши, состояние приложений на диске. Именно поэтому перед большим обновлением AlmaLinux или Rocky Linux на VDS snapshot обычно важнее, чем надежда на dnf rollback.

Но snapshot тоже не магия. Если база данных активно пишет на диск, простой crash-consistent snapshot может быть похож на состояние после внезапного отключения питания. Современные СУБД обычно умеют восстанавливаться после такого, но для критичных данных лучше делать application-consistent подготовку: дамп, flush, остановку сервиса на короткое окно или fsfreeze при понимании последствий.

Хорошая практика: перед крупным обновлением иметь как минимум свежий backup данных и snapshot системного диска. Backup нужен для данных, snapshot — для быстрого возврата системы.

Если у вас PostgreSQL, посмотрите отдельный материал про PITR-восстановление PostgreSQL через WAL. Для MySQL и MariaDB полезен разбор Point-in-Time Recovery через binlog и GTID. Снимок диска не отменяет таких процедур, а дополняет их.

Вариант 1: snapshot на уровне платформы VDS

Если сервер работает как VDS, самый простой вариант — сделать snapshot в панели управления провайдера перед обновлением. Обычно это снимок всего виртуального диска или набора дисков. Плюс такого подхода — не нужно заранее проектировать LVM или Btrfs внутри гостевой ОС. Минус — восстановление чаще всего откатывает весь диск целиком, а не один пакет или каталог.

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

Минимальный чек-лист перед snapshot:

• проверить свободное место и состояние файловой системы;
• убедиться, что нет незавершённых обновлений DNF;
• сохранить дамп базы данных или проверить свежий backup;
• записать текущий ID последней транзакции DNF;
• запланировать окно работ и критерии успешного обновления.

Последний ID транзакции можно зафиксировать так:

sudo dnf history list | head

После snapshot выполняйте обновление:

sudo dnf upgrade

А затем проверяйте сервисы:

systemctl --failed

sudo journalctl -p err --since today

ss -lntup

Вариант 2: LVM snapshot внутри AlmaLinux или Rocky Linux

На многих установках Enterprise Linux корневой раздел находится на LVM. Это удобно: можно создать snapshot логического тома перед обновлением. Сначала посмотрите структуру томов:

sudo lvs

sudo vgs

sudo lsblk -f

Если корень расположен на LVM, snapshot создаётся так:

sudo lvcreate --snapshot --name root_pre_dnf_2026_07_01 --size 10G /dev/almalinux/root

Путь /dev/almalinux/root у вас может отличаться: на Rocky Linux группа томов может называться rocky, на AlmaLinux — almalinux, а при ручной разметке имя может быть любым.

Размер snapshot — это не размер всего корня, а пространство под изменения после создания снимка. Если вы выделили 10 ГБ, а за время обновления на исходном томе изменилось больше блоков, snapshot переполнится и станет бесполезен. Для больших обновлений, активных баз данных и контейнерных хостов закладывайте запас.

Проверять заполнение snapshot можно так:

sudo lvs -a

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

sudo lvremove /dev/almalinux/root_pre_dnf_2026_07_01

Если нужно посмотреть файлы из snapshot, можно смонтировать его только для чтения:

sudo mkdir -p /mnt/root_snap

sudo mount -o ro /dev/almalinux/root_pre_dnf_2026_07_01 /mnt/root_snap

ls /mnt/root_snap

sudo umount /mnt/root_snap

Как откатиться к LVM snapshot

Для отката LVM snapshot обычно используют merge. Делайте это только после понимания последствий: изменения на исходном томе после snapshot будут потеряны.

sudo lvconvert --merge /dev/almalinux/root_pre_dnf_2026_07_01

sudo reboot

Если том активен, merge произойдёт при следующей активации, поэтому перезагрузка — нормальная часть процедуры. Для корневого тома это ожидаемое поведение.

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

Вариант 3: Btrfs и snapper

В AlmaLinux и Rocky Linux по умолчанию чаще встречаются XFS и LVM, но Btrfs тоже можно использовать при ручной разметке или в отдельных сценариях. Если корневая файловая система живёт на Btrfs, можно применять snapshots на уровне файловой системы и инструменты вроде snapper.

Установка и базовая настройка:

sudo dnf install snapper

sudo snapper -c root create-config /

sudo snapper -c root create --description 'before dnf upgrade'

Список снимков:

sudo snapper -c root list

Сравнение изменений между снимками:

sudo snapper -c root status 10..11

Откат отдельных файлов через snapper undochange полезен, когда нужно вернуть конфиг или набор файлов. Но полноценный bootable rollback на Btrfs зависит от разметки subvolume, загрузчика и политики snapshots. Не стоит считать, что одна установка snapper автоматически даёт такой же опыт, как в дистрибутивах, где Btrfs snapshots интегрированы в систему загрузки из коробки.

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

Допустим, у нас AlmaLinux или Rocky Linux с Nginx, PHP-FPM и MariaDB. Нужно обновить систему. Сначала собираем состояние:

cat /etc/os-release

uname -r

sudo dnf check

sudo dnf history list | head

systemctl --failed

df -h

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

После backup создаём snapshot: на уровне VDS-платформы, LVM или Btrfs. Затем обновляем систему без автоматического подтверждения, чтобы увидеть план:

sudo dnf upgrade --assumeno

Если план выглядит ожидаемо, запускаем обновление:

sudo dnf upgrade

После обновления проверяем:

systemctl --failed

sudo systemctl status nginx

sudo systemctl status php-fpm

sudo systemctl status mariadb

sudo journalctl -p err --since today

Если всё хорошо, не спешите сразу удалять snapshot. Подержите его короткое время, достаточное для smoke-тестов: главная страница, авторизация, отправка форм, фоновые задачи, очереди, cron, API, логи ошибок. Но и неделями держать snapshot не нужно: это лишняя нагрузка и риск переполнения.

Что делать, если обновление сломало сервис

Если после обновления не стартует один сервис, начинайте с точной диагностики:

sudo systemctl status nginx

sudo journalctl -u nginx --since today

sudo nginx -t

Для PHP-FPM:

sudo systemctl status php-fpm

sudo journalctl -u php-fpm --since today

php -v

php -m

Если видите, что проблема связана с одним пакетом или небольшой транзакцией, смотрите DNF:

sudo dnf history list

sudo dnf history info 42

sudo dnf history undo 42 --assumeno

Если план undo аккуратный, можно выполнить:

sudo dnf history undo 42

После отката перезапустите сервис и проверьте журналы:

sudo systemctl restart nginx

sudo systemctl restart php-fpm

sudo journalctl -p err --since today

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

DNF versionlock и аккуратное удержание проблемных пакетов

Иногда после инцидента нужно временно удержать пакет на рабочей версии, чтобы следующее обновление не вернуло проблему. Для этого используют plugin versionlock.

sudo dnf install python3-dnf-plugin-versionlock

sudo dnf versionlock add nginx

sudo dnf versionlock list

Снимать блокировку нужно осознанно:

sudo dnf versionlock delete nginx

Не превращайте versionlock в вечное хранилище технического долга. Это временная мера: зафиксировали проблему, открыли задачу, проверили новую версию на staging, сняли lock и обновились. Иначе через год можно получить сервер, где половина пакетов «прибита гвоздями», а обновление безопасности превращается в квест.

Сторонние репозитории: EPEL, Remi, vendor repo

AlmaLinux и Rocky Linux часто используют не только базовые репозитории, но и EPEL, Remi, репозитории панелей управления, мониторинга, баз данных, Node.js, Docker/Podman-стека и других вендоров. Чем больше источников пакетов, тем важнее snapshots.

Перед обновлением проверьте подключённые репозитории:

sudo dnf repolist --enabled

Если у вас подключён сторонний репозиторий только ради одного пакета, ограничивайте его использование. Иначе DNF может подтянуть оттуда больше, чем вы ожидали. В продакшене полезно документировать, зачем подключён каждый repo-файл в /etc/yum.repos.d.

После неудачного обновления из стороннего репозитория dnf history rollback может упереться в отсутствие старых версий. Некоторые vendor repo хранят только актуальные сборки. Snapshot в такой ситуации часто оказывается единственным быстрым способом вернуться назад.

Когда выбирать dnf undo, а когда snapshot rollback

Короткое правило такое: если изменение небольшое, понятное и касается пакетов — пробуйте dnf history undo после dry-run. Если изменение большое, затронуло данные, ядро, системные библиотеки или состояние приложения — используйте snapshot.

Практическая таблица решений:

• Случайно установили лишний пакет — dnf history undo.
• Обновили один сервис, он не стартует из-за версии пакета — сначала dnf history undo, затем анализ.
• Массовое обновление системы на сотни пакетов — snapshot rollback надёжнее.
• Обновление ядра сломало загрузку — выбор старого ядра через GRUB или grubby, при необходимости snapshot.
• Миграция базы данных пошла не так — restore из backup, snapshot только если он согласован с состоянием БД.
• Обновление панели управления изменило много сервисов — snapshot rollback обычно быстрее и чище.

Runbook: минимальный регламент перед dnf upgrade

Чтобы не вспоминать команды в момент аварии, держите короткий runbook. Пример для одиночного VDS:

1. Запланировать окно работ и уведомить ответственных.
2. Проверить dnf check, свободное место и состояние сервисов.
3. Зафиксировать dnf history list | head.
4. Сделать backup данных, особенно баз и пользовательских файлов.
5. Создать snapshot системного диска или LVM/Btrfs snapshot.
6. Выполнить dnf upgrade --assumeno и оценить план.
7. Выполнить обновление.
8. Проверить загрузку, сервисы, логи, HTTP-ответы, фоновые задачи.
9. При небольшой проблеме рассмотреть dnf history undo.
10. При системной проблеме восстановиться из snapshot.
11. После успешной проверки удалить временный snapshot.

Такой регламент занимает немного времени, но резко снижает стресс. Особенно на серверах, где один VDS одновременно держит сайт, базу данных, почту и cron-задачи.

Частые ошибки

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

Вторая ошибка — делать snapshot после обновления, когда всё уже сломалось. Такой снимок полезен для анализа, но не для возврата в рабочее состояние. Снимок для rollback создаётся до изменений.

Третья ошибка — выполнять dnf history rollback без --assumeno. DNF может предложить неожиданный план, особенно если подключены сторонние репозитории. Сначала смотрим, потом действуем.

Четвёртая ошибка — забывать про данные между snapshot и откатом. Если за это время пользователи загрузили файлы, пришли письма, создались заказы или обновились записи в БД, полный откат диска может потерять эти изменения. Поэтому для динамичных систем нужен отдельный план по данным.

Пятая ошибка — держать LVM snapshot слишком долго. Он не предназначен для вечного хранения точки восстановления. Чем дольше snapshot живёт и чем активнее запись, тем выше накладные расходы и риск переполнения.

Итоги

dnf history в AlmaLinux и Rocky Linux — отличный инструмент для расследования и точечного отката пакетных транзакций. yum history в этих системах обычно остаётся как совместимый интерфейс, но в новых инструкциях лучше использовать dnf. Команды undo и rollback полезны, но они не возвращают весь сервер в прошлое: конфиги, данные, состояние базы и файловой системы требуют отдельной стратегии.

Snapshots закрывают другой уровень задачи: они позволяют быстро вернуть диск или том к предыдущему состоянию. Для серьёзных обновлений на VDS лучшая практика — сочетать backup данных, snapshot перед работами и аккуратное использование dnf history для анализа. Тогда даже неудачное обновление становится управляемым процессом, а не ночной лотереей с непонятным финалом.