Restic-Backup vom VPS auf einen anderen Server

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: auf einen zweiten VPS, eine Maschine bei Ihnen zu Hause oder einen S3-kompatiblen Objektspeicher. Diese Anleitung richtet Restic unter Ubuntu 24.04 ein. Sie reicht von der Installation über ein Repository per SFTP, ein erstes Backup, einen nächtlichen systemd-Timer und eine Aufbewahrungsrichtlinie bis zur Wiederherstellungsübung, mit der Sie die vollständige Funktionsfähigkeit prüfen. Das Ziel muss eine andere Maschine sein, weil eine Kopie auf demselben Server zusammen mit dem Server ausfällt.

Ein backup/-Verzeichnis auf dem Server, dessen Daten gesichert werden, schützt Sie nur vor dem versehentlichen Löschen einer Datei. Bei einem ausgefallenen Laufwerk bleibt es nicht erhalten, weil es auf diesem Laufwerk lag. Vor einem Angreifer mit root-Rechten schützt es ebenfalls nicht, weil dieser zuerst die Kopien löscht. Auch einen Fehler beim Verwalten des Kontos, durch den der VPS selbst gelöscht wird, übersteht es nicht. Das ineffizienteste Rechenzentrum der Welt macht sich über ein Tar-Archiv namens backup_final_v2_REAL lustig, das auf demselben Array wie die Daten liegt. Der Witz funktioniert, weil viele von uns genau das bereits getan haben. Die Kopie muss außerhalb des Servers liegen. Restic ist der am wenigsten aufwendige Weg, diese Regel einzuhalten.

Restic in vier Grundideen

Repository. Der Speicherort, in den restic schreibt. Es handelt sich um ein Verzeichnis im eigenen Format von restic, das mit verschlüsselten Blobs gefüllt ist und nur von restic gelesen werden kann. Bearbeiten Sie es niemals manuell. Greifen Sie stattdessen über restic-Befehle und die Adresse -r darauf zu.

Snapshot. Eine Momentaufnahme der Dateien zu einem bestimmten Zeitpunkt, die Sie gesichert haben. Jeder Sicherungslauf erstellt einen Snapshot. Jeder Snapshot kann unabhängig wiederhergestellt werden und verhält sich wie eine vollständige Kopie Ihrer Daten zu diesem Zeitpunkt.

Deduplizierung. Restic teilt Dateien in inhaltsdefinierte Chunks auf und überträgt nur Chunks, die im Repository noch nicht vorhanden sind. Die erste Sicherung überträgt alles. Jeder weitere Lauf überträgt ungefähr die Änderungen. Bei einem nächtlichen Snapshot mit 20 GB, in dem sich 50 MB geändert haben, fallen daher etwa 50 MB an. Deshalb ist es kostengünstig, Dutzende Snapshots aufzubewahren.

Verschlüsselung standardmäßig. Ein restic-Repository ist immer verschlüsselt (AES-256). Restic verweigert das Erstellen oder Öffnen eines Repositorys mit einem leeren Passwort, sofern Sie nicht --insecure-no-password übergeben (restic 0.17.0 und höher). Ein Repository, das wie in diesem Leitfaden eingerichtet wurde, benötigt daher für jeden Befehl sein Passwort. Der Backup-Host oder der Speicheranbieter sieht ausschließlich verschlüsselte Blobs. Die entscheidende Konsequenz: Wenn Sie das Passwort verlieren, sind die Daten dauerhaft und absichtlich nicht mehr verfügbar. Bewahren Sie eine Kopie des Passworts an einem Ort auf, der sich nicht auf diesem Server befindet. Das ist so wichtig, dass es weiter unten noch zweimal thematisiert wird.

restic auf Ubuntu 24.04 installieren

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

Unter Ubuntu 24.04 wird damit restic 0.16.4 installiert. Die aktuelle Upstream-Version ist 0.19.1. Dieser Unterschied besteht, weil ein LTS-Release (Long Term Support) die Paketversionen einfriert. Für diesen Zweck ist er unerheblich: 0.16.4 bietet alle Funktionen, die in dieser Anleitung benötigt werden. Wenn Sie wegen der Geschwindigkeitsverbesserungen das neueste Release verwenden möchten, laden Sie den offiziellen Einzelbinär-Build von der GitHub-Releases-Seite des restic-Projekts herunter, packen Sie ihn mit bunzip2 aus und installieren Sie ihn in /usr/local/bin/restic. Für die Installation von restic sind keine weiteren Schritte erforderlich.

