Verschlüsselte Backups: Klappt die Wiederherstellung? (2026)

Zur Finanzierung (Stand September 2026): CypherpunkGuide schaltet keine Überwachungswerbung — keine Werbenetzwerke, Tracking-Pixel oder gesponserten Inhalte. Einige Artikel enthalten klar gekennzeichnete Affiliate-Links, über die wir eine Provision erhalten können. Dieser Artikel enthält keine Affiliate-Links und empfiehlt keinen Speicheranbieter.

Fotos, Briefe und persönliche Unterlagen sollen oft länger erhalten bleiben als der Computer, auf dem sie entstanden sind. Eine verschlüsselte Sicherung schützt ihre Vertraulichkeit. Ob du sie später wieder nutzen kannst, hängt außerdem davon ab, ob du an das Backup kommst, es entsperren kannst, die passende gespeicherte Version findest und die Dateien öffnen kannst.

Für diesen Artikel habe ich einen Wiederherstellungsversuch mit 12 künstlichen Dateien und sechs Testfällen entworfen. Zum Einsatz kam restic, ein quelloffenes Programm für verschlüsselte Backups. In einem Fall liefen die Prüfung des Backup-Speichers, die vollständige Datenprüfung und die Wiederherstellung erfolgreich durch. Zurück kamen trotzdem nur 11 der 12 vorgesehenen Dateien. In einem anderen Fall waren alle Dateien vorhanden und bestanden die Formatprüfung. Eine davon enthielt jedoch einen älteren Stand.

Entscheidend ist deshalb ein konkretes Ergebnis: Bekommst du die Unterlagen zurück, die du behalten wolltest — in der benötigten Version und in nutzbarer Form? Die folgenden Prüfungen verbinden einen persönlichen Sicherungsplan mit einem nachvollziehbaren Experiment und einer vorsichtigen Wiederherstellungsprobe. Der Versuch verwendet ausschließlich erzeugte Testdateien. Er misst weder die Lebensdauer von Laufwerken noch den Schutz durch räumlich getrennte Kopien oder die Wiederherstellung eines ganzen Computers.

Synchronisation, Backup und Langzeitarchivierung unterscheiden

#

Synchronisation gleicht Arbeitskopien ab. Ein Backup hält Kopien zur Wiederherstellung bereit. Langzeitarchivierung erhält darüber hinaus Bedeutung und Lesbarkeit, wenn Geräte und Software wechseln. Ein Dienst kann mehrere dieser Aufgaben übernehmen; prüfen musst du sie einzeln.

Wenn ein Synchronisationsdienst eine Löschung auf andere Geräte überträgt, kann er genau wie vorgesehen arbeiten. Ob sich die Datei noch zurückholen lässt, bestimmen unter anderem die aufbewahrten Versionen, die Löschregeln und der Zugang zum Konto. Eine abgetrennte Festplatte kann umgekehrt eine wertvolle Kopie enthalten, auf der alle seit dem Abtrennen entstandenen Dateien fehlen. Kläre zuerst, welche Aufgabe die Kopie erfüllen soll.

Die US-Behörde für Cybersicherheit und Infrastrukturschutz, CISA, beschreibt die 3-2-1-Regel so: insgesamt drei Kopien auf zwei unterschiedlichen Medientypen, davon eine an einem anderen Ort. Ihr Ransomware-Leitfaden empfiehlt außerdem verschlüsselte Offline-Backups sowie regelmäßige Prüfungen von Unversehrtheit und Wiederherstellung. „An einem anderen Ort“ beschreibt den Standort; „offline“ beschreibt die Verbindung. Kann dasselbe kompromittierte Konto auch die entfernte Kopie löschen, ist diese durch das andere Gebäude allein noch nicht unabhängig geschützt. Die Grundlagen stehen in den CISA-Hinweisen zu Backups und im Ransomware-Leitfaden.

