Ein Unternehmen, das für jede Anwendung einen eigenen Server betreibt, sammelt schnell ein Dutzend unterschiedlicher Sicherungslösungen an: ein Skript hier, ein Cronjob dort, manche Server ganz ohne Sicherung. Anwendungsdateien, hochgeladene Nutzerinhalte, Konfigurationsdateien und Logdateien liegen dabei auf jedem Server anders verteilt. Ein Sicherungswerkzeug, das nur eine einzelne Datenbank abdeckt, hilft bei diesem Durcheinander nicht weiter, weil es die restlichen Dateien eines Servers gar nicht kennt. Restic schließt genau diese Lücke: Es sichert beliebige Verzeichnisse eines Dateisystems, verschlüsselt sie, bevor sie den Quellserver verlassen, und speichert viele Server platzsparend in einem gemeinsamen Ziel.
Restic ist ein quelloffenes, aktiv gepflegtes Sicherungsprogramm für beliebige Dateien und Verzeichnisse. Version 0.19.1 erschien am 5. Juli 2026. Jede Sicherung verschlüsselt Restic clientseitig mit AES-256 im Zählmodus (Counter Mode), bevor auch nur ein Byte den Quellserver verlässt, und erkennt gleiche Dateiabschnitte über mehrere Sicherungsläufe und mehrere Server hinweg wieder. Ein gemeinsames Sicherungsziel muss dadurch denselben Inhalt nicht mehrfach speichern, selbst wenn er von unterschiedlichen Servern stammt.
Das deckt sich mit der Aufgabe, die auch pgBackRest löst, allerdings für ein anderes Problem. pgBackRest sichert ausschließlich PostgreSQL-Datenbanken über die fortlaufende Archivierung ihres Transaktionsprotokolls und erlaubt damit eine Wiederherstellung auf die exakte Sekunde vor einem Fehler. Restic kennt kein Transaktionsprotokoll und keine Datenbank-Interna. Dafür sichert es alles andere: Anwendungscode, hochgeladene Bilder, Konfigurationsdateien, Logverzeichnisse, auch die Datendateien einer Datenbank als reine Dateikopie ohne Transaktionsbezug. Ein Team, das beide Aufgaben hat, setzt beide Werkzeuge nebeneinander ein, nicht gegeneinander: pgBackRest für den Datenbankserver, Restic für alles, was auf demselben und auf jedem anderen Server sonst noch liegt.
Systemvoraussetzungen
Eine Installation braucht wenige, klar benannte Bausteine. Die folgende Tabelle listet sie mit den aktuellen Angaben aus der Projektdokumentation und der Versionshistorie.
| Komponente | Version oder Anforderung | Zweck |
|---|---|---|
| Restic | Version 0.19.1 (5. Juli 2026, aktuelle stabile Version) | Führt Sicherung, Wiederherstellung und Aufräumarbeiten aus |
| Zu sichernder Server | Beliebiges Betriebssystem mit Restic-Binärdatei, unter anderem Linux, macOS, Windows und BSD | Quelle der zu sichernden Verzeichnisse |
| Repository-Ziel | S3-kompatibler Objektspeicher mit Endpoint, Bucket und Zugriffsschlüssel, alternativ lokales Verzeichnis oder SFTP-Ziel | Gemeinsamer, verschlüsselter Speicherort für viele Server |
Umgebungsvariable RESTIC_REPOSITORY | Enthält die Zieladresse des Repositorys | Erspart die Wiederholung des Zielorts bei jedem Befehl |
Umgebungsvariable RESTIC_PASSWORD | Enthält das Repository-Passwort | Erlaubt unbeaufsichtigte, automatisierte Sicherungsläufe |
| Netzwerkzugriff | Ausgehende HTTPS-Verbindung vom Quellserver zum Speicherziel | Überträgt die verschlüsselten Daten zum Repository |
Systemarchitektur
Jeder Server bekommt in Restic keine eigene Installation und keine eigene Sonderkonfiguration, sondern lediglich einen eigenen Aufruf desselben Programms gegen dasselbe Repository, den verschlüsselten und deduplizierten Speicherort für alle angeschlossenen Server. Restic unterscheidet die Server dabei über den Hostnamen, den es bei jedem Sicherungslauf automatisch im Snapshot vermerkt.
flowchart TD
A[Server eins mit Anwendungsdateien] --> B[restic backup verschluesselt lokal]
C[Server zwei mit Uploads und Konfiguration] --> D[restic backup verschluesselt lokal]
B --> E[Content Defined Chunking zerlegt Dateien in Blobs]
D --> E
E --> F[Gleiche Blobs werden nur einmal gespeichert]
F --> G[Gemeinsames Repository auf S3 kompatiblem Speicher]
G --> H[restic snapshots zeigt Sicherungen je Host]
G --> I[restic forget markiert alte Snapshots nach Aufbewahrungsregel]
I --> J[restic prune entfernt nicht mehr referenzierte Blobs]
G --> K[restic unlock entfernt eine verwaiste Sperre nach Abbruch]
Der Ablauf beginnt auf dem jeweiligen Quellserver. Der Befehl restic backup liest die angegebenen Verzeichnisse und zerlegt jede Datei über ein Verfahren namens Content-Defined Chunking in unterschiedlich große Blöcke, sogenannte Blobs, bevor es jeden Blob einzeln verschlüsselt. Content-Defined Chunking bestimmt die Schnittstellen zwischen den Blöcken über eine gleitende Prüfsumme, ein Rabin-Fingerprint-Verfahren über ein 64-Byte-Fenster, statt über feste Byte-Abstände. Ändert sich mitten in einer großen Datei nur ein kleiner Abschnitt, verschieben sich dadurch nicht alle nachfolgenden Blockgrenzen. Der überwiegende Teil der Datei erzeugt deshalb beim nächsten Lauf exakt dieselben Blobs wie zuvor. Weil Restic jeden Blob über seinen SHA-256-Hash identifiziert, erkennt es identische Blobs auch dann wieder, wenn sie von einem völlig anderen Server stammen. Zwei Server mit derselben Softwareinstallation oder überlappenden Konfigurationsdateien teilen sich im Repository denselben gespeicherten Inhalt, auch wenn beide unabhängig voneinander und zu unterschiedlichen Zeiten sichern.
Schritt-für-Schritt-Umsetzung
Repository auf S3-kompatiblem Speicher einrichten
Ein Repository muss einmalig angelegt werden, bevor der erste Server sichern kann. Die Zugangsdaten für den Objektspeicher stehen dafür als Umgebungsvariablen bereit, zusammen mit der Zieladresse und dem Repository-Passwort.
export AWS_ACCESS_KEY_ID=<IHR_ZUGRIFFSSCHLUESSEL>
export AWS_SECRET_ACCESS_KEY=<IHR_GEHEIMER_SCHLUESSEL>
export RESTIC_REPOSITORY=s3:s3.eu-central-1.amazonaws.com/firma-restic-backups
export RESTIC_PASSWORD=<EIN-LANGES-EINMALIGES-PASSWORT>
restic initrestic init legt im angegebenen Bucket die Verzeichnisstruktur des Repositorys an und verschlüsselt sie sofort mit dem übergebenen Passwort. Jeder weitere Server, der in dasselbe Repository sichern soll, braucht dieselben drei Umgebungsvariablen und sonst nichts: keine eigene Installation des Objektspeichers, keine zweite Konfigurationsdatei.
Ersten Snapshot eines Verzeichnisses erstellen
Der Befehl restic backup sichert die angegebenen Pfade und legt dabei einen Snapshot an, den in sich abgeschlossenen Stand aller gesicherten Dateien zu genau diesem Zeitpunkt.
restic backup /var/www/anwendung /etc/anwendungJeder weitere Aufruf auf demselben Server sichert nur noch die seither veränderten Blobs, weil Restic den letzten Snapshot als Vergleichsgrundlage nutzt. Der Befehl restic snapshots listet anschließend alle bisherigen Sicherungsläufe im Repository auf, über alle angeschlossenen Server hinweg, unterschieden nach Host.
restic snapshots
ID Datum Host Pfad Groesse
------------------------------------------------------------------------
3a1f9c02 2026-08-20 02:15:04 server-a /var/www/anwendung 4.821GiB
78bd21aa 2026-08-21 02:15:11 server-a /var/www/anwendung 4.822GiB
c02e441f 2026-08-21 02:30:02 server-b /srv/uploads 981.400MiBDie Spalte Host zeigt, von welchem Server ein Snapshot stammt. Mit der Option --host lässt sich die Liste gezielt auf einen einzelnen Server einschränken, etwa restic snapshots --host server-b, wenn mehrere Dutzend Server gemeinsam in ein Repository sichern und die volle Liste unübersichtlich wird.
Alte Snapshots mit forget und prune entfernen
Ohne Aufräumen wächst ein Repository unbegrenzt, weil jeder Sicherungslauf neue Snapshots und neue Blobs hinzufügt, aber keinen automatisch wieder entfernt. Restic trennt das Aufräumen deshalb in zwei getrennte Befehle. forget markiert Snapshots anhand einer Aufbewahrungsregel zur Löschung. prune entfernt anschließend die Datenblöcke, auf die kein verbleibender Snapshot mehr verweist. Nur forget aufzurufen setzt lediglich Markierungen und gibt noch keinen Speicherplatz frei.
forgetmit Aufbewahrungsregel aufrufen. Restic markiert veraltete Snapshots je Server zur Löschung und behält dabei die jeweils neueste Sicherung pro Tag, Woche und Monat.- Ergebnis mit
restic snapshotsprüfen. Die Liste zeigt danach nur noch die verbliebenen, nicht markierten Snapshots. pruneaufrufen. Restic entfernt alle Blobs, auf die kein Snapshot mehr zeigt, und gibt den freigewordenen Speicherplatz im Repository zurück.- Ablauf automatisiert wiederholen. Ein Cronjob je Server ruft
backup,forgetundprunein dieser Reihenfolge nach jedem Sicherungslauf auf.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6
restic pruneDie Optionen --keep-daily, --keep-weekly und --keep-monthly behalten jeweils die neueste Sicherung des angegebenen Zeitraums und verwerfen den Rest. --keep-daily 7 behält damit die letzten sieben Tage mit mindestens einer Sicherung, --keep-monthly 6 zusätzlich die letzten sechs Monatssicherungen, auch wenn diese älter als sieben Tage sind. Der anschließende Aufruf von restic prune liest das gesamte Repository, ermittelt alle noch referenzierten Blobs und löscht den Rest endgültig.
Häufige Fehlerquellen
- Verlorenes Repository-Passwort. Restic verschlüsselt jedes Repository mit genau einem Passwort, und die eigene Dokumentation warnt ausdrücklich, dass ein verlorenes Passwort die gesicherten Daten unwiederbringlich macht. Fix: Das Passwort in einem Passwort-Tresor oder Secrets-Management-System hinterlegen, nie nur auf dem gesicherten Server selbst, sonst geht mit dem Server auch der Zugriff auf sein eigenes Backup verloren.
- Verwaiste Sperre nach abgebrochenem Lauf. Bricht ein Sicherungslauf durch einen Netzwerkfehler oder einen abgebrochenen Prozess mitten in der Ausführung ab, bleibt die Sperre, die Restic für die Dauer des Laufs auf dem Repository hält, mitunter bestehen. Jeder folgende Aufruf schlägt dann mit dem Hinweis auf ein bereits gesperrtes Repository fehl. Fix:
restic unlockentfernt eine verwaiste Sperre eines beendeten Prozesses, bevor der nächste Lauf beginnt. - forget ohne anschließendes prune. Ein Cronjob, der nur
restic forgetaufruft, markiert veraltete Snapshots zwar zur Löschung, das Repository schrumpft dadurch aber nicht, weil die zugehörigen Datenblöcke weiterhin gespeichert bleiben. Fix:prunedirekt im Anschluss anforgetim selben Skript aufrufen, nicht als getrennten, seltener laufenden Job. - Fehlende Aufbewahrungsregel. Ein Sicherungsskript, das nur
restic backupaufruft und nieforget, sammelt für jeden Server unbegrenzt viele Snapshots an, bis der Objektspeicher spürbar teurer wird. Fix: Von Anfang an eine Aufbewahrungsregel mit--keep-daily,--keep-weeklyund--keep-monthlyfestlegen und automatisiert laufen lassen. - Falsche oder abgelaufene Zugangsdaten für den Objektspeicher. Ein abgelaufener oder falsch berechtigter Zugriffsschlüssel für das S3-kompatible Ziel lässt
restic backupmit einem Verbindungs- oder Berechtigungsfehler abbrechen, oft zuerst auf einem von vielen Servern, während die übrigen weiterhin erfolgreich sichern. Fix: Zugriffsschlüssel vor dem produktiven Einsatz mit einem einzelnenrestic snapshots-Aufruf testen und die Rotation der Schlüssel fest einplanen.
Häufig gestellte Fragen
Was unterscheidet Restic von einem datenbankspezifischen Sicherungswerkzeug wie pgBackRest?
Restic unterscheidet sich von einem datenbankspezifischen Werkzeug wie pgBackRest dadurch, dass es beliebige Dateien und Verzeichnisse sichert, statt sich auf eine einzelne Datenbank und deren Transaktionsprotokoll zu spezialisieren. pgBackRest archiviert fortlaufend das Write-Ahead-Log von PostgreSQL und erlaubt dadurch eine Wiederherstellung auf die exakte Sekunde vor einem Fehler, kennt aber ausschließlich diese eine Datenbank. Restic kennt keine Datenbank-Interna, sichert dafür Anwendungscode, hochgeladene Dateien, Konfigurationen und Logs gleichermaßen und lässt sich neben pgBackRest auf demselben Server einsetzen, ohne dass sich beide Werkzeuge in die Quere kommen.
Wie verschlüsselt Restic die Daten eines Backups?
Restic verschlüsselt die Daten eines Backups mit AES-256 im Zählmodus und authentifiziert jeden Block zusätzlich mit Poly1305-AES, bevor auch nur ein Byte den Quellserver verlässt. Jeder verschlüsselte Datenblock besteht laut Projektdokumentation aus Initialisierungsvektor, verschlüsseltem Inhalt und Prüfsumme, zusammen 32 Byte Zusatzaufwand je Block. Das Passwort für diese Verschlüsselung wird nirgends im Repository selbst gespeichert, sondern nur beim Zugriff eingegeben oder aus der Umgebungsvariable RESTIC_PASSWORD gelesen.
Wie funktioniert die Deduplizierung, wenn mehrere Server dasselbe Repository nutzen?
Die Deduplizierung funktioniert bei mehreren Servern im selben Repository über Content-Defined Chunking: Restic zerlegt jede Datei anhand einer gleitenden Prüfsumme in unterschiedlich große Blöcke und identifiziert jeden Block über seinen SHA-256-Hash. Zwei Server, die identische oder überlappende Dateien sichern, etwa dieselbe Softwareinstallation, erzeugen dabei identische Blöcke, die Restic nur einmal im Repository ablegt, unabhängig davon, von welchem Server sie zuerst ankamen. Laut eigener Projektdokumentation führt genau dieser Effekt dazu, dass mehrere Server, die gemeinsam sichern, den Speicherbedarf gegenüber getrennten Sicherungszielen spürbar senken.
Was passiert, wenn das Repository-Passwort von Restic verloren geht?
Geht das Repository-Passwort von Restic verloren, sind laut eigener Projektdokumentation sämtliche darin gesicherten Daten unwiederbringlich verloren, weil es keinen eingebauten Wiederherstellungsmechanismus für ein vergessenes Passwort gibt. Restic speichert das Passwort selbst nirgends im Repository, sondern nur einen daraus abgeleiteten Schlüssel, gegen den eine Eingabe geprüft wird. Wer viele Server gegen ein gemeinsames Repository sichert, sollte das Passwort deshalb von Anfang an in einem Passwort-Tresor oder Secrets-Management-System hinterlegen, getrennt von den gesicherten Servern selbst.