Backup-Strategie für Rootserver, die im Ernstfall trägt

Die Checkliste für die ersten 30 Minuten endet mit einem tar-Archiv von /etc und der Feststellung, dass das noch keine Sicherung ist, sondern eine Kopie auf derselben Platte. Dort setzt dieser Beitrag an: wie daraus eine Strategie wird, die einen Totalverlust übersteht.

Der Satz, um den alles kreist: Eine Sicherung, aus der noch nie etwas zurückgeholt wurde, ist keine Sicherung, sondern eine Hoffnung. Alles Weitere dient dem Zweck, daraus eine geprüfte Aussage zu machen.

Alle Befehle laufen als root. Als normaler Benutzer stellen Sie jedem Befehl sudo voran. Bezugssysteme sind Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS und Ubuntu 22.04 LTS. Wo sich die vier unterscheiden, steht es dabei.

Bevor Sie etwas ändern: der Rückweg

An der Sicherung selbst geht selten etwas kaputt. Gefährlich sind die Handgriffe drumherum: eine Rücksicherung, die über das laufende System schreibt, ein Repository, das die Systemplatte füllt, Schlüsseldateien, die den eigenen Zugang ersetzen. Vier Punkte vorab.

1. Den Konsolenzugang kennen, bevor Sie ihn brauchen

Bei KVM-Rootservern und Dedicated Servern von KernelHost erreichen Sie die VNC-Konsole im Kundenbereich. Sie hängt nicht am Netzwerkstack des Gastsystems und antwortet auch dann noch, wenn SSH schweigt. Das ist der Rettungsweg, wenn eine Rücksicherung eine alte sshd_config oder authorized_keys über die aktuelle geschrieben hat. Melden Sie sich einmal vorher darüber an und prüfen Sie, ob Sie das root-Passwort kennen.

2. Nie als ersten Versuch nach / zurücksichern

Die erste Rücksicherung geht immer in ein leeres Verzeichnis, etwa /var/tmp/restore-test. Von dort vergleichen Sie und kopieren gezielt zurück. Ein Rückspielen direkt nach / überschreibt auch die Dateien, die seit der Sicherung mit gutem Grund geändert wurden.

3. Eine zweite Sitzung offen halten

Solange Sie an SSH-Schlüsseln oder an der authorized_keys des Ziels arbeiten, gilt dieselbe Regel wie beim Aufbau einer Firewall: ein zweites Terminal mit stehender Verbindung offen lassen und erst schließen, wenn eine frische Verbindung klappt.

4. Platz prüfen, bevor das Repository wächst

df -h /
df -i /

Die zweite Zeile vergessen die meisten: Ein Dateisystem läuft auch dann voll, wenn noch Gigabyte frei sind, nämlich wenn die Inodes ausgehen. Ein lokales Repository, das die Systemplatte füllt, ist eine der häufigsten selbstverursachten Störungen. Deshalb liegt das Ziel hier von Anfang an außerhalb des Servers.

Die 3-2-1-Regel, auf einen einzelnen Server angewendet

• Drei Kopien. Die Produktivdaten sind die erste Kopie. Es braucht also zwei Sicherungen, nicht eine.
• Zwei verschiedene Ablagen. Zwei Verzeichnisse auf derselben Platte sind eine Ablage, zwei Platten im selben RAID ebenfalls: Ein versehentliches rm trifft beide. RAID schützt gegen den Ausfall eines Datenträgers und gegen sonst nichts.
• Eine Kopie außer Haus. Nicht derselbe Server, nicht dasselbe Verwaltungskonto, idealerweise nicht derselbe Standort.

Zwei Ergänzungen sind nötig. Erstens sollte eine Kopie so liegen, dass der Server selbst sie nicht löschen kann, denn wer Ihren Server übernimmt, findet dort die Zugangsdaten zum Ziel. Zweitens zählt eine Kopie erst, wenn sie geprüft wurde. Ein Abbild im selben Kundenbereich ist bequem, als Kopie außer Haus zählt es nicht.

Legen Sie außerdem zwei Zahlen fest: Wie viele Stunden Datenverlust können Sie hinnehmen (das bestimmt den Abstand zwischen zwei Läufen), und wie lange darf die Wiederherstellung dauern (das entscheidet über ein zusätzliches Abbild).

Was gesichert gehört, und was nicht

Der häufigste Fehler ist nicht, zu wenig zu sichern, sondern alles. Wer / ohne Ausschlüsse wegschreibt, nimmt Paket-Caches, temporäre Dateien und Swap mit.