Halte für dein persönliches Archiv konkrete Ausfälle fest: ein gestohlener Laptop, eine versehentliche Löschung, ein Wohnungsbrand, ein gesperrtes Konto oder verlorene Informationen zum Entsperren. Welche Kopie könntest du danach noch verwenden? Dieselbe Frage leitet einen persönlichen Plan zum Schutz der Privatsphäre: Gegen welchen Ausfall soll jede einzelne Maßnahme helfen?

Einen Wiederherstellungsweg außerhalb des ausgefallenen Systems behalten

#

Verschlüsselung schützt den Inhalt eines Backups vor Personen, die es nicht entsperren können. Sie bewahrt jedoch weder das Passwort auf noch hält sie ein Konto zugänglich oder alle Kopien verfügbar. Diese Voraussetzungen brauchen jeweils eine eigene Lösung.

Notiere, wo das Backup liegt, welches Programm und Format es verwendet und gegebenenfalls, wie sich der Kontozugang wiederherstellen lässt. Halte außerdem fest, wie eine berechtigte Person an die Informationen zum Entsperren kommt. Schütze die Zugangsdaten. Veröffentliche sie nicht in einer Checkliste und übermittle sie nicht an einen Chatbot. Ein Verweis wie „Die Wiederherstellungsanleitung liegt im versiegelten Umschlag“ hat einen anderen Zweck als die Offenlegung des Geheimnisses selbst.

Bei restic liegen die verschlüsselten Sicherungen in einem Repository, also einem von restic verwalteten Backup-Speicher. Der Zugriff erfolgt über passwortgeschützte Schlüssel. Ein Repository kann mehrere solcher Schlüssel haben. Ein vergessenes Passwort bedeutet deshalb nicht automatisch einen endgültigen Verlust, wenn noch ein anderer gültiger Schlüssel samt Passwort verfügbar ist. Anders liegt der Fall, wenn kein brauchbarer Weg zum Entsperren mehr bleibt. Die offizielle Dokumentation zur Erstellung eines Repositorys erläutert dieses Modell.

Vermeide gegenseitige Abhängigkeiten: Das einzige Exemplar des Backup-Passworts darf nicht nur im verschlüsselten Backup liegen. Ebenso wenig helfen Wiederherstellungsunterlagen für den Passwortmanager, wenn sie ausschließlich auf dem verlorenen Laptop gespeichert sind. Die Anleitungen zur Passkey-Wiederherstellung und zum Wechsel des Passwortmanagers behandeln dasselbe Zugangsproblem aus Sicht deiner Konten.

Wer einen Dienst selbst betreibt, übernimmt auch seine Wiederherstellung. Liegen ein selbst betriebener Dienst und sein einziges Backup auf demselben Rechner, reicht der Verlust dieses Rechners weiterhin aus.

Was die einzelnen Prüfungen tatsächlich belegen

#

Jede Backup-Prüfung beantwortet eine begrenzte Frage. Die Konsistenz des Repositorys, das Lesen gespeicherter Daten, die Vollständigkeit der gewünschten Dateien, identische Bytes und lesbare Formate sind unterschiedliche Prüfungen. Ein Erfolg bei einer davon ersetzt die anderen nicht.

Nach der am 3. September 2026 geprüften restic-Dokumentation unterscheiden sich check und check --read-data im Umfang. Die gewöhnliche Prüfung untersucht Struktur und Konsistenz des Repositorys. Dabei liest und überprüft sie nicht den gesamten Inhalt aller gespeicherten Packs. Ein Pack ist eine Datei, in der restic Backup-Daten zusammenfasst. Mit --read-data liest restic jedes Pack; das kann viel Zeit und Datenverkehr beanspruchen. Einzelheiten erläutert Working with repositories.

Ein Manifest ist eine Liste der erwarteten Dateien, gegebenenfalls ergänzt um Dateigrößen und Hashes. Ein kryptografischer Hash, etwa SHA-256, ist ein aus den Bytes einer Datei berechneter Wert, mit dem sich Veränderungen erkennen lassen. Erstelle eine geschützte Referenz aus den Dateien, die du tatsächlich erhalten möchtest. Eine Liste, die nur aus dem Backup selbst entsteht, kann keine Datei aufdecken, die nie darin gelandet ist. Auch Dateinamen können vertrauliche Informationen enthalten. Berücksichtige das Manifest daher in deinem Datenschutzplan.

