BTRFS + snapshoty na Arch Linux / CachyOS

BTRFS daje ci coś, czego ext4 nie ma: cofnięcie zmian w systemie. Zainstalowałeś coś, co zepsuło Xorg? Wracasz do stanu sprzed 10 minut. Kernel panic po aktualizacji? Reboot do poprzedniego snapshota. Baza danych się posypała? Przywracasz plik sprzed awarii.

Ten poradnik to moja konfiguracja, którą używam od 3 lat na 4 maszynach (laptop roboczy, serwer domowy, stacja testowa, VPS).

Instalacja systemu na BTRFS (CachyOS / Arch)

Wybieram schemat partycji, który daje mi pełną kontrolę:

# Schemat partycji (UEFI + LUKS opcjonalnie)
# /dev/sda1 - 512MB - EFI partition (FAT32)
# /dev/sda2 - reszta - LUKS encrypted BTRFS

# Po instalacji CachyOS / Arch: stwórz subvolumes
mount /dev/sda2 /mnt
btrfs subvolume create /mnt/@
btrfs subvolume create /mnt/@home
btrfs subvolume create /mnt/@snapshots
btrfs subvolume create /mnt/@var_log
btrfs subvolume create /mnt/@var_cache

umount /mnt

Czemu 5 subvolumes, nie jeden? Snapshoty to kopia danych. Jeśli masz jeden subvolume @ z /var w środku, snapshot kopiuje też logi i cache. Wydajność spada, a rozmiar rośnie. Osobne subvolumes = snapshoty tylko tego, co chcesz.

Montowanie z kompresją zstd i noatime

Dodaj do /etc/fstab:

# /etc/fstab
UUID=xxxx-xxxx  /              btrfs   subvol=@,compress=zstd:3,noatime,ssd,discard=async  0  1
UUID=xxxx-xxxx  /home          btrfs   subvol=@home,compress=zstd:3,noatime,ssd,discard=async  0  2
UUID=xxxx-xxxx  /snapshots     btrfs   subvol=@snapshots,compress=zstd:3,noatime,ssd,discard=async  0  2
UUID=xxxx-xxxx  /var/log       btrfs   subvol=@var_log,compress=zstd:3,noatime,ssd,discard=async  0  2
UUID=xxxx-xxxx  /var/cache     btrfs   subvol=@var_cache,compress=zstd:3,noatime,ssd,discard=async  0  2
UUID=xxxx-xxxx  /boot/efi      vfat    umask=0077  0  2

Trzy opcje, które robią różnicę:

• compress=zstd:3 — transparentna kompresja. Zysk: 10-30% miejsca za darmo, CPU overhead pomijalny. Poziom 3 to sweet spot (poziom 1 szybszy ale mniej kompresuje, 9+ daje marne 2% więcej za 3x CPU).
• noatime — nie zapisuj czasu ostatniego dostępu do pliku. Zysk: mniej writeów, dłuższe życie SSD. Bez tej opcji jądro aktualizuje atime przy każdym read().
• discard=async — TRIM dla SSD w tle, nie blokuje operacji I/O. Alternatywa: cron z fstrim -A.

Timeshift: snapshoty desktopowe

Timeshift to GUI + CLI, który robi snapshoty całego systemu (poza /home) i przywraca jednym kliknięciem. Idealny na laptop/desktop.

Instalacja i konfiguracja

# CachyOS / Arch
sudo pacman -S timeshift

# Inicjalizacja (automatycznie wykryje BTRFS)
sudo timeshift --snapshot-device /dev/sda2

# Ustawienia:
# - typ: BTRFS (nie RSYNC — na BTRFS to marnuje miejsce)
# - lokalizacja: subvolume @snapshots
# - schedule: Daily (7 dni) + Weekly (4 tygodnie) + Monthly (3 miesiące)
# - exclude: nic (Timeshift+BTRFS kopiuje tylko zmiany)

Pierwszy snapshot i przywracanie

# Ręczny snapshot przed większą zmianą
sudo timeshift --create --comments "Przed aktualizacją kernela 6.10"

# Lista snapshotów
sudo timeshift --list

# Przywrócenie z poziomu systemu (reboot)
sudo timeshift --restore

# Przywrócenie z GRUB-a (gdy system się nie bootuje)
# Reboot → GRUB → "Arch Linux snapshots" → wybierz snapshot