apt-mark showmanual > /root/paketliste.txt
dpkg --get-selections > /root/paketauswahl.txt
wc -l /root/paketliste.txt /root/paketauswahl.txt

apt-mark showmanual listet nur die ausdrücklich installierten Pakete ohne die mitgezogenen Abhängigkeiten: die kurze Liste, die Sie beim Neuaufbau brauchen.

Datei, Datenbank, Abbild: drei Verfahren, die einander nicht ersetzen

Daraus folgt eine Reihenfolge, keine Auswahl. Erst schreibt der Datenbankserver einen Dump, dann läuft die Dateisicherung, und das Datenverzeichnis bleibt ausgeschlossen. Eine Dateikopie von /var/lib/mysql im laufenden Betrieb erfasst verschiedene Tabellen zu verschiedenen Zeitpunkten. Ob sie sich zurückspielen lässt, erfahren Sie im ungünstigsten Moment.

Zugangsdatei, Rechte und Stolpersteine des Dumps behandelt MySQL- und MariaDB-Datenbanken automatisch sichern. Wichtig ist der Übergabepunkt: Die Dumps landen in /var/backups/db, bleiben dort ein bis zwei Tage, die Aufbewahrung übernimmt das Repository. PostgreSQL sichern Sie mit pg_dumpall als Benutzer postgres.

restic oder Borg

Beide zerlegen Dateien in Blöcke, speichern gleiche Blöcke nur einmal, verschlüsseln und legen versionierte Stände ab. Beide sind auf allen vier Distributionen paketiert. Der Unterschied, der die Entscheidung trägt, steht in der letzten Zeile.

Auf einem Speicher, auf dem Sie nichts installieren können, fällt Borg aus. Bei einem zweiten Linux-Server unter Ihrer Verwaltung spricht der Append-Only-Modus für Borg.

Einrichten mit restic

apt update
apt install -y restic
restic version

Prüfen Sie die Ausgabe, bevor Sie ein Repository anlegen: Die vier Distributionen liefern sehr unterschiedliche Stände aus, und ein Repository einer neueren Version lässt sich von einer älteren nicht zwingend öffnen.

Zugang zum Ziel

Das Ziel ist hier ein zweiter Server per SSH. Der Schlüssel gehört root, denn nur root darf alle zu sichernden Dateien lesen:

ssh-keygen -t ed25519 -N '' -f /root/.ssh/id_ed25519_backup -C 'sicherung srv01'
ssh-copy-id -i /root/.ssh/id_ed25519_backup.pub sicherung@203.0.113.50

cat > /root/.ssh/config <<'EOF'
Host backupziel
    HostName 203.0.113.50
    User sicherung
    IdentityFile /root/.ssh/id_ed25519_backup
    BatchMode yes
EOF
chmod 600 /root/.ssh/config

Erfolgskontrolle: ssh backupziel true läuft ohne Ausgabe und ohne Rückfrage durch. Die allererste Verbindung fragt nach dem Hostschlüssel: Beantworten Sie das jetzt und nicht später in einem Dienst, der auf niemanden warten kann.

Passwort und Repository

install -d -m 700 /etc/restic
head -c 32 /dev/urandom | base64 | tr -d '\n' > /etc/restic/repo.pass
chmod 600 /etc/restic/repo.pass

cat > /etc/restic/env <<'EOF'
RESTIC_REPOSITORY=sftp:backupziel:/srv/sicherung/srv01
RESTIC_PASSWORD_FILE=/etc/restic/repo.pass
EOF
chmod 600 /etc/restic/env

Diese Datei taugt für die Shell und für systemd gleichermaßen. In der Shell:

set -a; . /etc/restic/env; set +a
restic init

Erfolgskontrolle: restic cat config gibt eine kurze JSON-Struktur mit der Kennung des Repositories aus. Kommt die Rückfrage Is there a repository at the following location?, stimmt der Pfad nicht oder restic init ist nie gelaufen.

Der erste Lauf

cat > /etc/restic/excludes.txt <<'EOF'
/proc
/sys
/dev
/run
/tmp
/var/tmp
/var/cache
/var/lib/apt/lists
/var/lib/mysql
/swapfile
EOF

restic backup / --one-file-system --exclude-file=/etc/restic/excludes.txt --exclude-caches --tag system

--one-file-system hält die Sicherung auf dem Wurzeldateisystem und nimmt eingehängte Netzlaufwerke nicht mit. --exclude-caches überspringt Verzeichnisse, die sich selbst als Zwischenspeicher markiert haben. Der Ausschluss von /var/lib/mysql ist die Umsetzung des vorigen Abschnitts.