Die Library of Congress, die US-amerikanische Kongressbibliothek, unterscheidet in ihrem Glossar zur digitalen Bestandserhaltung zwischen dem Erhalt der Bits und dem Erhalt des künftigen Zugangs. Ich habe dafür die archivierte Fassung vom September 2025 verwendet, weil die aktuelle Seite den Abruf bei dieser Prüfung blockierte. Diese Unterscheidung liegt auch dem Experiment zugrunde: Identische Bytes sind ein wertvoller Nachweis. Eine bereits fehlerhafte Datei lässt sich dennoch bytegenau kopieren.

Sechs Wiederherstellungsfälle mit künstlichen Dateien

#

Das Experiment trennt den Erfolg eines Befehls vom gewünschten Wiederherstellungsergebnis. Unter Windows mit restic 0.19.1 gelangen Repository-Prüfung, vollständige Datenprüfung und Wiederherstellung auch dann, wenn eine vorgesehene Datei fehlte oder eine alte Version ausgewählt war. Erst der Abgleich mit einer unabhängigen Referenz zeigte diese Abweichungen.

Ich habe den Testbestand angelegt, bevor eine Datei ausgeschlossen wurde. Er umfasst 12 Dateien in sieben Formatgruppen: UTF-8-Text, JSON, CSV, XML, ZIP, WAV und TOML. Dazu gehören künstliche Notizen, strukturierte Datensätze, ein Archiv und ein erzeugter Ton. Die Leseprogramme der Python-Standardbibliothek prüfen, ob sich die jeweiligen Formate verarbeiten lassen. Die Darstellung in einem Fotoprogramm, einer Office-Anwendung oder der Oberfläche eines Audioplayers wurde nicht getestet.

Jeder Fall verwendet eine festgelegte Snapshot-ID, also die Kennung eines gespeicherten Sicherungsstands, und einen neuen, leeren Zielordner. Das Protokoll erfasst die gewöhnliche Prüfung, die vollständige Datenprüfung, die Wiederherstellung, die erwarteten Pfade, die Hashes und die Formatprüfungen getrennt. Rückgabecode 0 bedeutet, dass der Befehl erfolgreich beendet wurde. Ein anderer Wert meldet einen Fehler dieses Befehls. Keiner dieser Werte ist eine Gesamtnote für ein persönliches Archiv.

Die sechs Fälle eignen sich als wiederholbare Übung, um ein Wiederherstellungsziel zu prüfen. Unterscheide bei jedem Fall zwischen einem erfolgreich abgeschlossenen Befehl und der Wiederherstellung der benötigten Dateien in der richtigen Version und in lesbaren Formaten. Der Ausschluss in S4 und die Auswahl des älteren Snapshots in S5 sind beabsichtigt; restic setzt diese Vorgaben korrekt um.

Ergebnisse

#

Bei Pfaden und Hashes beziehen sich die Zahlen auf die 12 vorgesehenen Dateien. Bei der Formatprüfung zählen nur die tatsächlich wiederhergestellten und geprüften Dateien. Für eine fehlende Datei gibt es keine wiederhergestellten Bytes, die ein Leseprogramm prüfen könnte. In S5 stammen die Vergleichshashes aus der unabhängig festgehaltenen benötigten aktuellen Version, nicht aus einer Liste des alten Snapshots. In S6 beschreibt die Referenz dagegen bewusst die bereits fehlerhafte Quelldatei. So bleiben bytegetreuer Erhalt und Lesbarkeit getrennte Fragen.

In S4–S6 werden alle drei restic-Befehle erfolgreich abgeschlossen: Die absichtlich ausgeschlossene Datei fehlt, die ausgewählte ältere Version wird wiederhergestellt und die bereits ungültige JSON-Datei wird unverändert kopiert. Die Abbildung ist englisch beschriftet; Anzahlen und Bezugsgrößen stehen in der Tabelle darüber.

Die Abbildung gibt es als SVG und PNG, dazu den Quellcode zur Erstellung.