Ten ostatni punkt jest kluczowy. GRUB ma integrację z BTRFS — przy starcie systemu pokazuje listę snapshotów, z których możesz zabootować. Kernel panic po pacman -Syu? Reboot, wybierz wczorajszy snapshot, napraw, wróć do bieżącego.

Snapper: snapshoty per-transakcja (przed/po pacman)

Snapper to niskopoziomowe narzędzie, które automatycznie tworzy snapshot przed i po każdej operacji pacman. Plus timeline (co godzinę, codziennie). Wymaga więcej konfiguracji niż Timeshift, ale daje precyzyjną kontrolę.

Konfiguracja dla / i /home

sudo pacman -S snapper snap-pac

# Utwórz config dla subvolume @
sudo snapper -c root create-config /

# Utwórz config dla subvolume @home
sudo snapper -c home create-config /home

# Edytuj timeline cleanup, żeby nie zaśmiecać
sudo nano /etc/snapper/configs/root
# Zmień:
#   TIMELINE_LIMIT_HOURLY="10"
#   TIMELINE_LIMIT_DAILY="7"
#   TIMELINE_LIMIT_WEEKLY="4"
#   TIMELINE_LIMIT_MONTHLY="3"
#   TIMELINE_LIMIT_YEARLY="0"

# Włącz timery systemd
sudo systemctl enable --now snapper-timeline.timer
sudo systemctl enable --now snapper-cleanup.timer

snap-pac integruje snappera z pacmanem. Od teraz każde pacman -S tworzy snapshot "pre" i "post" automatycznie. Jeśli aktualizacja zepsuje system:

# Lista snapshotów
sudo snapper list

# Różnice między dwoma snapshotami
sudo snapper status 42..43

# Przywrócenie pojedynczego pliku
sudo snapper undochange 42..43 --filename /etc/fstab

# Przywrócenie wszystkiego
sudo snapper undochange 42..43

Wyłączanie COW dla baz danych i VM

BTRFS używa Copy-on-Write — każda modyfikacja pliku tworzy nowy blok. Dla baz danych (PostgreSQL, MySQL, SQLite) to katastrofa wydajnościowa: zamiast jednego zapisu jest 10. Fix:

# Dla nowo tworzonych plików w katalogu
chattr +C /var/lib/postgresql/data
chattr +C /var/lib/mysql
chattr +C /var/lib/libvirt/images

# Dla istniejących plików: musisz zrobić defragmentację
btrfs filesystem defragment -czstd /var/lib/postgresql/data

Po chattr +C nowe pliki nie używają COW. Wydajność baz wraca do poziomu ext4. Snapshots wciąż działają (kopiują cały subvolume, nie pojedyncze bloki COW).

Backup off-site: btrfs send/receive

BTRFS ma wbudowany mechanizm incrementalnych backupów — btrfs send i btrfs receive. Wysyłasz tylko delta, nie cały snapshot.

# Na serwerze backupowym: utwórz subvolume do odbierania
btrfs subvolume create /backup/laptop/@

# Na laptopie: wyślij pierwszy snapshot
sudo btrfs send /.snapshots/1/snapshot | ssh backup@server "btrfs receive /backup/laptop/@"

# Kolejne snapshoty: tylko delta
sudo btrfs send -p /.snapshots/1/snapshot /.snapshots/5/snapshot | \
  ssh backup@server "btrfs receive /backup/laptop/@"

To jest 10-100x szybsze niż rsync na dużych snapshotach, bo wysyła tylko zmienione bloki. Backup 200GB snapshotu z 2GB zmian = 2GB transferu, nie 200GB.

Monitoring: ile miejsca zajmują snapshoty

# Ile zajmują snapshoty
sudo btrfs filesystem du -s /.snapshots/*/snapshot

# Ogólne użycie dysku
btrfs filesystem usage /

# Ile miejsca można zwolnić usuwając snapshoty
sudo snapper list --columns number,description,used-space

Zasada: 20-30% wolnego miejsca minimum. BTRFS potrzebuje wolnych bloków do alokacji COW. Gdy zapełnisz dysk w 95%+, system zaczyna zwalniać w nieoczywisty sposób (alokacja się nie udaje, snapshoty nie działają, performance spada).

Co dalej

• WordPress REST API: praktyczne przypadki użycia
• Cloudflare dla WordPressa
• Własny serwer mailowy Postfix + Dovecot

Jeśli chcesz, żebym skonfigurował ci BTRFS ze snapshotami na istniejącym serwerze (bez reinstalacji) — napisz do mnie.