Snapshoty BTRFS: konfiguracja, snapper i rollback po aktualizacji

Każdy, kto używa Archa, CachyOS albo openSUSE dłużej niż miesiąc, prędzej czy później staje przed pytaniem: co zrobić, gdy aktualizacja coś zepsuje? BTRFS daje odpowiedź, której ext4 nie ma: snapshoty. W tym artykule pokażę, jak je tworzyć ręcznie, jak skonfigurować snappera do automatycznych migawek i jak wrócić do działającego systemu w minutę.

Subvolumes – fundament snapshotów

Snapshot w BTRFS to kopia metadanych subvolume oparta na copy-on-write. Powstaje natychmiast, nie duplikuje danych, a przechowuje jedynie bloki zmienione po jego utworzeniu. Dlatego pierwszy snapshot jest niemal darmowy, a dziesiąty zajmuje tyle, ile się faktycznie zmieniło.

Podstawowe operacje na subvolumes:

# Lista subvolumes
sudo btrfs subvolume list /

# Utworzenie nowego subvolume
sudo btrfs subvolume create /mnt/dane

# Ręczny snapshot subvolume @
sudo btrfs subvolume snapshot -r / /mnt/@snapshots/@-$(date +%Y%m%d-%H%M%S)

# Usunięcie snapshota (uważaj — bezpowrotne!)
sudo btrfs subvolume delete /mnt/@snapshots/@-20260710-120000

Flaga -r tworzy snapshot tylko do odczytu – to ważne, bo taki snapshot jest odporny na przypadkową modyfikację i może być bazą do btrfs send (backupu na inny dysk). Snapshoty robocze bez -r bywają przydatne do testów, ale łatwo w nich narobić bałaganu.

Konfiguracja snappera

Snapper automatyzuje całość: robi snapshoty przed i po pacman -Sy, utrzymuje oś czasu (co godzinę, co dzień), czyści stare migawki według zasad. Instalacja i pierwsza konfiguracja:

# Instalacja
sudo pacman -S snapper snap-pac

# Konfiguracja dla katalogu głównego — utworzy /etc/snapper/configs/root
sudo snapper -c root create-config /

# Sprawdzenie konfiguracji
sudo snapper list

Na Arch/CachyOS pakiet snap-pac dodaje hooki, dzięki którym snapper robi snapshot przed każdą aktualizacją pacmana i po niej. To dokładnie ta migawka, do której wrócisz, gdy aktualizacja zepsuje system. Na openSUSE snapper jest domyślnie skonfigurowany – wystarczy sudo snapper list, żeby zobaczyć istniejące snapshoty.

Zasady czyszczenia możesz dostroić w /etc/snapper/configs/root:

TIMELINE_CREATE="yes"
TIMELINE_LIMIT_HOURLY="10"
TIMELINE_LIMIT_DAILY="7"
TIMELINE_LIMIT_WEEKLY="4"
TIMELINE_LIMIT_MONTHLY="2"
TIMELINE_LIMIT_YEARLY="0"

Czyli: 10 snapshotów godzinowych, 7 dziennych, 4 tygodniowe, 2 miesięczne. Snapper sam usunie starsze – nie musisz pamiętać o sprzątaniu.

Rollback po zepsutej aktualizacji

Scenariusz: zrobiłeś sudo pacman -Syu, zrestartowałeś system i dostajesz czarny ekran, kernel panic albo w ogóle brak boota. Spokojnie – oto procedura.

Opcja A: Snapper + bootloader. Jeśli używasz GRUB-a z pluginem snappera (na CachyOS i openSUSE domyślnie), wystarczy:

1. Zrestartuj system.
2. W menu GRUB wybierz “Snapper snapshots”.
3. Wybierz snapshot sprzed aktualizacji – zazwyczaj ten z poprzedniego dnia albo oznaczony jako “pre” aktualizacji.
4. System wstanie z migawki, a Ty masz czas, żeby zbadać problem.

Opcja B: Snapper z poziomu działającego systemu. Gdy system bootuje, ale jest niestabilny:

