Restic Backup auf VPS einrichten Anleitung

Warum ein Backup auf demselben Server kein Backup ist

Restic ist ein kostenloses Open-Source-Backup-Tool. Es überträgt verschlüsselte, deduplizierte Snapshots Ihrer Dateien in ein Repository an einem anderen Ort: ein zweiter VPS, ein Heimrechner oder S3-kompatibler Objektspeicher. Diese Anleitung führt Sie durch die Einrichtung auf Ubuntu 24.04. Sie umfasst die Installation, ein Repository über SFTP, ein erstes Backup, einen nächtlichen systemd-Timer, eine Aufbewahrungsrichtlinie und die Wiederherstellung zur Überprüfung der Funktion. Das Ziel muss eine andere Maschine sein, da eine Kopie auf demselben Server mit dem Server verloren geht.

Ein backup/-Verzeichnis auf dem zu sichernden System schützt nur vor einer Sache: dem versehentlichen Löschen einer Datei. Es schützt nicht vor einem Defekt der Festplatte, da die Daten auf dieser Festplatte liegen. Es schützt nicht vor einem Angreifer mit Root-Rechten, da dieser zuerst die Kopien löscht. Es schützt nicht vor Fehlern bei der Kontoverwaltung, die den VPS selbst löschen. Das ineffizienteste Rechenzentrum der Welt macht Witze über ein tarball namens backup_final_v2_REAL, das auf demselben Array wie die Daten liegt. Der Witz ist passend, da viele Nutzer genau das getan haben. Die Regel lautet: Das Backup muss außerhalb des Systems liegen. Restic ist der einfachste Weg, diese Regel umzusetzen.

Restic in vier Konzepten

Repository. Der Speicherort, in den restic schreibt. Es ist ein Verzeichnis im restic-eigenen Format, das verschlüsselte Blobs enthält. Nur restic kann es lesen. Bearbeiten Sie es niemals manuell; die Kommunikation erfolgt über restic-Befehle und die -r Adresse.

Snapshot. Eine Momentaufnahme der gesicherten Dateien. Jeder Backup-Vorgang erstellt einen Snapshot. Jeder Snapshot kann einzeln wiederhergestellt werden und verhält sich wie eine vollständige Kopie Ihrer Daten zu diesem Zeitpunkt.

Deduplication. Restic teilt Dateien in inhaltsabhängige Chunks auf und lädt nur die Chunks hoch, die das Repository noch nicht kennt. Das erste Backup lädt alle Daten hoch; jeder weitere Durchgang lädt nur die Änderungen hoch. Ein nächtlicher Snapshot von 20 GB, bei dem sich 50 MB geändert haben, verbraucht etwa 50 MB Speicherplatz. Daher ist die Aufbewahrung vieler Snapshots kostengünstig.

Standardmäßige Verschlüsselung. Ein restic-Repository ist immer verschlüsselt (AES-256). Jeder Befehl erfordert das Repository-Passwort. Der Backup-Host oder der Storage-Provider sieht ausschließlich verschlüsselte Blobs. Die Konsequenz: Wenn das Passwort verloren geht, sind die Daten unwiderruflich verloren. Bewahren Sie eine Kopie des Passworts an einem Ort auf, der nicht dieser Server ist. Dies ist so wichtig, dass es im weiteren Verlauf noch zweimal erwähnt wird.

restic auf Ubuntu 24.04 installieren

sudo apt update && sudo apt install -y restic
restic version

Auf Ubuntu 24.04 wird restic 0.16.4 installiert, während die aktuelle Upstream-Version 0.19.1 ist. Diese Differenz entsteht, weil eine LTS (Long Term Support) Version die Paketversionen einfriert. Für diesen Leitfaden ist dies unerheblich: 0.16.4 unterstützt alle Funktionen dieses Guides. Wenn Sie die neueste Version wegen der Geschwindigkeitsverbesserungen benötigen, laden Sie den offiziellen Single-Binary-Build von der GitHub-Releases-Seite des restic-Projekts herunter. Entpacken Sie diesen mit bunzip2 und installieren Sie ihn unter /usr/local/bin/restic; eine restic-Installation erfordert keine weiteren Schritte.