Erstellen des Repositorys auf einem anderen Server über SFTP

Sie benötigen einen Zielrechner: Ein zweiter kleiner VPS ist die übliche Lösung, und jeder Rechner mit einem SSH-Server und freiem Speicherplatz funktioniert. Restic verwendet SFTP (Dateiübertragung über SSH), daher muss auf dem Backup-Host keine Software installiert werden. In dieser Anleitung ist der Backup-Host 10.0.0.12 mit einem Benutzer namens restic. Nennen Sie diesen Benutzer nicht backup: Ubuntu und Debian liefern bei jeder Installation ein reserviertes Systemkonto namens backup (UID 34, keine Login-Shell) aus, daher schlägt adduser backup fehl und ssh backup@... landet in nologin.

Der nächtliche Job wird als root auf dem zu sichernden Server ausgeführt, daher benötigt root einen schlüsselbasierten Login auf dem Backup-Host. Erstellen Sie einen dedizierten Schlüssel ohne Passphrase, da um 3 Uhr morgens kein Mensch anwesend ist, um diese einzugeben, und kopieren Sie ihn:

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 Ihnen Schlüssel neu sind, erklärt Grundlagen der SSH-Schlüsselverwaltung das Modell, die Berechtigungen und wie ein Schlüssel später widerrufen wird.

Als Nächstes das Repository-Passwort. Generieren Sie ein starkes Passwort in eine 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 nun in Ihren Passwort-Manager, bevor Sie fortfahren. Wenn dieser VPS ausfällt, stellt das Repository zusammen mit diesem Passwort alles wieder her; das Repository ohne das Passwort stellt nichts wieder her.

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

Das alternative Ziel ist S3-kompatibler Objektspeicher, was die richtige Wahl ist, wenn Sie keinen zweiten Rechner betreiben möchten. Jeder S3-kompatible Bucket funktioniert auf die gleiche Weise; nur die Adresse und zwei Zugangsdaten-Variablen ä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 zeigt die SFTP-Adresse; ersetzen Sie diese durch Ihre eigene.

Das erste Backup mit Ausschlüssen

Sichern Sie die Daten, die Sie nicht neu installieren können, und nicht das gesamte Dateisystem. Das Betriebssystem lässt sich durch eine Neuinstallation wiederherstellen. Ihre Konfiguration und Ihre Daten jedoch nicht. Bei einem typischen VPS sind das /etc, /home und die Verzeichnisse, in denen Ihre Anwendungen ihren Zustand speichern, beispielsweise /srv oder /var/www. Schließen Sie Caches aus. Sie sind groß, ändern sich täglich und werden automatisch neu erstellt:

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

Beim ersten Lauf werden alle Daten hochgeladen. Das dauert daher eine Weile. Führen Sie denselben Befehl erneut aus. Er ist dann innerhalb weniger Sekunden abgeschlossen und meldet nur wenige geänderte Dateien sowie einige hinzugefügte MiB, weil die Deduplizierung nur neue Chunks hochlädt. Listen Sie die vorhandenen Snapshots auf:

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

Jeder Snapshot zeigt eine ID, einen Zeitpunkt und die darin enthaltenen Pfade. Anhand dieser IDs führen Sie Wiederherstellungen durch.

Nächtliche Ausführung mit einem systemd-Timer

Die Repository-Adresse bei jedem Befehl einzugeben, wird schnell lästig. Außerdem wird eine manuell gestartete Sicherung innerhalb eines Monats meist nicht mehr ausgeführt. Beide Probleme lassen sich mit einem Skript und einem Timer lösen. Das Skript setzt die beiden Umgebungsvariablen, die restic liest: RESTIC_REPOSITORY und RESTIC_PASSWORD_FILE. Dadurch bleiben alle darin enthaltenen Befehle 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 beiden Abschnitten erklärt. Jetzt zum Zeitplan: Ein oneshot-Dienst führt das Skript aus. Ein Timer startet ihn jede Nacht um 03:00. Ein Timer ist hier besser geeignet als ein cron-Eintrag, weil die Ausführung im Journal protokolliert wird. Außerdem führt Persistent=true eine verpasste Sicherung aus, sobald der Server nach einem Ausfall wieder läuft.

# /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. Starten Sie den Dienst anschließend einmal manuell und beobachten 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, wann die nächste Ausführung startet. Sie können die beiden Unit-Dateien auch generieren, statt sie einzugeben:

