Restic Backup: 7 Schritte für Ihr Linux-Backup

Eine gelöschte Datei ist ärgerlich. Ein defektes Update kurz vor dem Wochenende ist schlimmer. Richtig unerquicklich wird es erst, wenn auf dem Linux-Rechner das einzige Fotoarchiv, der Schlüsselordner oder die kleine Datenbank liegt – und das angebliche Backup bloß eine alte USB-Platte im Schrank ist. Restic Backup bringt Ordnung in diese Sorte Nervosität: Das Werkzeug arbeitet im Terminal, verschlüsselt die Sicherung und bleibt angenehm unspektakulär. Genau so muss Backup-Software sein.

Restic Backup beginnt nicht mit einem Skript

Bevor Sie den ersten Befehl kopieren, lohnt sich eine unbequeme Frage: Was wäre nach einem Geräteverlust tatsächlich weg? Bei vielen Linux-Nutzenden sind das nicht nur /home, sondern auch SSH-Schlüssel, Notizen, Projektdateien, Datenbanken, Compose-Dateien und die Konfiguration eines kleinen Servers. Wer nur das Home-Verzeichnis sichert, rettet viel – aber nicht zwingend die Arbeit, die das System wieder benutzbar macht.

Restic ist ein freies Kommandozeilenprogramm für Backups. Es legt Daten in einem Repository ab, verschlüsselt sie clientseitig und speichert gleiche Datenblöcke nicht endlos neu. Das spart Platz, ersetzt aber keine Planung. Ein Backup auf derselben SSD schützt weder gegen Diebstahl noch gegen einen Controller-Schaden. Hand aufs Herz: Eine Kopie neben dem Original ist keine Rückfallebene, sondern Bequemlichkeit mit gutem Gewissen.

Für den Einstieg reichen drei getrennte Ebenen: die Arbeitsdaten auf dem Rechner, ein lokales Repository auf einem externen Datenträger und eine zweite Kopie außerhalb der Wohnung oder des Büros. Das kann ein Storage-Server, ein S3-kompatibler Speicher oder ein per SFTP erreichbares Ziel sein. Die offizielle Restic-Anleitung zum neuen Repository beschreibt die Grundidee ohne Marketingnebel: Erst Speicherziel und Passwort klären, dann initialisieren.

Wir bei digital-magazin.de sehen oft das gleiche Muster: Ein Backup läuft monatelang durch, weil ein Cronjob grün aussieht. Erst beim Restore fällt auf, dass das Passwort nicht dokumentiert, der Zielpfad nicht erreichbar oder die wichtige Datenbank gar nicht enthalten ist. Der Restore ist der Test. Alles davor ist eine Vermutung.

Restic Backup einrichten: Repository, Passwort, erster Lauf

Installieren Sie Restic über die Paketverwaltung Ihrer Distribution oder über das Projekt-Release. Für Debian und Ubuntu genügt häufig sudo apt install restic; bei anderen Distributionen unterscheiden sich Paketname und Aktualität. Prüfen Sie anschließend mit restic version, ob das Programm wirklich im Pfad liegt. Für eine produktive Maschine würde ich nicht blind ein Paket aus einem uralten Spiegel verwenden. Ein Blick in die Release-Hinweise kostet weniger Zeit als eine spätere Repository-Migration.

Als lokales Testziel eignet sich ein eingebundener Datenträger, etwa /mnt/backup/restic. Initialisieren Sie das Repository mit:

export RESTIC_REPOSITORY=/mnt/backup/restic
restic init

Restic fragt nach einem Repository-Passwort. Dieses Passwort ist kein Detail für die Passwortliste „später sortieren“. Ohne es kommen Sie an die verschlüsselten Daten nicht heran. Legen Sie es in einem Passwortmanager ab und sorgen Sie dafür, dass eine zweite vertrauenswürdige Person im Notfall weiß, wo die Zugangsinformation liegt. Die Passwortdatei unverschlüsselt neben das Repository zu legen, wäre ungefähr so elegant wie den Hausschlüssel mit Klebeband an die Tür zu hängen.

Der erste Lauf darf klein sein. Sichern Sie zunächst einen überschaubaren Ordner und beobachten Sie die Ausgabe:

restic backup ~/Dokumente
restic snapshots

Die Liste der Snapshots ist Ihre erste Plausibilitätskontrolle. Sie zeigt Zeitpunkt, Host und gesicherte Pfade. Danach erweitern Sie den Umfang gezielt. Auf einem Desktop können das /home, eine Liste wichtiger Konfigurationsordner und Export-Dateien sein. Auf einem Server gehören Datenbank-Dumps und persistent gemountete Volumes auf die Liste; ein laufendes Datenbankverzeichnis kopiert man nicht einfach mitten im Schreibvorgang. PostgreSQL, MariaDB und ähnliche Systeme liefern dafür eigene Dump-Mechanismen.