Erfolgskontrolle: Der Lauf endet mit einer Zeile wie snapshot 0a1b2c3d saved. Danach:

restic snapshots
restic stats latest

In der Liste stehen Zeitpunkt, Rechnername und Pfade. Zeigt restic stats latest eine unerwartet kleine Größe, greift ein Ausschluss zu weit.

Dasselbe mit Borg

apt install -y borgbackup
borg --version
export BORG_REPO='ssh://sicherung@203.0.113.50/./srv01'
borg init --encryption=repokey-blake2

borg create --stats --compression zstd ::'system-{now}' /etc /var/www /home /var/backups
borg list
borg info

Alle vier Distributionen liefern eine Version aus der 1.x-Reihe aus. Borg muss auf beiden Seiten vorhanden sein, und die Version am Ziel sollte nicht älter sein als die auf dem Server. Betreiben Sie pro Server ein eigenes Repository: Das erspart Ihnen, das Aufräumen auf die Archive genau dieses Servers zu begrenzen, und erlaubt getrennte Zugangsschlüssel.

Erfolgskontrolle: borg list zeigt das Archiv mit Zeitstempel, borg info die Größe vor und nach der Deduplizierung.

Aufbewahrung: länger, als die meisten ansetzen

Die Aufbewahrungsdauer richtet sich nicht danach, wie lange Sie Daten aufheben möchten, sondern danach, wie lange es dauert, bis ein Schaden auffällt. Ein gelöschtes Verzeichnis merkt man am selben Tag, eine defekte Tabelle oft erst Wochen später. Wer sieben Tage aufhebt, hat dann sieben Tage lang den Schaden mitgesichert.

restic forget --dry-run --keep-daily 7 --keep-weekly 4 --keep-monthly 6
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Der Probelauf zeigt, welche Stände verschwinden würden. Ohne --prune gehen nur die Verweise, der Platz bleibt belegt. Bei Borg ist das seit 1.2 zweistufig, und der vergessene zweite Befehl erklärt die meisten Repositories, die nicht schrumpfen wollen:

borg prune --list --dry-run --keep-daily=7 --keep-weekly=4 --keep-monthly=6
borg prune --list --keep-daily=7 --keep-weekly=4 --keep-monthly=6
borg compact

Erfolgskontrolle: restic snapshots beziehungsweise borg list zeigt die erwartete Staffelung, und die belegte Größe am Ziel sinkt.

Verschlüsselung und der Schlüssel, den hinterher niemand mehr hat

Beide Werkzeuge verschlüsseln, bevor die Daten den Server verlassen. Das Ziel sieht nur unlesbare Blöcke, was einen fremden Speicher erst vertretbar macht. Der Preis ist eindeutig: Ohne Passwort beziehungsweise Schlüssel sind die Daten endgültig verloren. Es gibt keine Hintertür.

Daraus folgen zwei Regeln. Erstens gehört das Passwort an einen zweiten Ort, üblicherweise in einen Passwortspeicher. Ein Passwort, das nur in /etc/restic/repo.pass liegt, ist beim Verlust des Servers mit weg, und mit ihm die Sicherung. Zweitens exportieren Sie bei Borg mit repokey den Schlüssel und legen ihn außerhalb ab, denn dort liegt er im Repository selbst:

borg key export ::

Erfolgskontrolle: Führen Sie mit dem Passwort aus dem Passwortspeicher auf einem anderen Rechner restic snapshots aus. Ein Passwort, das Sie noch nie von anderswo benutzt haben, ist unbestätigt.

Das Ziel gegen Löschen absichern

Ein Angreifer mit root-Rechten hat auch Zugriff auf das hinterlegte Passwort und auf den Schlüssel für das Ziel. Er kann die Sicherung also löschen, bevor er die Produktivdaten verschlüsselt. Deshalb braucht es eine Ablage, die neue Stände annimmt, aber kein Löschen erlaubt. Bei Borg richten Sie das in der authorized_keys des Sicherungsbenutzers am Ziel ein:

command="borg serve --append-only --restrict-to-path /srv/sicherung/srv01",restrict ssh-ed25519 AAAA... sicherung srv01