Was die Abweichungen bedeuten

#

S2 prüft den Zugriff mit einem falschen Testpasswort. Der Fall zeigt, dass dieses Testpasswort zurückgewiesen wurde. Er beweist nicht, dass eine Wiederherstellung mit einem anderen gültigen Schlüssel unmöglich wäre. Das veröffentlichte Passwort ist ausschließlich für künstliche Testdaten vorgesehen. Verwende es niemals für echte Backups.

S3 verändert gespeicherte Nutzdaten, während die umgebende Repository-Struktur erhalten bleibt. Die gewöhnliche Prüfung meldete Erfolg. Das vollständige Lesen der Daten und die Wiederherstellung erkannten den Fehler. Das Ergebnis gilt für genau diese gezielt erzeugte Beschädigung. Es bedeutet weder, dass die gewöhnliche Prüfung jede Beschädigung übersieht, noch, dass bei einem beschädigten echten Repository immer genau eine Datei verloren geht. Ich habe die Ergebnisse der einzelnen Befehle getrennt festgehalten, weil eine pauschale Kennzeichnung als „Backup fehlgeschlagen“ diesen Unterschied verdecken würde.

S4 enthält einen Fehler bei der Dateiauswahl. Das Programm hat die ausgewählten Dateien erfolgreich gesichert. Zur unabhängig erstellten Soll-Liste gehörte aber auch documents/contacts.csv; diese Datei wurde im Experiment absichtlich ausgeschlossen. Ein Programm kann nicht wissen, dass eine gültige Ausschlussregel deiner Absicht widerspricht. Prüfe deshalb die Auswahl- und Ausschlussregeln als Teil der Sicherung. Wie restic damit umgeht, erklärt die Dokumentation zum Erstellen von Backups.

S5 betrifft den gewählten Sicherungsstand. Die ältere documents/status.json war weiterhin gültiges JSON und wurde korrekt wiederhergestellt. Ihr Hash stimmte jedoch nicht mit der benötigten aktuellen Version überein. Weder die richtige Anzahl an Dateien noch bestandene Formatprüfungen belegen die Aktualität. Nach einer versehentlichen Löschung kann gerade ein älterer Snapshot richtig sein. Problematisch wird er dann, wenn er nicht zu deinem Wiederherstellungsziel passt.

S6 bewahrt fehlerhafte Ausgangsdaten unverändert. Das Experiment erzeugt vor dem Backup absichtlich ungültiges JSON in documents/records.json. Alle drei restic-Vorgänge gelingen, und die Hashes aller 12 wiederhergestellten Dateien stimmen mit den Referenzen der Quelldateien überein. Trotzdem weist das JSON-Leseprogramm diese Datei sowohl vor als auch nach der Sicherung zurück. Der Fehler liegt bereits in der Quelle; er ist nicht bei der Wiederherstellung entstanden. Die übrigen 11 Dateien bestehen die Formatprüfung.

Das begrenzte Experiment nachvollziehen

#

Das herunterladbare Versuchsskript akzeptiert ausschließlich die festgelegte offizielle ZIP-Datei von restic 0.19.1 für Windows amd64. Es prüft die Hashes des Archivs und der ausführbaren Datei, erzeugt eigene Testdateien und entbehrliche Repositorys und lehnt vorhandene Quell- oder Zielordner ab. Absichtlich beschädigt wird nur eine innerhalb des Versuchs erstellte Kopie. Dein echtes Backup-Repository kann dem Skript nicht übergeben werden.

Die Methodik und Grenzen, die Ergebnistabelle, die detaillierten Ergebnisse, die Manifeste der künstlichen Dateien und das bereinigte Befehlsprotokoll stehen ebenfalls zum Download bereit. Sie dokumentieren ausschließlich erzeugte Testdateien. Im Befehlsprotokoll wurden Angaben zum ausführenden Rechner und zu lokalen Speicherorten ersetzt; es ist kein unveränderter Terminalmitschnitt.