# Zobacz snapshoty i znajdź ten sprzed aktualizacji
sudo snapper list

# Rollback — utworzy nowy podvolume @ i skopiuje do niego zawartość snapshota
sudo snapper rollback

Po snapper rollback zaktualizuj bootloader (sudo grub-mkconfig -o /boot/grub/grub.cfg na Archu, na CachyOS wystarczy narzędzie cachyos-bootloader) i zrestartuj.

Opcja C: Ręczne przywrócenie z działającego systemu. Gdy bootuje, ale chcesz wrócić do konkretnego snapshota bez grzebania w GRUB-ie:

# Najpierw zidentyfikuj snapshot
sudo snapper list

# Zamontuj katalog @ do /mnt (jeśli jeszcze nie jest zamontowany)
sudo mount /dev/nvme0n1p2 /mnt -o subvol=@

# Wyczyść obecną zawartość @ (zachowaj ukryte pliki konfiguracyjne? — nie, przywracamy całość)
sudo find /mnt -mindepth 1 -maxdepth 1 -exec rm -rf {} +

# Przywróć snapshot do @ — reflink kopiuje dane bez duplikacji COW
sudo cp -a --reflink=auto /mnt/@snapshots/@-YYYYMMDD-HHMMSS/. /mnt/

sudo reboot

Uwaga: rm -rf na zawartości @ to operacja destrukcyjna – wykonuj ją tylko, gdy masz pewność, że snapshot jest dobry. Bezpieczniejszym wariantem jest podmiana subvolume, ale wymaga montowania z subvolid i jest opisana w dedykowanym artykule o BTRFS na Arch/CachyOS.

Snapshoty danych, nie tylko systemu

Snappera warto skonfigurować też dla katalogu domowego i danych, ale z głową. Snapshoty /home co godzinę to strata miejsca przy dużych plikach – wystarczą dzienne. Dla bazy danych i maszyn wirtualnych rozważ wyłączenie COW:

# Wyłącz COW na plikach baz danych / obrazach VM
sudo chattr +C /var/lib/postgresql/16/main/pgdata
sudo chattr +C /var/lib/libvirt/images

Uwaga: chattr +C działa tylko na pustych plikach i nowych plikach w katalogu – musisz to zrobić przed zapisem danych albo skopiować dane po ustawieniu flagi.

Odzyskiwanie pojedynczych plików i przeglądanie różnic

Rollback całego systemu to rzadka operacja. Na co dzień znacznie częściej potrzebujesz jednego pliku: nadpisałeś dokument, usunąłeś zdjęcie, a edytor zapisał wersję bez Twoich zmian. Snapper pozwala podejrzeć, co się zmieniło między snapshotami, i skopiować pojedynczy plik:

# Jakie zmiany zaszły od ostatniego snapshota?
sudo snapper status

# Zobacz różnice treści w konkretnym pliku
sudo snapper diff

# Skopiuj plik z wybranego snapshota z powrotem
sudo cp /mnt/@snapshots/42/snapshot/home/user/dokument.odt ~/dokument.odt

Snapshoty są montowane w katalogu .snapshots (na Arch/CachyOS z reguły /mnt/@snapshots/<numer>/snapshot/), więc pojedyncze pliki można po prostu skopiować jak z każdego innego katalogu. To najczęściej używana funkcja snappera u mnie – nie raz uratowała nadpisany plik konfiguracyjny czy przypadkiem skasowany folder.

Co daje praktycznie

Z snapshotami codzienne życie wygląda tak: aktualizujesz bez stresu, bo wiesz, że przywrócenie to snapper rollback i reboot. Eksperymentujesz z konfiguracją – wracasz do stanu sprzed godziny. Przed dużą zmianą (nowy kernel, zmiana sterownika) robisz ręczny snapshot i idziesz spać spokojnie.

To samo podejście sprawdza się na serwerze domowym – tam snapshoty przed aktualizacją to już nie wygoda, ale standard bezpieczeństwa, zwłaszcza gdy na serwerze czekają dane Nextclouda i konta innych domowników.