Das vollständige Muster hinter diesen beiden Dateien, einschließlich der Kalendersyntax und der Hardening-Direktiven, die ein Dienst enthalten kann, finden Sie unter ein Programm als systemd-Dienst auf einem VPS ausführen.

Eine Sicherung ist bis zur Wiederherstellung nur ein Gerücht

Behandeln Sie diesen Satz als verbindliche Regel. Ein Sicherungsjob, der jede Nacht erfolgreich durchläuft, beweist nur, dass ein 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, das das Skript bereits jede Nacht ausführt. Der Befehl überprüft die Struktur des Repositorys und den Index. Dadurch wird eine unbemerkte Beschädigung auf dem Backup-Host in der folgenden Nacht erkannt und nicht erst am Tag der Wiederherstellung. Führen Sie einmal im Monat die gründlichere Variante aus. Sie lädt ein zufällig ausgewähltes Zehntel der tatsächlichen Daten herunter und überprüft es kryptografisch:

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 ausgewählt wird, weist die Dokumentation von restic ausdrücklich darauf hin, dass wiederholte Ausführungen nicht garantiert jede Pack-Datei abdecken, unabhängig von ihrer Anzahl. Wenn monatliche Ausführungen das gesamte Repository durchlaufen sollen, ohne jemals einen vollständigen Download zu verursachen, verwenden Sie stattdessen die feste Gruppenform: --read-data-subset=1/10 in einem Monat, 2/10 im nächsten und so weiter bis 10/10. Restic teilt die Pack-Dateien in zehn ungefähr gleich große Gruppen auf und prüft jeweils nur die Gruppe n. Ein vollständiger Zyklus aus zehn Ausführungen liest daher jede Gruppe einmal.

Zweitens die Wiederherstellungsübung. Bleiben Sie in der Root-Shell aus dem vorherigen Abschnitt. Stellen Sie ein echtes Verzeichnis aus dem neuesten Snapshot an einem temporären Speicherort wieder her und vergleichen Sie es mit den aktiven Dateien:

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

Wenn diff nichts ausgibt, wurde jedes Byte identisch wiederhergestellt. Nur dieser Nachweis ist maßgeblich. Löschen Sie /srv/restore-drill anschließend. Führen Sie diese Übung monatlich durch. Ein- oder zweimal pro Jahr sollten Sie außerdem die vollständige Variante ausführen: Stellen Sie den gesamten neuesten Snapshot auf einem temporären VPS wieder her und prüfen Sie, ob Ihre Anwendung daraus tatsächlich startet. Wenn dies unter Zeitdruck funktionieren muss, sollte es für Sie ein bereits erprobter Routinevorgang sein.

Aufbewahrung: forget und prune

Ohne Aufbewahrungsrichtlinie sammeln sich Snapshots unbegrenzt an, und das Repository wächst weiter. Die Zeile forget im Skript wendet jede Nacht eine Richtlinie an: --keep-daily 7 behält für die letzten sieben Tage einen Snapshot pro Tag, --keep-weekly 4 einen pro Woche für vier Wochen und --keep-monthly 6 einen pro Monat für sechs Monate. Alles, was von keiner Regel geschützt wird, wird vergessen.

forget entfernt allein nur die Snapshot-Einträge. Die Datenblöcke bleiben im Repository, bis sie gelöscht werden. Genau das erledigt --prune: Der Befehl ermittelt Datenblöcke, auf die kein verbleibender Snapshot mehr verweist, und löscht sie. Erst dann wird tatsächlich Speicherplatz freigegeben. Prune führt echte Arbeiten am Repository aus. Deshalb führen manche forget jede Nacht und --prune wöchentlich aus, wenn das Repository groß ist. Bei typischen VPS-Größen reicht eine nächtliche Ausführung aus.

Datenbanken: Zuerst einen Dump erstellen, dann den Dump sichern

Restic kopiert Dateien, während es sie liest. Eine Datenbank schreibt kontinuierlich in ihre Dateien. Wird eine Live-Datenbankdatei während eines Schreibvorgangs erfasst, lässt sich die wiederhergestellte Datenbank nicht verwenden, weil die Kopie Seiten aus der Zeit vor und nach dem Schreibvorgang mischt. Die Standardlösung ist einfach: Lassen Sie die Datenbank-Engine einen konsistenten Export in eine Datei erstellen. Anschließend sichert restic diese Datei.

Fügen Sie für PostgreSQL am Anfang von restic-backup.sh, vor dem Befehl restic backup, eine Dump-Zeile ein. Nehmen Sie außerdem das Dump-Verzeichnis in die zu sichernden Pfade auf:

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