Ein häufiger Fehler ist ein zu großzügiger Befehl wie sudo restic backup /. Damit landen schnell Pseudo-Dateisysteme, Caches, temporäre Daten und Mounts im Repository. Klüger ist eine explizite Auswahl. Ausschlüsse lassen sich in einer Datei pflegen; die Dokumentation zum Backup-Befehl erklärt die Muster und Optionen genauer. Für eine lesbare Konfiguration ist das Gold wert.

Die 7 Prüfungen, die ein Linux-Backup belastbar machen

1. Das Ziel ist nicht der Quellrechner. Ein externes Laufwerk ist ein Anfang, aber bei Feuer, Diebstahl oder Verschlüsselungstrojanern oft am falschen Ort. Trennen Sie das Medium nach dem Lauf oder sichern Sie zusätzlich an einen anderen Standort.

2. Der Umfang ist dokumentiert. Schreiben Sie nicht nur „Home sichern“ in ein Wiki. Listen Sie konkret auf: welche Verzeichnisse, welche Datenbank-Dumps, welche geheimen Konfigurationsdateien, welche Ausschlüsse. Sonst rätselt im Ernstfall jemand, ob ~/Projekte oder /srv überhaupt Teil des Plans war.

3. Geheimnisse werden bewusst behandelt. SSH- und GPG-Schlüssel, Tokens und Passwortdateien brauchen ein Backup, aber keinen Platz in einem ungeschützten Script. Setzen Sie Rechte restriktiv und halten Sie die Zugangsdaten zum Speicherziel getrennt vom Rechner fest.

4. Aufbewahrung ist definiert. Ohne Regeln wachsen Snapshots still vor sich hin. Eine brauchbare Rotation kann beispielsweise sieben tägliche, vier wöchentliche und zwölf monatliche Stände behalten. Der dazu passende Restic-Aufruf sieht so aus:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Das ist kein magischer Standard für jede Umgebung. Wer Abrechnungen, Forschungsdaten oder Kundenprojekte verwaltet, braucht möglicherweise längere Fristen und rechtliche Vorgaben. Der Knackpunkt: Die Regel muss absichtlich gewählt sein, nicht zufällig aus einem Blog kopiert.

5. Integrität wird geprüft.restic check untersucht das Repository und sollte fest im Wartungsplan stehen. Bei großen Beständen kann eine vollständige Prüfung dauern; trotzdem ist sie wesentlich besser als das tägliche Schulterklopfen für einen Prozess, dessen Daten niemand kontrolliert hat.

6. Wiederherstellung wird geübt. Wählen Sie eine Testdatei, löschen Sie sie nicht einmal nur symbolisch, und stellen Sie sie in ein separates Ziel wieder her. Beispiel:

mkdir -p /tmp/restic-restore-test
restic restore latest --target /tmp/restic-restore-test

Öffnen Sie danach die Datei. Stimmen Inhalt, Dateinamen und Zugriffsrechte? Wiederholen Sie den Test bei einer Datenbank mit einem Dump und einem echten Import in eine isolierte Instanz. Dieser Schritt wirkt pedantisch, bis er es nicht mehr ist.

7. Der Lauf wird überwacht. Ein Timer oder Cronjob ohne Benachrichtigung ist ein Briefkasten, in den niemand schaut. Lassen Sie den Job bei Fehlern E-Mail, Matrix, Slack oder einen anderen verlässlichen Kanal nutzen. Wer ohnehin Dienste containerisiert, kann außerdem die Sicherung der Volumes in den Deployment-Ablauf einbauen. Bei einem ungewöhnlichen Treiber-Sprung im Linux-Umfeld geht die Betriebsroutine gern verloren; beim Backup darf das nicht passieren.

Restic Backup für Projekte, Code und Konfiguration

Entwicklungsarbeit hat eine eigene Fehlerklasse: Das Repository liegt bei GitHub oder GitLab, also fühlt sich alles sicher an – während lokale Schlüssel, .env-Dateien, Datenbank-Dumps, uncommittete Notizen und Build-Artefakte trotzdem nur auf einem Rechner wohnen. Git ist kein vollständiges Backup. Es schützt die Historie dessen, was bewusst committed und gepusht wurde. Restic kann die Lücke schließen, ohne die Versionsverwaltung zu ersetzen.

Prüfen Sie bei Projektordnern außerdem, welche Dateien wirklich gesichert werden müssen. Große Abhängigkeitsordner lassen sich oft reproduzieren; Zugangsdaten und lokale Migrationsdaten nicht. Wer Code automatisiert prüft, kennt das Dilemma aus gestapelten Pull Requests und ihren vielen Zwischenständen: Nicht jeder Stand gehört dauerhaft ins Archiv, aber der falsche fehlende Stand kann teuer werden. Eine einfache Include-/Exclude-Liste schafft hier mehr Klarheit als eine pauschale Vollsicherung.