Erstellen des Repositorys auf einem anderen Server über SFTP

Sie benötigen ein Zielsystem: Ein zweiter kleiner VPS ist die übliche Lösung. Jeder Rechner mit einem SSH-Server und freiem Festplattenspeicher ist geeignet. Restic nutzt SFTP (File Transfer Protocol über SSH), daher muss auf dem Backup-Host keine zusätzliche Software installiert sein. In dieser Anleitung ist der Backup-Host 10.0.0.12 mit dem Benutzer restic. Benennen Sie diesen Benutzer nicht backup: Ubuntu und Debian enthalten bei jeder Installation ein reserviertes Systemkonto namens backup (uid 34, keine Login-Shell). Daher schlägt adduser backup fehl und ssh backup@... landet in nologin.

Der nächtliche Job läuft auf dem zu sichernden Server als root, daher benötigt root einen Key-Login auf dem Backup-Host. Erstellen Sie einen dedizierten Key ohne Passphrase, da um 3 Uhr morgens kein Mensch zur Eingabe anwesend ist, und kopieren Sie diesen:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

Falls Sie mit Keys noch nicht vertraut sind, erklärt SSH Key Management Grundlagen das Modell, die Berechtigungen und das spätere Widerrufen eines Keys.

Als Nächstes folgt das Repository-Passwort. Generieren Sie ein starkes Passwort in einer Datei, die nur für root lesbar ist:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

Kopieren Sie dieses Passwort in Ihren Passwort-Manager, bevor Sie fortfahren. Wenn dieser VPS ausfällt, ermöglichen das Repository und dieses Passwort die vollständige Wiederherstellung; ohne das Passwort kann das Repository nichts wiederherstellen.

Initialisieren Sie das Repository:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

Eine Alternative ist S3-kompatibler Objektspeicher. Dies ist die richtige Wahl, wenn Sie keinen zweiten Rechner betreiben möchten. Jeder S3-kompatible Bucket funktioniert auf die gleiche Weise; nur die Adresse und zwei Anmeldevariablen ändern sich:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

Alles nach init ist für beide Ziele identisch. Der Rest dieser Anleitung verwendet die SFTP-Adresse; ersetzen Sie diese durch Ihre eigene.

Das erste Backup mit Ausschlüssen

Sichern Sie nur die Daten, die nicht neu installiert werden können, nicht das gesamte Dateisystem. Das Betriebssystem kann durch eine Neuinstallation wiederhergestellt werden; Ihre Konfigurationen und Daten hingegen nicht. Für einen typischen VPS bedeutet das /etc, /home und alle Orte, an denen Anwendungen Zustände speichern, wie zum Beispiel /srv oder /var/www. Schließen Sie Caches aus, da diese groß sind, sich täglich ändern und sich selbst wieder aufbauen:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

Der erste Durchlauf lädt alles hoch, daher dauert er eine Weile. Führen Sie denselben Befehl erneut aus; er wird in Sekunden fertig sein und melden, dass einige Dateien geändert und einige MiB hinzugefügt wurden, da die Deduplizierung nur neue Chunks hochlädt. Listen Sie auf, was Sie haben:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

Jeder Snapshot zeigt eine ID, eine Zeit und die enthaltenen Pfade. Diese IDs werden für die Wiederherstellung verwendet.

Nightly runs mit einem systemd-Timer

Das manuelle Eingeben der Repository-Adresse bei jedem Befehl ist ineffizient. Manuelle Backups werden meist innerhalb eines Monats vergessen. Beide Probleme lassen sich durch ein Skript und einen Timer lösen. Das Skript setzt die beiden Umgebungsvariablen, die restic benötigt, nämlich RESTIC_REPOSITORY und RESTIC_PASSWORD_FILE. Dadurch bleiben alle Befehle innerhalb des Skripts kurz:

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

Die Zeilen forget und check werden in den nächsten zwei Abschnitten erläutert. Zum Zeitplan: Ein oneshot-Service führt das Skript aus, und ein Timer startet diesen jede Nacht um 03:00 Uhr. Ein Timer ist hier einem cron-Eintrag vorzuziehen, da die Protokolle im Journal gespeichert werden und Persistent=true ein versäumtes Backup sofort nach dem Hochfahren des Servers nach einem Ausfall ausführt.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