Der Schlüssel nimmt danach nur noch Sicherungen entgegen, und zwar nur in diesem Pfad. Rechnen Sie damit, dass ein prune hier zwar durchläuft, aber keinen Platz freigibt, weil das Löschen am Ziel nicht ausgeführt wird. Das Aufräumen erledigen Sie dort, wo der Server keinen Zugriff hat. Bei restic übernehmen der REST-Server im Append-Only-Betrieb oder ein Objektspeicher mit Versionierung diese Rolle. Ein reiner SFTP-Zugang leistet das nicht.

Automatisieren mit einem systemd-Timer

Ein Timer ist einem Cronjob vorzuziehen, weil er die Ausgabe ins Journal schreibt, versäumte Läufe nachholt und den Startzeitpunkt streuen darf. Zum Aufbau von Units: Einen eigenen systemd-Service erstellen.

cat > /etc/systemd/system/sicherung.service <<'EOF'
[Unit]
Description=Tägliche Sicherung mit restic
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
Nice=10
IOSchedulingClass=idle
ExecStart=/usr/bin/restic backup / --one-file-system --exclude-file=/etc/restic/excludes.txt --exclude-caches --tag system
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
EOF

cat > /etc/systemd/system/sicherung.timer <<'EOF'
[Unit]
Description=Startet die tägliche Sicherung

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=1800
Persistent=true

[Install]
WantedBy=timers.target
EOF

systemctl daemon-reload
systemctl enable --now sicherung.timer
systemd-analyze calendar '*-*-* 02:30:00'

Mehrere ExecStart-Zeilen in einer oneshot-Unit laufen nacheinander, und ein Fehlschlag bricht die Kette ab. Das Aufräumen läuft also nur nach einer geglückten Sicherung. Ist das Ziel ein eingehängtes Dateisystem, gehört eine Absicherung davor, sonst schreibt der Lauf unbemerkt in den leeren Einhängepunkt:

ExecStartPre=/usr/bin/mountpoint -q /mnt/sicherung

Erfolgskontrolle:

systemctl start sicherung.service
systemctl list-timers sicherung.timer
journalctl -u sicherung.service -n 50 --no-pager

systemctl list-timers muss eine nächste Startzeit ausweisen. Steht dort nichts, ist der Timer nicht aktiviert. Der wichtigste Punkt kommt zum Schluss: Ein Lauf, der leise aufhört zu laufen, ist der Normalfall des Scheiterns. Prüfen Sie systemctl is-failed sicherung.service, oder hängen Sie als letzte ExecStart-Zeile einen Aufruf an einen externen Überwachungsdienst an, der Alarm schlägt, wenn das tägliche Lebenszeichen ausbleibt.

Die Wiederherstellung testen

Der kleine Test, monatlich, fünf Minuten

mkdir -p /var/tmp/restore-test
restic restore latest --target /var/tmp/restore-test --include /etc/ssh/sshd_config
diff /etc/ssh/sshd_config /var/tmp/restore-test/etc/ssh/sshd_config && echo "identisch"

Mit Borg entsprechend, das Pfade ohne führenden Schrägstrich speichert:

cd /var/tmp/restore-test
borg extract --list ::system-2026-09-03T02:30:00 etc/ssh/sshd_config

Prüfen Sie zusätzlich die Unversehrtheit des Repositories. Die jeweils zweite Zeile liest die Daten zurück und rechnet die Prüfsummen nach, bei restic nur für einen Teil, damit der Lauf nicht Stunden dauert:

restic check
restic check --read-data-subset=1/7

borg check
borg check --verify-data

Erfolgskontrolle: restic check endet mit no errors were found, borg check ohne Fehlermeldung. Ein Repository, das nur einmal im Jahr geprüft wird, kann elf Monate lang defekt gewesen sein.

Der große Test, einmal im Jahr

Der kleine Test beweist, dass Dateien lesbar sind. Er beweist nicht, dass Sie den Dienst wieder ans Laufen bekommen. Dafür braucht es den vollständigen Durchlauf auf einem zweiten, leeren Server: Grundsystem installieren, Paketliste einspielen, Repository anbinden, Daten zurückholen, Dump einlesen, Dienste starten. Stoppen Sie die Zeit. Diese Zahl ist Ihre tatsächliche Wiederherstellungsdauer, erfahrungsgemäß ein Vielfaches der geschätzten.

Notieren Sie, was gefehlt hat. Es sind fast immer dieselben Dinge: eine Datei außerhalb der gesicherten Pfade, ein Dienst mit Konfiguration unter /opt, ein Zertifikat ohne Kontoschlüssel, eine Datenbank ohne Benutzer und Rechte. Diese Liste ist der Ertrag des Tests.

