Backups vor Ransomware schützen¶
Veröffentlicht am 16. September 2026 · Geschätzte Lesezeit: 10 Minuten
Ein normales Backup reicht gegen Ransomware nicht aus, wenn Schadsoftware oder ein kompromittiertes Administratorkonto auch die Sicherung löschen kann. Hier baust du deshalb eine verschlüsselte, versionierte restic-Sicherung auf einem nur kurz verbundenen USB-Datenträger auf und ergänzt sie um getrennte Zugangsdaten sowie eine unveränderliche oder zweite räumlich getrennte Kopie. Plane für die Einrichtung 45 bis 90 Minuten, für den ersten Lauf abhängig von der Datenmenge und für den Restore-Test weitere 15 bis 30 Minuten ein. Grundlage dieser Anleitung sind die Security Guidelines for Storage Infrastructure des NIST.[4]
Voraussetzungen
- Ein Debian- oder Ubuntu-Server mit
sudo-Zugriff und installiertem USB-Anschluss - Ein leerer oder bereits passend vorbereiteter USB-Datenträger mit genügend freiem Speicher
- Ein klar festgelegter Quellordner, zum Beispiel ein Docker-Projektordner unter
/srv/docker - Ein Passwortmanager für das restic-Passwort und eine unkritische Testdatei
1. Schutzmodell und Datenumfang festlegen¶
Notiere zuerst, welche Daten wirklich wiederherstellbar sein müssen. Zu einem Docker-Projekt gehören neben Compose-Dateien auch Konfigurationen, Bind-Mounts und anwendungskonsistente Datenbankexporte. Laufende Datenbankdateien solltest du nicht ungeprüft kopieren, sondern den Dienst kurz stoppen oder den vorgesehenen Exportweg der Anwendung verwenden.
Plane mindestens diese Ebenen:
- Originaldaten auf Server, NAS oder Computer
- versionierte Sicherung auf einem externen Datenträger
- eine weitere Kopie außer Haus
- mindestens eine Kopie, die offline oder durch eine echte Aufbewahrungssperre unveränderlich ist
- ein dokumentierter und regelmäßig getesteter Rückweg
NIST empfiehlt für die Wiederherstellung nach Cyberangriffen isolierte Kopien, getrennte Verwaltungswege, eigene Zugangsdaten, eine externe Aufbewahrung und bei Bedarf Air-Gap oder unveränderlichen Speicher.[4] Eine Synchronisation allein erfüllt das nicht: Sie kann verschlüsselte oder gelöschte Dateien ebenfalls zum Ziel übertragen.
Prüfe den Umfang des Quellordners. Ersetze <QUELLPFAD> durch den vollständigen Pfad deiner zu sichernden Daten:
Der Befehl verändert nichts und zeigt die derzeit belegte Datenmenge. Rechne zusätzlich Platz für mehrere historische Stände ein.
Erreichbar bedeutet angreifbar
Ein dauerhaft eingebundenes USB-Laufwerk oder eine ständig beschreibbare NAS-Freigabe ist keine Offline-Kopie. Wer den Server mit ausreichenden Rechten übernimmt, kann eine erreichbare Sicherung ebenfalls löschen oder verschlüsseln.
2. restic installieren und Version prüfen¶
Aktualisiere auf Debian oder Ubuntu die Paketinformationen:
Installiere restic:
Prüfe anschließend, ob das Programm aufrufbar ist:
Verwende auf anderen Linux-Systemen die Paketverwaltung des Herstellers. Die aktuelle restic-Dokumentation beschreibt versionierte Snapshots und Wiederherstellungen mit denselben Grundbefehlen.[1][2]
3. Offline-Datenträger eindeutig erkennen¶
Schließe den vorbereiteten USB-Datenträger an und zeige Dateisysteme, Labels, UUIDs und Einhängepunkte an:
lsblk liest Informationen über vorhandene Blockgeräte und zeigt mit --fs die Dateisystemdaten an.[11] Notiere die UUID der richtigen Partition. Prüfe Größe und Label sorgfältig, damit du nicht versehentlich die Systemplatte auswählst.
Erstelle einen festen Einhängepunkt:
Hänge die vorhandene Partition über ihre UUID ein. Ersetze <DATENTRAEGER-UUID> durch die zuvor abgelesene UUID:
UUIDs sind für die Zuordnung robuster als wechselnde Gerätenamen wie /dev/sdb1; mount verbindet das Dateisystem mit dem angegebenen Verzeichnis.[9]
Prüfe das Ergebnis:
Die Ausgabe muss genau den erwarteten Datenträger und den Einhängepunkt /mnt/offline-backup zeigen.
Nicht formatieren, wenn Daten vorhanden sind
Diese Anleitung formatiert keinen Datenträger. Wenn lsblk --fs kein geeignetes Dateisystem zeigt, sichere vorhandene Daten zuerst und richte den Datenträger separat ein. Ein falscher Formatierungsbefehl würde Daten dauerhaft löschen.
4. Verschlüsseltes Repository initialisieren¶
Erstelle auf dem eingehängten Datenträger einen geschützten Repository-Ordner:
Initialisiere das Repository genau einmal:
restic fragt das neue Repository-Passwort zweimal verdeckt ab. Ohne gültiges Passwort sind die verschlüsselten Daten nicht wiederherstellbar.[8]
Passwort und Datenträger getrennt verwahren
Speichere das lange, zufällige Repository-Passwort im Passwortmanager und zusätzlich in einer geschützten Notfallkopie. Lege diese Notfallkopie nicht ausschließlich auf denselben USB-Datenträger. Schreibe das Passwort weder in diesen Befehl noch in ein Git-Repository, eine Compose-Datei oder einen Screenshot.
Die Verschlüsselung schützt die Vertraulichkeit bei Verlust des Datenträgers. Sie verhindert aber nicht, dass ein Angreifer das gesamte erreichbare Repository löscht. Dafür brauchst du die physische Trennung aus Schritt 8 oder eine vom Speicher erzwungene Unveränderlichkeit aus Schritt 9.
5. Erstes versioniertes Backup erstellen¶
Lege im Quellordner eine unkritische Testdatei mit eindeutigem Inhalt an. Ersetze <QUELLPFAD> wieder durch den vollständigen Quellpfad:
Erstelle nun den ersten Snapshot:
restic liest den Quellordner, speichert neue Datenblöcke und legt einen eindeutig auswählbaren Snapshot an.[1] <QUELLPFAD> steht weiterhin für den in Schritt 1 geprüften vollständigen Quellordner. Der feste Tag ransomware-schutz erleichtert später die Auswahl dieser Sicherungsreihe.
Ein erfolgreicher Lauf endet mit einer gespeicherten Snapshot-ID. Prüfe Fehlermeldungen trotzdem vollständig. Bei aktiven Datenbanken ist ein technisch erfolgreicher Dateikopiervorgang noch kein Beweis für einen konsistenten Datenbestand.
6. Snapshots und Repository prüfen¶
Zeige nur die Snapshots dieser Sicherungsreihe an:
Kontrolliere Datum, Host, Tag und Quellpfad. Mehrere Snapshots halten historische Stände vor, sodass nicht nur der zuletzt verschlüsselte oder beschädigte Zustand vorhanden ist.[5]
Prüfe danach die interne Struktur:
restic check kontrolliert die Konsistenz des Repositorys. Eine aktuelle Praxisanleitung für ein Ransomware-Recovery-Labor kombiniert ebenfalls getrennte beziehungsweise offline gelagerte Kopien mit Repository-Prüfungen und echten Restore-Tests.[7]
Prüfung ist noch keine Wiederherstellung
Ein fehlerfreies restic check ist wichtig, ersetzt aber keinen Restore-Test. NIST empfiehlt regelmäßige Testwiederherstellungen und eine Kontrolle, ob der Rückweg vollständig und rechtzeitig funktioniert.[4]
7. Rückweg mit einer Testdatei prüfen¶
Suche die Testdatei im Repository:
Notiere den vollständigen Pfad, den restic für die Datei im Snapshot ausgibt. Erstelle danach ein leeres Wiederherstellungsziel:
Stelle nur die Testdatei wieder her. Ersetze <PFAD-IM-SNAPSHOT> durch den vollständig von restic find ausgegebenen Pfad:
sudo restic -r /mnt/offline-backup/restic-repo restore latest --tag ransomware-schutz --include '<PFAD-IM-SNAPSHOT>' --target /tmp/restic-restore-test
Die restic-Dokumentation verlangt bei --include den Pfad in der Form, in der er im Snapshot liegt.[2] Vergleiche Original und wiederhergestellte Datei. Ersetze <QUELLPFAD> durch deinen Quellordner und <PFAD-IM-SNAPSHOT> erneut durch den vollständigen Snapshot-Pfad:
Beide SHA-256-Werte müssen exakt übereinstimmen. Öffne die wiederhergestellte Datei zusätzlich und kontrolliere ihren Inhalt. Entferne danach ausschließlich den temporären Testordner:
Lösche die Testdatei im Original erst, wenn mindestens ein weiterer regulärer Snapshot vorhanden ist. Für eine echte Wiederherstellung arbeitest du ebenfalls zuerst in einem leeren Zielordner und ersetzt produktive Daten erst nach der Prüfung.
8. Datenträger sauber trennen und getrennt lagern¶
Beende alle Shells, Dateimanager und Prozesse, die auf /mnt/offline-backup zugreifen. Hänge den Datenträger dann sauber aus:
umount trennt das Dateisystem vom Einhängepunkt.[10] Kontrolliere anschließend, dass dort nichts mehr eingehängt ist:
Keine Ausgabe und ein entsprechender Rückgabefehler bedeuten, dass der Einhängepunkt nicht mehr belegt ist. Ziehe den USB-Datenträger erst danach ab.
Lagere ihn so, dass er außerhalb des Backup-Zeitfensters weder physisch noch über das Netzwerk erreichbar ist. Eine zweite Wechselplatte an einem anderen Ort schützt zusätzlich vor Diebstahl, Brand und Defekt. NIST empfiehlt für Cyber-Recovery-Kopien eine Trennung von Produktionssystemen, eine externe Aufbewahrung und bei sensiblen Daten die Prüfung eines Air-Gaps.[4]
Offline-Rotation nicht gleichzeitig anschließen
Verbinde bei einer Rotation nie beide Offline-Datenträger gleichzeitig mit dem möglicherweise kompromittierten Server. Prüfe zuerst den Server, sichere dann auf genau einen Datenträger und trenne ihn wieder sauber.
9. Getrennte Konten und echte Unveränderlichkeit ergänzen¶
Für ein NAS, einen Backup-Server oder einen Objektspeicher verwendest du ein eigenes Backup-Konto mit eigenem Passwort. Dieses Konto darf nur das vorgesehene Repository erreichen und soll keine allgemeinen Server-, NAS- oder Cloud-Administrationsrechte besitzen. NIST empfiehlt getrennte Rollen für Datenverwaltung und Backup-Löschung sowie eigene Konten und Zugangsdaten für Recovery-Kopien.[4]
Eine unveränderliche Kopie muss vom Zielsystem selbst erzwungen werden, zum Beispiel durch:
- Object Lock oder WORM mit festgelegter Aufbewahrungszeit
- eine unveränderliche Snapshot- oder Vault-Sperre
- ein Ziel, auf dem der schreibende Backup-Client vorhandene Stände weder ändern noch löschen darf
Teste die Funktion vor dem produktiven Einsatz mit einem Test-Repository: Erstelle einen Stand, aktiviere die Retention nach Herstelleranleitung und versuche anschließend mit den normalen Backup-Zugangsdaten, ihn vor Ablauf zu löschen. Die Löschung muss scheitern. NIST nennt Retention Lock, Vault Lock und Immutability Policies ausdrücklich als zusätzliche Schutzmöglichkeiten.[4]
Versionierung ist nicht automatisch unveränderlich
Wenn dasselbe Administratorkonto Versionen, Retention und Speicherziel löschen kann, ist die Kopie trotz eingeschalteter Versionierung nicht zuverlässig unveränderlich. Ein Online-Ziel mit Object Lock ersetzt außerdem keine physisch getrennte Kopie gegen Hardwaredefekt, Kontosperre oder Fehlkonfiguration.
10. Aufbewahrung und regelmäßigen Prüfrhythmus festlegen¶
Bewahre mehrere Zeitstände auf. Diese Beispielregel zeigt zunächst nur, welche Snapshots erhalten blieben. Sie löscht wegen --dry-run noch nichts:
sudo restic -r /mnt/offline-backup/restic-repo forget --tag ransomware-schutz --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --dry-run
Die Werte bedeuten bis zu 7 tägliche, 4 wöchentliche und 12 monatliche Stände innerhalb der von restic gebildeten Snapshot-Gruppen. Passe sie an Datenmenge, verfügbaren Speicher und den maximal tolerierbaren Datenverlust an.
Führe eine echte Bereinigung erst aus, wenn mehrere geprüfte Backups und mindestens eine weitere unabhängige Kopie vorhanden sind:
sudo restic -r /mnt/offline-backup/restic-repo forget --tag ransomware-schutz --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
forget entfernt nicht mehr aufzubewahrende Snapshots; --prune entfernt anschließend nicht mehr referenzierte Daten. Pruning kann lange dauern, sperrt das Repository und sollte von einem erneuten restic check gefolgt werden.[3]
Ein sinnvoller Heimserver-Rhythmus ist beispielsweise: regelmäßig versioniert sichern, nach jedem Lauf die Abschlussmeldung prüfen, den Offline-Datenträger sofort trennen und mindestens vierteljährlich eine echte Datei zurückholen. Der öffentlich erreichbare Vortrag „restic – Backups mal richtig“ zeigt das Grundprinzip von Backup, Prüfung und Wiederherstellung; verwende für konkrete Befehle trotzdem die aktuelle Dokumentation.[6]
Backup, Rückweg und Sicherheitsrisiken¶
Die neue USB-Sicherung ist eine zusätzliche Kopie und kein Grund, Originaldaten oder andere Sicherungen zu löschen. Für den vollständigen Rückweg installierst du restic auf einem sauberen Ersatzsystem, verbindest genau einen geprüften Datenträger, stellst zunächst in einen leeren Ordner wieder her und kontrollierst Inhalt sowie Prüfsummen. Erst danach übernimmst du Daten in das Produktivsystem.
Wichtige Restrisiken bleiben:
- Ein verlorenes restic-Passwort macht das verschlüsselte Repository unzugänglich.[8]
- Ein während eines Angriffs angeschlossener Datenträger kann gelöscht oder beschädigt werden.
- Ein einzelner USB-Datenträger kann ausfallen, verloren gehen oder bei einem lokalen Schaden zerstört werden.
- Eine unveränderliche Kopie kann bereits verschlüsselte oder manipulierte Quelldaten enthalten, wenn der Angriff vor dem Backup unbemerkt blieb.
- Eine Sicherung aktiver Datenbanken kann inkonsistent sein, obwohl restic keine Lesefehler meldet.
- Zu kurze Aufbewahrung kann den letzten sauberen Stand entfernen.
Typische Fehler beheben¶
repository does not exist: Prüfe mitfindmnt --target /mnt/offline-backup, ob der richtige Datenträger eingehängt ist. Initialisiere nicht vorschnell ein neues Repository im leeren Mountpunkt.wrong password or no key found: Prüfe Tastaturlayout und den richtigen Eintrag im Passwortmanager. Ändere oder lösche keine Repository-Dateien.device is busybeim Aushängen: Beende Shells und Programme, die auf den Einhängepunkt zugreifen. Erzwinge das Aushängen nicht, solange noch geschrieben wird.- Testdatei wird nicht gefunden: Kontrolliere den gesicherten Quellpfad mit
restic snapshotsund suche erneut mitrestic find backup-test.txt. - Prüfsummen unterscheiden sich: Verwende die Sicherung nicht als bestätigt. Prüfe Snapshot, Pfad und Repository mit
restic checkund wiederhole den Restore in einen leeren Ordner. - Backup ist unerwartet klein: Kontrolliere
<QUELLPFAD>, Dateirechte, Ausschlüsse und anwendungsspezifische Datenbankexporte. - Offline-Platte bleibt angeschlossen: Behandle den Lauf als noch nicht ransomwaregeschützt, hänge sie sauber aus und lagere sie getrennt.
Fertig¶
Dein Schutz funktioniert, wenn restic snapshots --tag ransomware-schutz mehrere erwartete Stände zeigt, restic check ohne Fehler endet, Original und wiederhergestellte Testdatei dieselbe SHA-256-Prüfsumme besitzen und findmnt --target /mnt/offline-backup nach dem Aushängen keinen Mount mehr meldet. Vollständig wird das Konzept erst mit einer weiteren räumlich getrennten Kopie, getrennten Backup-Zugangsdaten und einer nachweislich getesteten Offline- oder unveränderlichen Aufbewahrung.
Sources¶
[1] https://restic.readthedocs.io/en/stable/040_backup.html [2] https://restic.readthedocs.io/en/stable/050_restore.html [3] https://restic.readthedocs.io/en/stable/060_forget.html [4] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-209.pdf [5] https://restic.readthedocs.io/en/stable/045_working_with_repos.html [6] https://media.ccc.de/v/c4.openchaos.2016.01.restic [7] https://nathanberg.io/posts/ransomware-recovery-lab-immutable-backups-restore [8] https://restic.readthedocs.io/en/stable/070_encryption.html [9] https://man7.org/linux/man-pages/man8/mount.8.html [10] https://man7.org/linux/man-pages/man8/umount.8.html [11] https://man7.org/linux/man-pages/man8/lsblk.8.html