Auch das Repository selbst verdient eine nüchterne Sicherheitsbetrachtung. Verschlüsselung schützt den Inhalt auf dem Speicherziel, sie schützt jedoch nicht vor einem verlorenen Passwort oder vor einem Konto, das gleichzeitig Quelle und Ziel kontrolliert. Gerade bei freier Software und Automatisierung ist die Versuchung groß, alles mit demselben SSH-Schlüssel zu lösen. Besser sind getrennte, auf das Backup-Ziel begrenzte Zugangsdaten. Der Gedanke hinter klaren Regeln für automatisierte Entwicklungsarbeit passt auch hier: Was im Hintergrund läuft, braucht nachvollziehbare Grenzen.

Automatisierung ohne Passwort-Zirkus

Wenn Restic interaktiv nach dem Passwort fragt, kann ein geplanter Lauf nicht unbeaufsichtigt funktionieren. Die Umgebungsvariable RESTIC_PASSWORD_FILE verweist auf eine Datei mit restriktiven Rechten. Das ist praktikabel, verlangt aber Disziplin: Die Datei gehört nicht in ein Git-Repository, nicht in ein öffentlich lesbares Home-Verzeichnis und nicht in ein Support-Screenshot.

Ein minimalistisches Script kann Repository, Passwortdatei und die gewünschten Pfade setzen, danach backup, forget --prune und in größeren Abständen check ausführen. Verwenden Sie absolute Pfade. Cron startet mit einer anderen Umgebung, als sie Ihr Terminal bequem mitliefert. Genau an dieser Stelle entstehen die kleinen Terminal-Momente, bei denen man kurz bereut, die Dokumentation nur überflogen zu haben.

Für systemd bietet sich ein Service plus Timer an. Der Service führt den Backup-Befehl aus, der Timer bestimmt den Rhythmus, und systemctl list-timers macht die Planung sichtbar. Das ist für viele Systeme angenehmer als eine lange Crontab, weil Logs und fehlgeschlagene Läufe direkt über journalctl auffindbar sind. Wer ohnehin mit Linux-Servern arbeitet, sollte sich auch mit einer klaren Update- und Rollback-Routine beschäftigen – gerade bei Werkzeugen, die täglich im Hintergrund laufen.

Für entfernte Ziele hängt Restic nicht an einem einzigen Anbieter. SFTP, Rest-Server und verschiedene Object-Stores sind möglich. Wenn Sie Dateien zunächst in einen anderen Speicher spiegeln möchten, kann die Rclone-Dokumentation bei der Wahl und Anbindung eines Speichers helfen. Trotzdem würde ich nicht zwei komplizierte Werkzeuge zusammenstecken, nur weil es technisch geht. Ein simples, getestetes Restic-Repository schlägt einen kunstvollen Workflow, den niemand nach drei Monaten noch versteht.

Was bei Restic Backup typischerweise schiefgeht

Erstens: Das Repository ist erreichbar, aber voll. Beobachten Sie Speicherverbrauch und Fehlermeldungen; eine abgebrochene Aufbewahrungsbereinigung kann den freien Platz schneller auffressen, als man denkt. Zweitens: Der Zielserver ist mit denselben Zugangsdaten wie der Quellrechner zugänglich. Wird der Rechner kompromittiert, kann ein Angreifender unter Umständen auch Backups löschen. Versionierung, getrennte Credentials oder ein Ziel mit Unveränderbarkeitsoptionen verdienen deshalb eine konkrete Prüfung.

Drittens: Es werden nur Dateien, nicht aber die Wiederanlauf-Schritte gesichert. Ein Notfall-Dokument sollte erklären, welches System wiederhergestellt wird, wo das Repository liegt, welches Werkzeug nötig ist und welche Reihenfolge gilt. Kein Roman. Eine Seite kann reichen. Doch diese Seite spart nach einem Ausfall mehr Nerven als jede hochtrabende Architekturzeichnung.

Viertens: Das Backup wird zum Glaubenssatz. „Es lief doch gestern“ ist keine Aussage über die Qualität der Daten. Nach unserer Recherche bei digital-magazin.de trennt sich hier Routine von Resilienz: Wer stichprobenartig wiederherstellt, erkennt Probleme, solange sie noch langweilig sind.

Und jetzt? Ein kleiner Restore-Test schlägt große Versprechen

Fangen Sie diese Woche mit einem Ordner an. Initialisieren Sie ein Repository auf einem getrennten Ziel, sichern Sie ein paar wirklich wichtige Dateien und stellen Sie eine davon in ein Testverzeichnis wieder her. Erst wenn dieser Ablauf sitzt, bauen Sie Automatisierung, Rotation und ein zweites Ziel dazu. Das klingt fast zu bodenständig für ein Thema, das gern mit Cloud-Speicher und „Disaster Recovery“ dekoriert wird. Ist aber die Wahrheit: Ein Backup ist erst dann gut, wenn Sie es ohne Drama zurückholen können.