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 -r-Adresse darauf zu.

Snapshot. Eine Momentaufnahme der gesicherten Dateien zu einem bestimmten Zeitpunkt. 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 inhaltsbasierte Chunks auf und lädt nur die Chunks hoch, die im Repository noch nicht vorhanden sind. Die erste Sicherung lädt alle Daten hoch. Jeder weitere Lauf lädt ungefähr die geänderten Daten hoch. Ein nächtlicher Snapshot mit 20 GB, bei dem sich 50 MB geändert haben, verursacht etwa 50 MB Speicherbedarf. Deshalb können Sie Dutzende Snapshots kostengünstig aufbewahren.

Verschlüsselung standardmäßig. Ein restic-Repository ist immer verschlüsselt (AES-256), und für jeden Befehl ist das Repository-Passwort erforderlich. Der Sicherungshost oder der Speicheranbieter sieht ausschließlich verschlüsselte Blobs. Die entscheidende Konsequenz: Wenn Sie das Passwort verlieren, sind die Daten dauerhaft und absichtlich unwiederbringlich verloren. Bewahren Sie eine Kopie des Passworts an einem Ort auf, der nicht dieser Server ist. Das ist so wichtig, dass es weiter unten noch zweimal zur Sprache kommt.

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.

Repository auf einem anderen Server über SFTP erstellen

Sie benötigen ein Zielsystem. Ein zweiter kleiner VPS ist dafür die übliche Lösung. Geeignet ist jedes System mit einem SSH-Server und ausreichend freiem Speicherplatz. Restic unterstützt SFTP (Dateiübertragung über SSH). Auf dem Backup-Host muss daher nichts installiert werden. In dieser Anleitung ist der Backup-Host 10.0.0.12. Der Benutzer heißt restic. Verwenden Sie nicht den Namen backup. Ubuntu und Debian liefern bei jeder Installation ein reserviertes Systemkonto namens backup (uid 34, ohne Login-Shell) mit. Daher schlägt adduser backup fehl, und ssh backup@... legt die Dateien unter nologin ab.

Der nächtliche Job läuft als root auf dem Server, dessen Daten gesichert werden. Daher benötigt root eine Anmeldung per Schlüssel am Backup-Host. Erstellen Sie einen dedizierten Schlüssel ohne Passphrase. Um 3am ist niemand anwesend, um eine Passphrase einzugeben. Kopieren Sie den Schlüssel anschließend auf den Backup-Host:

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

Wenn Ihnen SSH-Schlüssel noch nicht vertraut sind, erklärt die Grundlagen der SSH-Schlüsselverwaltung das Modell, die Berechtigungen und das spätere Sperren eines Schlüssels.

Als Nächstes benötigen Sie das Repository-Passwort. Erzeugen Sie ein starkes Passwort in einer Datei, auf die nur root zugreifen kann:

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

Kopieren Sie dieses Passwort jetzt in Ihren Passwortmanager, bevor Sie fortfahren. Wenn dieser VPS ausfällt, stellen das Repository und dieses Passwort alle Daten 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

Die alternative Zielumgebung ist ein S3-kompatibler Objektspeicher. Das ist die richtige Wahl, wenn Sie keinen zweiten Rechner betreiben möchten. Jeder S3-kompatible Bucket funktioniert auf dieselbe 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 restliche Teil dieser Anleitung verwendet die SFTP-Adresse. Ersetzen Sie sie durch Ihre Adresse.

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.

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

Betrachten Sie diesen Satz als verbindliche Regel. Ein Backup-Auftrag, der jede Nacht erfolgreich durchläuft, belegt nur, dass ein Auftrag ausgeführt wurde. Er belegt 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. Es prü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 bei jeder Ausführung zufällig ausgewählt wird, arbeiten sich monatliche Ausführungen durch das gesamte Repository, ohne dass jemals ein vollständiger Download erforderlich ist.

Zweitens die Wiederherstellungsübung. Bleiben Sie in der Root-Shell von oben. 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, sind alle Bytes identisch wiederhergestellt worden. Das ist der einzige relevante Nachweis. Löschen Sie /srv/restore-drill anschließend. Führen Sie diese Übung monatlich durch. Ein- oder zweimal pro Jahr sollten Sie die vollständige Variante durchführen: Stellen Sie den gesamten neuesten Snapshot auf einem temporären VPS wieder her und prüfen Sie, ob Ihre Anwendung tatsächlich von dort startet. Wenn diese Wiederherstellung unter Zeitdruck funktionieren muss, sollte sie für Sie bereits ein geübter 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-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. Auf dem Rechner oder beim Anbieter, der das Repository speichert, liegen ausschließlich verschlüsselte Blobs. Ein kompromittierter Backup-Host legt Ihre Dateien daher nicht offen. Der Nachteil ist eindeutig: Ohne das Passwort kann niemand die Daten wiederherstellen. Bewahren Sie deshalb eine Kopie außerhalb des Servers auf.

Erstellt restic inkrementelle Backups?

Jeder restic-Snapshot verhält sich wie ein vollständiges Backup, benötigt aber nur inkrementellen Speicherplatz. restic teilt Dateien in Chunks auf und lädt nur Chunks hoch, die noch nicht im Repository 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 wiedergegeben werden muss. Jeder Snapshot lässt sich direkt wiederherstellen, und das Löschen eines alten Snapshots macht keinen neueren Snapshot unbrauchbar.

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

Führen Sie restic snapshots aus, um die Snapshot-ID zu ermitteln. Stellen Sie den Snapshot anschließend mit restic restore <id> --target /some/empty/dir wieder her. Mit --include /path stellen Sie nur einen Teil davon wieder her. latest kann anstelle einer ID verwendet werden. restic erstellt die ursprüngliche Verzeichnisstruktur unter dem Zielverzeichnis neu. Die Wiederherstellung von /etc/ssh landet daher in /some/empty/dir/etc/ssh. Testen Sie diesen Ablauf, bevor Sie ihn benötigen. Ein nicht getestetes Backup ist nur eine Vermutung.

Wie oft sollte ich restic backup ausführen?

Für einen Server ist ein nächtlicher Lauf die sinnvolle Mindestfrequenz. Durch Deduplizierung bleibt er kostengünstig: Jeder Lauf lädt nur die Chunks hoch, die sich seit dem vorherigen Lauf geändert haben. Daten, die sich schnell ändern oder deren Verlust von nur einem Tag bereits problematisch wäre, können mit demselben Timer-Muster alle paar Stunden gesichert werden. Die Häufigkeit ist nur die eine Hälfte. Führen Sie außerdem regelmäßig restic check aus und monatlich einen Wiederherstellungstest. Ein Zeitplan ohne Überprüfung vermittelt nur eine trügerische Sicherheit.

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

Die Backups sind nicht wiederherstellbar. 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 Backups selbst. Bewahren Sie eine Kopie in Ihrem Passwortmanager und an einem weiteren dauerhaften Ort auf, der nicht der gesicherte Server ist. Solange Sie noch Zugriff haben, kann restic key add ein zweites Passwort für dasselbe Repository registrieren. Damit steht Ihnen ein Ersatzpasswort zur Verfügung.