Lies das Skript und führe es mit Python 3.11 oder neuer in einem leeren, eigens für den Versuch angelegten Arbeitsordner aus. Lade zuvor die passende ZIP-Datei aus der offiziellen Veröffentlichung von restic 0.19.1 herunter und vergleiche sie mit den dort veröffentlichten Prüfsummen. Starte dann:

python restore-lab.py --restic-zip restic_0.19.1_windows_amd64.zip

Um einen neuen Versuchslauf mit dem veröffentlichten Protokoll zu vergleichen, speichere das Vergleichsskript und die veröffentlichten Ergebnisse im selben Arbeitsordner. Lass die heruntergeladene results.json unverändert; sie dient als Referenz. Führe restore-lab.py wie oben beschrieben aus. Ersetze anschließend c07-restore-lab-REPLACE-ME durch den Namen des Testordners, den das Programm ausgibt. Führe im Arbeitsordner folgenden Befehl aus:

python .\compare-results.py --results .\c07-restore-lab-REPLACE-ME\results.json

Mit --results gibst du das Protokoll des neuen Versuchslaufs an. Verglichen werden nur die aufgezeichneten Ergebnisse dieser sechs Fälle mit restic 0.19.1 unter Windows. Das Skript berechnet keine Datei-Hashes neu und beurteilt nicht die Sicherheit eines echten Backups. Übereinstimmende Ergebnisse allein belegen auch nicht, dass eine andere Person das Experiment unabhängig wiederholt hat. Einzelheiten stehen unter Methodik und Grenzen.

Der Testordner bleibt anschließend zur Prüfung erhalten. Der dokumentierte Lauf verwendete Python 3.12.10. Ein kleiner Dateibestand mit festgelegten Fehlern macht hier einzelne Mechanismen sichtbar. Daraus lässt sich weder eine Ausfallquote ableiten noch ein Vergleich von Backup-Produkten. Dateirechte, vollständige Betriebssysteme, Netzwerkausfälle, unabhängige Standorte, Hardware-Alterung und das gesamte Verhalten von Anwendungen wurden nicht untersucht.

Das eigene Backup vorsichtig wiederherstellen und prüfen

#

Verwende für die Probe einen neuen, leeren Zielordner. Prüfe das Ergebnis, bevor du Originale veränderst. Wähle den für dein Ziel passenden Sicherungsstand und vergleiche Dateien und Inhalte mit unabhängig erstellten Referenzen. Öffne repräsentative Dateien in ihren vorgesehenen Anwendungen. Eine kleine Stichprobe belegt nur das tatsächlich Geprüfte.

Die restic-Dokumentation zur Wiederherstellung warnt: Vorhandene Dateien werden standardmäßig überschrieben. Andere Programme haben eigene Regeln. Lies die Anleitung zu deiner installierten Version und kontrolliere den Zielordner vor dem Start. Ein Probeversuch gehört nicht in den Ordner mit deinen Arbeitsdokumenten.