Aktivieren Sie den Timer, führen Sie den Service einmal manuell aus und prüfen Sie die Ausführung:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

systemctl list-timers zeigt den nächsten Ausführungszeitpunkt an. Sie können das Paar an Unit-Files auch generieren lassen, anstatt sie manuell zu erstellen:

Das vollständige Konzept hinter diesen beiden Dateien, einschließlich der Kalendersyntax und der Hardening-Direktiven für Services, finden Sie in Ausführen eines Programms als systemd-Service auf einem VPS.

Ein Backup ist nur ein Gerücht, bis Sie es wiederherstellen

Betrachten Sie diesen Satz als Gesetz. Ein Backup-Job, der jede Nacht erfolgreich (grün) durchläuft, beweist nur, dass der Job ausgeführt wurde; er beweist nicht, dass Ihre Daten wiederhergestellt werden können. Zwei Prüfungen schließen diese Lücke.

Erstens: restic check, welches das Skript bereits jede Nacht ausführt. Es verifiziert die Repository-Struktur und den Index. So wird eine stille Korruption auf dem Backup-Host bereits am nächsten Abend erkannt und nicht erst am Tag der Wiederherstellung. Führen Sie einmal im Monat die tiefere Version aus, welche ein zufälliges Zehntel der tatsächlichen Daten herunterlädt und kryptografisch verifiziert:

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

Da die Teilmenge jedes Mal zufällig ist, arbeitet sich der monatliche Durchlauf durch das gesamte Repository, ohne dass ein vollständiger Download erforderlich ist.

Zweitens: Die Wiederherstellungsübung. Nutzen Sie weiterhin die Root-Shell aus dem vorherigen Schritt, stellen Sie ein reales Verzeichnis aus dem neuesten Snapshot an einen temporären Speicherort wieder her und vergleichen Sie es mit den Live-Dateien:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

Wenn diff keine Ausgabe erzeugt, sind alle Bytes identisch zurückgekehrt. Dies ist der einzige relevante Beweis. Löschen Sie /srv/restore-drill anschließend. Führen Sie diese Übung monatlich durch. Ein- bis zweimal pro Jahr sollten Sie die vollständige Version durchführen: Stellen Sie den gesamten neuesten Snapshot auf einem temporären VPS wieder her und prüfen Sie, ob Ihre Anwendung tatsächlich daraus startet. Wenn Sie diese Funktion unter Zeitdruck benötigen, muss der Vorgang eine bereits etablierte Routine sein.

Retention: forget und prune

Ohne eine Policy sammeln sich Snapshots dauerhaft an und das Repository wächst stetig. Die Zeile forget des Skripts wendet jede Nacht eine Policy an: --keep-daily 7 behält einen Snapshot pro Tag für die letzten sieben Tage, --keep-weekly 4 einen pro Woche für vier Wochen und --keep-monthly 6 einen pro Monat für sechs Monate. Alle Daten, die nicht durch eine Regel geschützt sind, werden vergessen.

forget allein entfernt nur die Snapshot-Einträge; die Daten-Chunks verbleiben im Repository, bis sie gelöscht werden. Das ist die Aufgabe von --prune: Es findet Chunks ohne verbleibende Snapshot-Referenzen und löscht diese, wodurch der Speicherplatz tatsächlich freigegeben wird. Prune führt die eigentliche Bereinigung des Repositories durch. Bei großen Repositories führen einige Benutzer forget täglich und --prune wöchentlich aus; bei typischen VPS-Größen ist ein täglicher Durchlauf ausreichend.

Datenbanken: Erst Dump erstellen, dann den Dump sichern

Restic kopiert Dateien während des Lesevorgangs. Eine Datenbank schreibt kontinuierlich in ihre Dateien. Eine Datenbankdatei, die während eines Schreibvorgangs kopiert wird, ist nach der Wiederherstellung beschädigt. Dies geschieht, weil die Kopie Seiten von vor und nach dem Schreibvorgang mischt. Die Standardlösung ist: Lassen Sie die Datenbank-Engine einen konsistenten Export in eine Datei erstellen und lassen Sie restic diese Datei sichern.