mysqldump übernimmt dieselbe Aufgabe für MariaDB und MySQL. Ein vollständiges Beispiel für dieses Verfahren finden Sie im Abschnitt zur Nextcloud-Sicherung. Dort wird der Wartungsmodus aktiviert, ein Postgres-Dump erstellt und die Dateien als ein konsistenter Satz kopiert. Genau diesen Satz sollte restic jede Nacht vom Server übertragen. Bei SQLite gilt dasselbe Prinzip mit einem kleineren Eingriff: Der Vaultwarden-Leitfaden stoppt den Container für einige Sekunden, um eine kalte Kopie von db.sqlite3 zu erstellen. Dieses Archiv überträgt restic vom Server.

FAQ

Sind restic-Sicherungen verschlüsselt?

Ja, immer. Jedes restic-Repository ist mit AES-256 verschlüsselt. Einen unverschlüsselten Modus gibt es nicht. Restic verweigert außerdem ein leeres Passwort, sofern Sie nicht --insecure-no-password übergeben (verfügbar seit restic 0.17.0). Ein Repository, das wie in diesem Leitfaden eingerichtet wurde, benötigt daher für jeden Befehl sein Passwort. Der Rechner oder Anbieter, auf dem das Repository gespeichert ist, enthält ausschließlich verschlüsselte Blobs. Ein kompromittierter Backup-Host gibt Ihre Dateien daher nicht preis. Die Konsequenz ist eindeutig: Ohne das Passwort kann niemand die Daten wiederherstellen. Bewahren Sie deshalb eine Kopie außerhalb des Servers auf.

Führt restic inkrementelle Sicherungen durch?

Jeder restic-Snapshot verhält sich wie eine vollständige Sicherung, benötigt aber nur inkrementellen Speicherplatz. Restic teilt Dateien in Chunks auf und überträgt nur Chunks, die im Repository noch nicht gespeichert sind. Ein nächtlicher Lauf überträgt daher ungefähr die Änderungen dieses Tages. Anders als bei herkömmlichen inkrementellen Verfahren gibt es keine Kette, die erneut verarbeitet werden muss. Jeder Snapshot kann direkt wiederhergestellt werden. Das Löschen eines alten Snapshots beschädigt daher keinen neueren Snapshot.

Wie stelle ich Dateien aus einer restic-Sicherung wieder her?

Führen Sie restic snapshots aus, um die Snapshot-ID zu ermitteln. Verwenden Sie anschließend restic restore <id> --target /some/empty/dir für die Wiederherstellung. Mit --include /path können Sie die Wiederherstellung auf einen Teil des Snapshots beschränken. latest kann anstelle einer ID verwendet werden. Restic stellt die ursprüngliche Verzeichnisstruktur unterhalb des Zielpfads wieder her. Eine Wiederherstellung von /etc/ssh landet daher in /some/empty/dir/etc/ssh. Üben Sie dies, bevor Sie es benötigen, denn eine nicht getestete Sicherung ist nur ein Gerücht.

Wie oft sollte ich restic backup ausführen?

Für einen Server ist eine nächtliche Ausführung das sinnvolle Minimum. Durch die Deduplizierung ist sie kostengünstig, da jeder Lauf nur die seit dem vorherigen Lauf geänderten Chunks überträgt. Daten, die sich schnell ändern oder deren Verlust von nur einem Tag bereits problematisch wäre, können nach demselben Timer-Muster alle paar Stunden gesichert werden. Die Häufigkeit ist jedoch nur die eine Hälfte. Führen Sie regelmäßig auch restic check und monatlich eine Wiederherstellungsübung aus. Ein Zeitplan ohne Überprüfung vermittelt nur eine trügerische Sicherheit.

Was passiert, wenn ich das Passwort meines restic-Repositorys verliere?

Die Sicherungen können nicht wiederhergestellt werden. Die Verschlüsselung von restic hat weder eine Hintertür noch eine Möglichkeit zum Zurücksetzen. Das Passwort ist daher genauso wichtig wie die Sicherungen selbst. Bewahren Sie eine Kopie in Ihrem Passwortmanager und an einem weiteren dauerhaften Ort auf, der sich nicht auf dem gesicherten Server befindet. Solange Sie noch Zugriff haben, kann restic key add ein zweites Passwort für dasselbe Repository registrieren. Dadurch erhalten Sie ein Ersatzpasswort.