1. Lege das Wiederherstellungsziel fest. Zum Beispiel: „Briefe und Fotos bis zum letzten abgeschlossenen Backup zurückholen“ oder „den Stand vor der gestrigen Löschung wiederherstellen“. Notiere die erwarteten Ordner und Zeiträume. Ist die Quelle noch vorhanden, erstelle die Soll-Liste unabhängig von der Backup-Auswahl und ordne sie der benötigten Version zu. Eine seit dem Backup veränderte Arbeitsdatei weicht von diesem Snapshot ab. Das allein weist noch nicht auf einen Schaden bei der Wiederherstellung hin.
2. Prüfe Zugang und freien Speicherplatz. Finde das Backup und einen gültigen Weg zum Entsperren. Verwende einen vertrauenswürdigen Computer sowie einen getrennten, leeren Zielordner mit genügend Platz. Wiederhergestellte Dateien können als unverschlüsselter Klartext vorliegen. Schütze den Zielordner und verhindere unbeabsichtigte Synchronisation oder Freigaben.
3. Wähle einen bestimmten Sicherungsstand. Halte seine Kennung und das relevante Datum fest. „Latest“ bezeichnet eine Auswahl nach Reihenfolge. Es belegt nicht, dass dieser Snapshot die erwarteten Änderungen enthält.
4. Führe die dokumentierten Prüfungen und die Wiederherstellung aus. Unterscheide eine kurze Strukturprüfung vom vollständigen Lesen der gespeicherten Daten. Prüfe Warnungen und Fehler, auch diejenigen des ursprünglichen Sicherungslaufs. Ein vorhandener Snapshot beweist nicht, dass jede Quelldatei gelesen werden konnte.
5. Vergleiche das Ergebnis mit deinem Ziel. Prüfe erwartete Pfade, ausgewählte Inhalte und Versionen sowie vertrauenswürdige Referenzhashes, soweit vorhanden. Öffne Dokumente, betrachte Fotos, spiele Aufnahmen ab und teste die Funktionen, die für diese Unterlagen wichtig sind. Notiere, was du geprüft hast und was offenbleibt.
6. Behalte nutzbare Kopien, bis die Prüfung abgeschlossen ist. Eine gelungene Probe rechtfertigt nicht, die einzige andere brauchbare Kopie zu löschen. Schütze die wiederhergestellten Testdateien oder entferne sie nach der Prüfung gemäß deinen Aufbewahrungsregeln. Verzichte bei ungeklärten Abweichungen auf destruktive Aufräumarbeiten.

Beginne mit einer begrenzten Auswahl, wenn Zeit oder Speicherplatz für eine vollständige Wiederherstellung fehlen. Notiere diese Grenze und erweitere den geprüften Bestand nach und nach. Ist die Quelle bereits verloren und gibt es keine unabhängige Soll-Liste, bleibt die Vollständigkeit unbekannt. Die Dateianzahl im verbliebenen Backup kann diese Frage nicht beantworten.

Neben dem Speicher auch die Lesbarkeit erhalten

#

Für eine langfristig nutzbare Sammlung musst du Medien, Anschlüsse, Leseprogramme, Formate und Wiederherstellungszugänge regelmäßig prüfen. Eine Lebensdauerangabe für ein Speichermaterial garantiert nicht, dass das gesamte Archiv während dieser Zeit wiederherstellbar bleibt.

Die Hinweise der Library of Congress zu persönlichen digitalen Unterlagen empfehlen, gespeicherte Dateien mindestens jährlich zu prüfen und alle fünf Jahre oder bei Bedarf auf neue Medien zu kopieren. Ihr Merkblatt zur Haltbarkeit digitaler Speichermedien erläutert die Unsicherheit solcher Lebensdauerschätzungen. Verstehe diese Zeitangaben als Wartungsplan. Sie versprechen nicht, dass ein Laufwerk bis zum nächsten Termin durchhält. Prüfe auch nach einem Umzug auf andere Speichermedien, einer Änderung des Entsperrverfahrens oder einem vermuteten Defekt.

Wähle ein Laufwerk nicht nach einer pauschalen Regel wie „Eine HDD hält X Jahre“ oder „Eine SSD hält Y Jahre“. Auch Verbatims Angabe zur Lebensdauer von M-DISC bezieht sich auf ein optisches Speicherprodukt. Sie garantiert nicht, dass künftig ein passendes Lesegerät, intakte Informationen zum Entsperren und lesbare Dateiformate verfügbar sind. Das US-Nationalarchiv beschreibt die unsichere Lebensdauer und die Lagerbedingungen von Videomedien, einschließlich optischer Discs. Aus diesen Einschränkungen folgt umgekehrt nicht, dass jede optische Disc ausfallen wird.

Wird ein Format oder eine Anwendung schwer nutzbar, erstelle eine dokumentierte Nutzungskopie und behalte das Original. Bei der Umwandlung eines komplexen Dokuments können Gestaltung oder Funktionen verloren gehen. Auch der Hash ändert sich, weil die Umwandlung die Bytes verändert. Prüfe daher, ob die für dich wichtigen Eigenschaften erhalten geblieben sind. Kennzeichne die neue Kopie und erstelle für sie eine eigene Referenz. Überschreibe das Original nicht, nur um den Ordner übersichtlicher zu machen.