Fügen Sie für PostgreSQL eine Dump-Zeile am Anfang von restic-backup.sh vor dem restic backup Befehl hinzu und nehmen Sie das Dump-Verzeichnis in die Backup-Pfade auf:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

mysqldump erfüllt dieselbe Funktion für MariaDB und MySQL. Ein praktisches Beispiel für dieses Vorgehen findet sich im Nextcloud-Backup-Abschnitt. Dort wird der Wartungsmodus aktiviert, Postgres wird gedumpt und die Dateien werden als ein konsistenter Satz kopiert. Dies ist genau der Satz, den restic jede Nacht vom Server übertragen soll. Bei SQLite ist das Prinzip ähnlich, jedoch mit weniger Aufwand: Die Vaultwarden-Anleitung stoppt den Container für einige Sekunden, um eine statische Kopie von db.sqlite3 zu erstellen. Dieses Archiv ist das, was restic vom Server überträgt.

FAQ

Sind restic-Backups verschlüsselt?

Ja, immer. Jedes restic-Repository ist mit AES-256 verschlüsselt. Es gibt keinen unverschlüsselten Modus, und jeder Befehl erfordert das Repository-Passwort. Der Host oder Anbieter, der das Repository speichert, besitzt nur verschlüsselte Blobs. Ein kompromittierter Backup-Host legt Ihre Dateien daher nicht offen. Der Kompromiss ist absolut: Ohne das Passwort können die Daten von niemandem wiederhergestellt werden. Speichern Sie daher eine Kopie des Passworts getrennt vom Server.

Führt restic inkrementelle Backups durch?

Jeder restic-Snapshot verhält sich wie ein Vollbackup, verbraucht aber nur inkrementellen Speicherplatz. Restic teilt Dateien in Chunks auf und lädt nur die Chunks hoch, die das Repository noch nicht gespeichert hat. Ein nächtlicher Durchlauf überträgt daher nur die Änderungen des Tages. Im Gegensatz zu traditionellen inkrementellen Verfahren gibt es keine Kette, die man abspielen muss: Jeder Snapshot lässt sich direkt wiederherstellen, und das Löschen eines alten Snapshots beschädigt niemals einen neueren.

Wie stelle ich Dateien aus einem restic-Backup wieder her?

Führen Sie restic snapshots aus, um die Snapshot-ID zu finden, und anschließend restic restore <id> --target /some/empty/dir für die Wiederherstellung. Nutzen Sie --include /path, um nur Teile des Snapshots wiederherzustellen. latest kann anstelle einer ID verwendet werden. Restic erstellt die ursprüngliche Verzeichnisstruktur im Zielverzeichnis nach. Eine Wiederherstellung von /etc/ssh erfolgt also in /some/empty/dir/etc/ssh. Üben Sie dies, bevor Sie es benötigen, da ein nicht getestetes Backup nur eine Behauptung ist.

Wie oft sollte ich restic backup ausführen?

Ein nächtlicher Durchlauf ist für Server die sinnvolle Untergrenze. Die Deduplizierung macht dies kostengünstig: Jeder Durchlauf lädt nur die Chunks hoch, die sich seit dem letzten Mal geändert haben. Daten mit schnellen Änderungsraten oder Daten, die bei einem Verlust bereits nach einem Tag kritisch wären, können alle paar Stunden mit demselben Zeitplan gesichert werden. Die Häufigkeit ist der einfache Teil; führen Sie auch regelmäßig restic check und einmal monatlich eine Wiederherstellungsprobe durch. Ein Zeitplan ohne Verifizierung bietet keine Sicherheit.

Was passiert, wenn ich mein restic-Repository-Passwort verliere?

Die Backups sind nicht wiederherstellbar. Die Verschlüsselung von restic hat keine Backdoor und keine Reset-Funktion. Das Passwort ist daher genauso wichtig wie die Backups selbst. Speichern Sie eine Kopie in Ihrem Passwort-Manager oder an einem anderen dauerhaften Ort, der nicht der gesicherte Server ist. Solange Sie noch Zugriff haben, kann restic key add ein zweites Passwort für dasselbe Repository registrieren, was Ihnen eine Reserve bietet.