# Snapper Lab: Systemrettung leicht gemacht

TL;DR / Management Summary Ein missglücktes Update oder eine versehentlich gelöschte Konfigurationsdatei? Dank Snapper ist das unter SUSE kein Grund zur Panik. In diesem Modul lernen wir den praktischen Umgang mit Snapshots: Wie wir Unterschiede (Diffs) zwischen Systemzuständen finden, wie wir den Server über das GRUB-Menü auf einen alten Stand zurücksetzen und wie wir einzelne Dateien extrahieren, ohne das gesamte System zu beeinträchtigen.

# 1. Einführung: Der Point-in-Time Schutz

Wann hilft Snapper?

Snapper erstellt Snapshots automatisch:

• Pre/Post: Vor und nach jeder zypper Aktion.
• Timeline: Stündlich (rotierend).
• Manual: Wenn der Admin es befiehlt.

# 2. Analyse: Was hat sich geändert?

Die Nadel im Heuhaufen.

Bevor Sie ein Rollback machen, sollten Sie wissen, welche Dateien betroffen sind.

# Diffs anzeigen

# Zeige Unterschiede zwischen Snapshot 10 und 11
sudo snapper diff 10..11

# Nur eine bestimmte Datei vergleichen
sudo snapper diff 10..11 /etc/passwd

# Dateiliste der Änderungen

# Listet alle geänderten Files zwischen zwei Zuständen
sudo snapper status 10..11

Legende: + (Neu), - (Gelöscht), c (Geändert).

# 3. Einzelne Dateien wiederherstellen

Chirurgische Präzision.

Sie müssen nicht das ganze OS zurückrollen, wenn nur die nginx.conf kaputt ist.

# Stellt den Zustand der Datei aus Snapshot 10 wieder her
sudo snapper undochange 10 /etc/nginx/nginx.conf

# 4. Full System Rollback: Der Rettungsanker

Wenn der Server nicht mehr bootet.

Dies ist das mächtigste Feature von SUSE.

# Schritt-für-Schritt (Boot-Rollback)

1. Reboot des Servers.
2. Im GRUB-Menü wählen Sie: “Start bootloader from a read-only snapshot”.
3. Wählen Sie einen Snapshot aus der Liste (nach Datum/Aktion).
4. Das System bootet nun in diesen Stand (Read-Only). Prüfen Sie, ob alles geht.
5. Führen Sie das permanente Rollback aus:

   sudo snapper rollback

6. Reboot. Das System nutzt nun den gewählten Stand wieder als primäres Schreib-System.

# 5. Troubleshooting & “War Stories”

Wenn der Snapshot-Speicher hakt.

# Story 1: “Der hängende Rollback”

Symptom: Nach snapper rollback bootet das System immer noch in den kaputten Stand. Ursache: Der Admin hat vergessen, nach dem rollback Befehl neu zu starten. Snapper ändert beim Rollback nur den Standard-Subvolume-Pointer in der Btrfs-Struktur. Lösung: Immer sofort nach dem Rollback rebooten.

# Story 2: “Snapper und separate Mountpoints”

Symptom: Der Admin macht ein Rollback, aber die Daten in /home oder /var/lib/mysql bleiben auf dem neuen (kaputten) Stand. Ursache: Snapper sichert standardmäßig nur das Root-Subvolume. Wenn /home ein eigenes Subvolume oder eine eigene Partition ist, braucht es eine eigene Snapper-Config. Lösung: Erstellen Sie eine zusätzliche Config für Datenverzeichnisse: sudo snapper -c home create-config /home.

# 6. Fazit & Empfehlung

• Automation: Lassen Sie die automatischen Zypper-Snapshots immer an. Sie sind Ihre Versicherung.
• Wartung: Prüfen Sie monatlich mit snapper list, ob die Anzahl der Snapshots im Rahmen bleibt (Standard: ~10-20 Stück).
• Backup: Snapper ist kein Backup! Wenn die physische Disk stirbt, sind auch die Snapshots weg. Nutzen Sie zusätzlich btrfs send/receive auf einen anderen Server.

# Anhang: Cheatsheet