Beim Vergleich der Testfälle habe ich neben jedem Befehlsergebnis die Soll-Liste, die benötigte Version und die Formatprüfungen festgehalten. Anhand dieser getrennten Angaben lässt sich entscheiden, was zu beheben ist: Bei einer fehlenden Datei muss die Auswahl geprüft werden, bei einem alten Stand die Versionswahl, bei bereits unlesbaren Quelldaten deren Erhaltung und Nutzbarkeit. Der Kauf einer weiteren Festplatte beantwortet diese Fragen für sich genommen nicht.

Häufige Fragen

#

Ist Cloud-Synchronisation ein Backup?

#

Sie kann einzelne Wiederherstellungsfunktionen bieten, wenn sie frühere Versionen und gelöschte Dateien ausreichend lange aufbewahrt. Prüfe diese Regeln und die Voraussetzungen zur Kontowiederherstellung. Synchronisation allein belegt nicht, dass sich eine unerwünschte Änderung, eine Löschung oder der Verlust des Kontozugangs rückgängig machen lässt.

Bedeutet ein erfolgreiches restic check, dass jede Datei sicher ist?

#

Nein. Die gewöhnliche Prüfung liest nicht den Inhalt jedes gespeicherten Packs. Auch eine vollständige Datenprüfung belegt noch nicht, dass alle vorgesehenen Dateien enthalten sind, dass du die benötigte Version ausgewählt hast oder dass Anwendungen die wiederhergestellten Dateien lesen können.

Kann ich ein verschlüsseltes Backup wiederherstellen, wenn ich sein Passwort vergessen habe?

#

Das hängt vom Programm und den verbliebenen Wegen zum Entsperren ab. Restic kann mehrere passwortgeschützte Schlüssel verwenden. Ein anderer gültiger Schlüssel samt Passwort kann weiterhin funktionieren. Gehe nicht davon aus, dass der Speicheranbieter dein Backup entschlüsseln kann. Ein zurückgewiesenes Passwort belegt auch nicht, dass alle Wiederherstellungswege verloren sind.

Wie oft sollte ich mein persönliches Archiv prüfen?

#

Die Library of Congress empfiehlt, gespeicherte Dateien mindestens einmal jährlich zu prüfen. Passe deinen Zeitplan daran an, wie oft sich wichtige Unterlagen ändern. Prüfe zusätzlich nach wesentlichen Änderungen an Speicher, Software oder Wiederherstellungszugang. Halte fest, ob du eine Stichprobe oder den ganzen Bestand untersucht hast. Weder ein Kalendereintrag noch eine kleine Stichprobe garantiert die weitere Wiederherstellbarkeit.

Welches Speichermedium erhält Dateien über Jahrzehnte?

#

Kein Medium macht unabhängige Kopien, Prüfungen und spätere Umzüge überflüssig. Berücksichtige neben dem Medium die Lagerbedingungen und die Verfügbarkeit passender Lesegeräte. Langfristiger Zugang hängt außerdem von Formaten, Software und den Informationen zum Entsperren ab. Behalte geprüfte Originale, wenn du neuere Nutzungskopien anlegst.

Quellen und Unterlagen zum Experiment

#

Die Primärquellen wurden am 3. September 2026 geprüft. Die Versuchsergebnisse gelten für die angegebene Laufzeitumgebung und die künstlichen Eingabedaten. Archivfassungen erhalten ältere Quellenstände und können von der aktuellen Fassung abweichen, auf der eine Aussage beruht.

Cora Aegis

Cora Aegis schreibt bei CypherpunkGuide über Privatsphäre und digitale Selbstbestimmung. Für diesen Artikel hat sie einen Wiederherstellungsversuch mit verschlüsselten Backups und künstlichen Dateien entworfen und ausgewertet. Die Ergebnisse hat sie mit der offiziellen restic-Dokumentation und Hinweisen zur digitalen Bestandserhaltung abgeglichen. Persönliche Backup-Daten wurden nicht verwendet.

Mehr über Cora Aegis ->