Häufige Fehler und Lösungen

Host key verification failed. Der Dienst läuft als root, und root hat den Hostschlüssel des Ziels nie bestätigt. Einmal von Hand ssh backupziel true ausführen oder ssh-keyscan -H 203.0.113.50 >> /root/.ssh/known_hosts. Auf der Konsole klappt es, im Timer nicht: fast immer dieser Fehler.

Permission denied (publickey). Falscher Benutzer, falscher Schlüssel oder falsche Rechte am Ziel: .ssh braucht 700, authorized_keys 600, beide gehören dem Zielbenutzer.

Is there a repository at the following location? restic findet keine Repository-Struktur: falscher Pfad, restic init nie gelaufen, oder das Ziel gerade nicht erreichbar.

Fatal: wrong password or no key found Die Passwortdatei passt nicht zum Repository, meist weil sie nachträglich neu erzeugt wurde. Prüfen Sie mit cat -A /etc/restic/repo.pass, ob sich ein Leerzeichen eingeschlichen hat.

repository is already locked exclusively by Ein abgebrochener Lauf hat seine Sperre hinterlassen. Erst prüfen, dass nichts mehr läuft, dann restic unlock. Bei Borg lautet die Meldung Failed to create/acquire the lock mit dem Zusatz (timeout), der Befehl borg break-lock. Beide sind riskant, solange doch ein Lauf aktiv ist.

Warning: The repository at location ... was previously located at ... Die Adresse des Repositories hat sich geändert, und Borg fragt interaktiv nach. In einer Unit wartet der Befehl damit auf eine Antwort, die nie kommt. Nachdem Sie geprüft haben, dass es dasselbe Repository ist, setzen Sie BORG_RELOCATED_REPO_ACCESS_IS_OK=yes in die Umgebungsdatei.

No space left on device am Ziel. Entweder läuft das Aufräumen gar nicht, oder ohne --prune beziehungsweise ohne borg compact. Hat umgekehrt ein Dump das Wurzeldateisystem gefüllt, hilft Festplatte voll unter Linux aufräumen weiter.

Der Lauf meldet Erfolg, sichert aber fast nichts. Ein Ausschluss greift zu weit, oder ein Pfad ist falsch geschrieben. Vergleichen Sie restic stats latest mit dem Wert des Vortags. Eine plötzlich um Größenordnungen kleinere Sicherung ist ein Alarm und kein Erfolg.

Unterschiede zwischen den Distributionen

• Paketnamen sind auf allen vier Systemen gleich: restic und borgbackup. Die ausgelieferten Versionen sind es nicht.
• Protokollierung: Debian 13 und viele Debian-12-Installationen bringen kein rsyslog mit. Die Ausgabe des Laufs finden Sie dort ausschließlich im Journal, also über journalctl -u sicherung.service. Unter Ubuntu 22.04 und 24.04 gibt es zusätzlich die Ablage unter /var/log.
• Einhängen von Sicherungsständen: restic mount und borg mount brauchen fuse3. Fehlt das Paket, bricht der Befehl mit einem Hinweis auf ein fehlendes fusermount3 ab. Der Weg ohne FUSE ist restic restore beziehungsweise borg extract.
• Datenbankwerkzeug: Debian liefert ausschließlich MariaDB, dort heißt es mariadb-dump mit mysqldump als Verweis darauf. Unter Ubuntu kann auch MySQL 8 laufen, dort gibt es nur mysqldump.

Die Abschlusskontrolle

Die Strategie ist fertig, wenn Sie diese sieben Punkte mit einem Befehl belegen können und nicht mit einer Vermutung:

1. restic snapshots oder borg list zeigt einen Stand von heute Nacht.
2. systemctl list-timers sicherung.timer weist eine nächste Startzeit aus.
3. restic check oder borg check meldet keinen Fehler.
4. Eine einzelne Datei ließ sich in diesem Monat zurückholen und war anschließend identisch.
5. Die Staffelung entspricht der geplanten Aufbewahrung, das Repository wächst nicht unbegrenzt.
6. Das Passwort liegt an einem zweiten Ort, und Sie haben es von dort schon einmal benutzt.
7. Mindestens eine Ablage nimmt Sicherungen an, ohne dass der Server sie löschen kann.

Fehlt Punkt vier, haben Sie eine Vermutung. Fehlt Punkt sechs, verschlüsselten Datenmüll. Fehlt Punkt sieben, eine Sicherung, die genau den Angriff nicht übersteht, gegen den sie am dringendsten gebraucht wird.