Ручной снимок перед pacman -Syu — хорошая привычка, пока ты о ней помнишь. ALPM-хуки переносят эту обязанность на сам пакетный менеджер: система создаёт снимок до изменений и, при необходимости, после них. Тебе остаётся решить, доверить работу готовому snap-pac или написать узкий хук под свою схему снапшотов.
После неудачного обновления файлы менеджера пакетов уже могут не совпадать с реально загруженной системой. Ручное восстановление отдельных библиотек нередко превращается в новый слой проблем. Снимок до pacman -Syu сохраняет согласованное состояние, из которого можно вернуться целиком.
Автоматизация нужна не только ради полного обновления. Установка или удаление пакета тоже запускает пакетную транзакцию, а причина проблемы не всегда очевидна. Хук на Upgrade защищает обычный сценарий, а более широкий триггер можно применить к установке и удалению.
Механизм особенно полезен, когда рядом работает grub-btrfs: снимок получает запись в меню загрузки, и после неудачной загрузки ты получаешь отдельный вариант старой системы. Настройку корневого btrfs, конфигурацию snapper, таймлайн и очистку я оставляю в базовом гайде по снапшотам с первого дня. Здесь разбирается только связка ALPM-хуков с автоматическим снимком.
ALPM — библиотека, которой пользуется pacman. Она читает файлы с расширением .hook и запускает подходящие действия вокруг транзакции. Системные хуки лежат в /usr/share/libalpm/hooks, а пользовательские — в /etc/pacman.d/hooks. Свои правила лучше держать во втором каталоге: обновление пакета с настройками pacman не затрёт их.
У каждого хука есть одна или несколько секций [Trigger] и одна секция [Action]. В [Trigger] находятся условия совпадения: Operation, Type и Target. Например, Operation = Upgrade выбирает обновление, Type = Package работает с пакетами, а Target = * разрешает любой пакет.
Секция [Action] определяет момент и команду. Значение When = PreTransaction запускает действие до распаковки и замены файлов пакетов, а When = PostTransaction — после успешного завершения изменений. Поле Exec содержит исполняемый файл и аргументы. Неудачный PostTransaction не запускается, зато снимок pre остаётся полезным резервом после прерванного обновления.
Для надёжности в пример можно добавить Depends = snapper и AbortOnFail. Первая строка запрещает запуск без зависимости, вторая останавливает pacman, если снимок создать не удалось. Для операций, где лучше продолжить обновление несмотря на ошибку вспомогательного действия, AbortOnFail не указывают.
snap-pac добавляет два хука: один создаёт снимок перед пакетной транзакцией, второй — после неё. Установи его из официальных репозиториев:
sudo pacman -S snap-pac
Пакет создаёт файлы snap-pac-pre.hook и snap-pac-post.hook в /etc/pacman.d/hooks. Они реагируют на установку, обновление и удаление пакетов. В описаниях снимков будут пометки вроде pacman pre и pacman post, поэтому состояние до и после легко различить в списке.
Пакет использует конфигурацию snapper. Если у тебя одна группа снимков для корня, дополнительной настройки обычно не нужно. Если групп несколько, выбери нужную в /etc/snapper/configs/snap-pac: параметр NUMBER задаёт имя конфигурации, а EMPTY_PRE_POST определяет, создавать ли пустые снимки для транзакций без изменений файлов. Перед первой проверкой посмотри доступные снимки:
sudo snapper list
Выполни небольшое обновление и снова открой список. В нём должны появиться парные записи до и после. Если снимка нет, сначала проверь, что конфигурация NUMBER существует, а каталог /etc/pacman.d/hooks содержит оба файла с суффиксом .hook.
Готовое решение удобно, но узкий хук лучше показывает механизм без лишних снимков. Ниже он создаёт одну запись в конфигурации single перед обновлением любого пакета. Создай файл:
sudo mkdir -p /etc/pacman.d/hooks
sudo nano /etc/pacman.d/hooks/00-snapshot.hook
Полное содержимое /etc/pacman.d/hooks/00-snapshot.hook:
[Trigger]
Operation = Upgrade
Type = Package
Target = *
[Action]
Description = Create a Snapper snapshot before package upgrades
Depends = snapper
When = PreTransaction
Exec = /usr/bin/snapper -c single create --description "pacman pre-upgrade"
AbortOnFail
Описание после --description попадёт в метаданные снимка. Поле Exec не запускает shell, поэтому передавай путь и аргументы напрямую. Если кавычки разбираются неверно, используй короткий отдельный скрипт и вызывай его из хука: так легче добавить проверку кодов возврата, временную метку или список пакетов.
Вместо Snapper можно вызвать btrfs напрямую:
Exec = /usr/bin/btrfs subvolume snapshot / @pre-upgrade
Здесь / должен указывать на корневой subvolume, а @pre-upgrade — на имя нового снимка. Если корневой subvolume называется не @, замени оба пути на свою схему монтирования и размещения снимков. Не используй исходный путь файловой системы, если / смонтирован не из нужного subvolume.
У прямой команды btrfs есть два ограничения. Фиксированное имя вскоре займёт следующую транзакцию, а у снимка не будет удобного описания и политики хранения. Snapper назначает уникальный номер, хранит описание и применяет лимиты. Для регулярных обновлений он удобнее; прямой btrfs subvolume snapshot подходит для минимального одноразового хука.
Перед реальным обновлением загляни в список снимков и запомни номер последней записи. Затем запусти pacman -Syu. Хук сработает один раз для всей пакетной транзакции, даже если пакетов сотня, и остановит pacman до замены файлов при ошибке снимка.
После успешного обновления новая запись должна иметь описание pacman pre-upgrade. Удали её вручную, если обновление прошло без инцидентов и отдельный post тебе не нужен. Если post-хука нет, сравнивать нечего — состояние после транзакции можно оценить обычной загрузкой и проверкой сервисов.
При сбое выбери в списке Snapper запись с меткой pre, затем загрузись с неё через меню grub-btrfs. Полный порядок действий, включая выбор снимка в меню GRUB и проверку загрузчика, разобран в материале про стратегию отката через grub-btrfs. Снимок восстанавливает файловую систему, но не исправляет ошибки в базах pacman; для сложной локализации сначала загрузись с Live ISO.
/home?Обычно нет. Если /home — отдельный subvolume, снимок корневого / его не захватит. Это полезное разделение: системный откат не затрагивает рабочие файлы, а /home защищают собственные снимки или резервные копии. Хук для /home создаёт дополнительную нагрузку и не заменяет резервное копирование пользовательских файлов.
Да. pacman -Syu — одна транзакция с несколькими пакетами, поэтому для неё нужен один снимок pre, а не отдельная копия на каждый пакет. Повторная установка уже установленного пакета также учитывается ALPM как обновление, значит триггер Operation = Upgrade подходит. При намеренном сносе большого набора пакетов оцени размер снимка и место в btrfs до запуска команды.
Добавь строки Operation = Install и Operation = Remove в секцию [Trigger]. Не запускай одновременно snap-pac и собственный хук с теми же триггерами: получишь дублирующие снимки без новой пользы. Для одной выбранной схемы оставь оба When у snap-pac либо создай отдельные файлы для нужных моментов времени.
Обычно PreTransaction задерживает pacman на доли секунды: btrfs фиксирует изменения свойств, а не копирует весь корень. На системе с высокой нагрузкой или большим числом изменений пауза может стать заметнее. Хук выполняется синхронно, поэтому pacman ждёт его завершения и продолжает транзакцию только после успешного кода выхода.
snap-pac?Нет. Ручной снимок перед pacman -Syu полезен для контролируемого эксперимента, но он не заменяет hook: следующий автоматический снимок всё равно создастся из более свежего состояния. Если ручной процесс уже разобран в старом руководстве перед обновлением, теперь его можно оставить только для особых случаев.
Автоматический снимок полезнее ручного тогда, когда он привязан к самой транзакции pacman. Для большинства систем snap-pac решает задачу парой команд; собственный 00-snapshot.hook даёт контроль над триггером, описанием и поведением при ошибке. Проверь создание записи, убедись, что grub-btrfs видит снимок, и тогда точка отката появится до следующего обновления, а не после первой поломки.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии