Снимки Btrfs со Snapper: настройка и восстановление системы

Snapper автоматически делает снимки Btrfs по расписанию и вокруг каждой установки пакетов, а при поломке возвращает отдельные файлы или всю систему. Настройка занимает несколько команд: create-config для корня, лимиты хранения, таймеры и хук пакетного менеджера, после чего обязательно проверьте откат.

Снимки Btrfs и роль Snapper

Снимок Btrfs - это копия подтома, которая создаётся за доли секунды и поначалу почти не занимает места. Файловая система работает по принципу copy-on-write: пока данные не меняются, снимок и рабочая система делят одни и те же блоки. Место начинает расти, только когда вы обновляете пакеты или правите файлы.

Сама Btrfs умеет делать снимки командой btrfs subvolume snapshot, но вести их вручную неудобно. Snapper, утилита родом из openSUSE, берёт рутину на себя: создаёт снимки по расписанию и до и после установки пакетов, чистит старые по правилам, показывает разницу между двумя точками и откатывает отдельные файлы.

Одно ограничение нужно держать в голове с самого начала: снимки лежат на том же диске. Если накопитель умрёт, они умрут вместе с ним. Это машина времени для неудачных обновлений и кривых правок конфигов, а не резервная копия. Для копий на другой носитель есть Borg и Restic, о них статья про схему 3-2-1.

Проверяем файловую систему и схему подтомов

Сначала убедитесь, что корень действительно на Btrfs, и посмотрите, какие подтома создал установщик:

findmnt -no FSTYPE,SOURCE /
sudo btrfs subvolume list /
grep btrfs /etc/fstab

От схемы зависит, как потом делать полный откат. Самые частые варианты:

Хорошая схема держит /home, логи и кэш пакетов в отдельных подтомах. Тогда откат системы не вернёт старые документы и не раздует снимки кэшем загрузок. Если вы только планируете установку, загляните в статью о разметке диска.

Установка Snapper и первая конфигурация

# Debian, Ubuntu
sudo apt install snapper
# Fedora
sudo dnf install snapper
# Arch
sudo pacman -S snapper

Конфигурация для корня создаётся одной командой. Snapper запишет файл /etc/snapper/configs/root и создаст подтом /.snapshots:

sudo snapper -c root create-config /
sudo snapper list-configs

Если подтом @snapshots уже есть

В Arch после archinstall каталог /.snapshots уже смонтирован из отдельного подтома, и create-config откажется работать. Обходной путь из ArchWiki: временно убрать каталог, дать Snapper создать конфиг, удалить созданный им вложенный подтом и вернуть свой:

sudo umount /.snapshots
sudo rm -r /.snapshots
sudo snapper -c root create-config /
sudo btrfs subvolume delete /.snapshots
sudo mkdir /.snapshots
sudo mount -a
sudo chmod 750 /.snapshots

Отдельный подтом для снимков лучше вложенного: при ручном откате его не нужно переносить. Для домашнего каталога можно завести второй конфиг: sudo snapper -c home create-config /home. Пригодится, если случайно удалили документы, но снимки /home съедают место быстрее, особенно если там лежат виртуальные машины.

Расписание, лимиты и права пользователя

Правила хранения задаются переменными в /etc/snapper/configs/root. Менять их удобнее через set-config, чтобы не ошибиться в кавычках:

sudo snapper -c root set-config TIMELINE_CREATE=yes TIMELINE_LIMIT_HOURLY=5 TIMELINE_LIMIT_DAILY=7 TIMELINE_LIMIT_WEEKLY=2 TIMELINE_LIMIT_MONTHLY=0 TIMELINE_LIMIT_YEARLY=0 NUMBER_LIMIT=10
sudo snapper -c root get-config

Получится пять почасовых, семь ежедневных и два еженедельных снимка плюс до десяти пар "до и после" от пакетного менеджера. Для домашнего компьютера этого хватает с запасом. Таймеры systemd включаются отдельно:

sudo systemctl enable --now snapper-timeline.timer snapper-cleanup.timer

Чтобы смотреть снимки без sudo и пользоваться графическими оболочками вроде Btrfs Assistant, разрешите доступ своему пользователю:

sudo snapper -c root set-config ALLOW_USERS=anna SYNC_ACL=yes

Ещё одна мелочь, которая спасает от тормозов: индексатор plocate или mlocate по умолчанию может обходить /.snapshots и индексировать каждую копию системы. Добавьте .snapshots в строку PRUNENAMES файла /etc/updatedb.conf.

Автоматические снимки при установке пакетов

Самые полезные снимки - пары "до" и "после" каждой транзакции пакетного менеджера. Подключаются они по-разному.

Debian и Ubuntu

Пакет snapper сам кладёт хук /etc/apt/apt.conf.d/80snapper, так что каждая операция apt создаёт пару снимков без дополнительных действий. Проверьте после первого sudo apt upgrade, что в snapper list появились записи типа pre и post.

Arch Linux

Ставится пакет snap-pac, он добавляет хуки pacman. Подробнее о самом pacman в статье о командах pacman.

sudo pacman -S snap-pac

Fedora

Старый плагин python3-dnf-plugin-snapper работал только с DNF4. В DNF5 тот же результат дают действия: пакет libdnf5-plugin-actions и файл /etc/dnf/libdnf5-plugins/actions.d/snapper.actions. Готовый пример с вызовами snapper create -t pre и -t post приведён прямо в справке man libdnf5-actions, его можно скопировать в файл почти без изменений. Остальная настройка свежей системы описана в материале о Fedora 44 после установки.

sudo dnf install libdnf5-plugin-actions
man libdnf5-actions

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

sudo snapper -c root create -d "до правки grub"
sudo snapper -c root create --command "make install" -d "сборка из исходников"

Смотрим изменения и откатываем отдельные файлы

# список снимков с номерами
sudo snapper -c root list
# какие файлы изменились между снимками 41 и 42
sudo snapper -c root status 41..42
# построчная разница для одного файла
sudo snapper -c root diff 41..42 /etc/ssh/sshd_config
# вернуть файл к состоянию снимка 41
sudo snapper -c root undochange 41..42 /etc/ssh/sshd_config

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

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

sudo ls /.snapshots/41/snapshot/etc/
sudo cp -a /.snapshots/41/snapshot/etc/fstab /etc/fstab
# удалить ненужный диапазон снимков
sudo snapper -c root delete 30-38

Загрузка из снимка, если система не стартует

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

• GRUB. Пакет grub-btrfs добавляет подменю со снимками. В Arch он в официальном репозитории, служба grub-btrfsd обновляет меню при появлении новых снимков. В Fedora и Ubuntu пакет приходится брать из сторонних источников или собирать, проверяйте, кому доверяете.
• Limine. Для него есть limine-snapper-sync, популярный в CachyOS: он копирует ядро снимка в /boot и создаёт отдельный пункт меню.
• systemd-boot штатно снимки не показывает.

# Arch
sudo pacman -S grub-btrfs inotify-tools
sudo systemctl enable --now grub-btrfsd
sudo grub-mkconfig -o /boot/grub/grub.cfg

Снимки Snapper по умолчанию только для чтения, и часть служб при такой загрузке ругается. В Arch grub-btrfs предлагает хук grub-btrfs-overlayfs для mkinitcpio, он накладывает поверх снимка временный слой для записи. Загрузка из снимка - способ осмотреться и подготовить откат, а не постоянный режим. Если же меню GRUB пропало совсем, сначала восстановите загрузчик по инструкции о восстановлении GRUB.

Полный откат системы: rollback и ручной способ

Команда snapper rollback 42 создаёт рабочую копию снимка 42 и делает её подтомом по умолчанию. В openSUSE загрузчик настроен под это, и после перезагрузки вы в старой системе. В Fedora, Arch и Ubuntu в /etc/fstab и параметрах ядра обычно жёстко прописано subvol=@ или subvol=root, и тогда смена подтома по умолчанию ни на что не влияет. В таких системах надёжнее ручной способ.

Ручной откат через подмену подтома

Загрузитесь с Live USB или из снимка, смонтируйте верхний уровень файловой системы и подмените корневой подтом:

sudo mount -o subvolid=5 /dev/nvme0n1p2 /mnt
sudo mv /mnt/@ /mnt/@.broken
sudo btrfs subvolume snapshot /mnt/@.snapshots/42/snapshot /mnt/@
sudo umount /mnt
reboot

Имена @ и @.snapshots подставьте свои из вывода btrfs subvolume list /. В Fedora корень называется root, а снимки по умолчанию вложены в него. Тогда после переименования они окажутся в /mnt/root.broken/.snapshots: создайте снимок оттуда, удалите в новом корне пустой каталог .snapshots командой rmdir и перенесите подтом снимков на место через mv.

Когда новая система загрузилась и всё работает, старый корень можно удалить: sudo btrfs subvolume delete /mnt/@.broken (снова смонтировав верхний уровень).

Главная ловушка - ядро. Если /boot лежит на отдельном разделе ext4 или в ESP, как в Fedora, снимок вернёт старые модули ядра, а в /boot останется новое ядро. Система может не загрузиться или остаться без модулей. После отката проверьте, что ls /lib/modules содержит версию из uname -r, а при расхождении переустановите пакет ядра.

Снимки съели диск: проверка и чистка

Обычные утилиты вроде df на Btrfs врут, особенно при наличии снимков. Смотрите так:

sudo btrfs filesystem usage /
sudo snapper -c root list
# запустить очистку вручную, не дожидаясь таймера
sudo snapper -c root cleanup number
sudo snapper -c root cleanup timeline

Если места мало прямо сейчас, удалите самые старые пары, а потом уменьшите лимиты. Snapper умеет учитывать квоты (snapper setup-quota и переменная SPACE_LIMIT), но квоты Btrfs замедляют работу на больших дисках, на домашнем ПК обычно хватает лимитов по количеству. Другие способы найти, куда ушло место, собраны в статье об освобождении диска.

Частые вопросы

Документация и источники

• snapper(8) manual page, Debian Manpages, проект snapper, 2025
• Snapper, ArchWiki, 2026
• libdnf5-actions(8), DNF5, Fedora Project, 2026

Команды проверены на актуальных версиях дистрибутивов на момент обновления. Перед изменением системных настроек сделайте резервную копию.