Wiederherstellung verschlüsselter Backups — nur künstliche Testdaten Beobachtet am: 2026-09-03 Was gemessen wurde ------------------ Der Versuch verwendet restic 0.19.1, Python 3.12.10 und Windows 11 amd64. Zwölf erzeugte Dateien decken UTF-8-Text, JSON, CSV, XML, ZIP, WAV und TOML ab. Es wurden keine persönlichen Dokumente, Fotos, Aufnahmen oder echten Zugangsdaten verwendet. Es handelt sich um einen lokalen Versuchsaufbau, nicht um einen Produktvergleich oder eine allgemeine Sicherheitsbewertung von Backup-Programmen. Die Entwicklungsläufe und der abschließend protokollierte Lauf ergaben dieselben sechs Ergebniszeilen. Sie sind keine voneinander unabhängigen Tests auf unterschiedlichen Rechnern. Das Repository verwendet Format 2. Die Komprimierung entspricht der restic-Voreinstellung (auto); der Cache ist deaktiviert. Nach jedem erfolgreichen Backup ermittelt das Skript die vollständige Snapshot-ID. Die Wiederherstellung verwendet diese feste ID und den künstlichen Unterordner /source, niemals die besondere Kennung "latest". Jeder Zielordner wird neu und leer innerhalb des neuen Versuchsordners angelegt. Zusätzlich ist --overwrite never gesetzt. Das Manifest mit allen zwölf vorgesehenen Dateien entsteht vor dem Dateiausschluss in S4. Das Manifest des in S5 benötigten aktuellen Stands wird erstellt, bevor die ältere Testfassung gespeichert wird. In S6 beschreibt das Manifest die absichtlich ungültige Quelldatei samt ihrer fehlgeschlagenen JSON-Prüfung, bevor diese Quelle gesichert wird. Weder ein unvollständiger Snapshot noch seine eigene Dateiliste dienen als Soll-Liste. Die Prüfungen beantworten getrennte Fragen: * restic check: Besteht das Repository die gewöhnliche Strukturprüfung? * restic check --read-data: Gelingt die Prüfung aller gespeicherten Daten? * restic restore: Endet die Wiederherstellung mit Rückgabecode 0? * Bestand: Sind alle erwarteten Pfade vorhanden, ohne unerwartete Dateien? * SHA256: Stimmen alle erwarteten wiederhergestellten Dateien mit dem zuvor erstellten Soll-Manifest überein? * Parser: Können die festgelegten Standard-Leseprogramme die wiederhergestellten Dateien verarbeiten? Gemessene Ergebnisse -------------------- Fall check read-data restore Pfade SHA256 Parser (vorhandene Dateien) S1 0 0 0 12/12 12/12 12/12 S2 12 12 12 0/12 0/12 nicht durchgeführt (0 Dateien) S3 0 1 1 11/12 11/12 11/11 S4 0 0 0 11/12 11/12 11/11 S5 0 0 0 12/12 11/12 12/12 S6 0 0 0 12/12 12/12 11/12 Rückgabecodes: 0 bedeutet einen erfolgreichen Abschluss. In diesem Lauf bedeutet 12, dass das öffentliche Testpasswort falsch war; 1 meldet einen Fehler bei Datenprüfung, Lesen oder Wiederherstellung. Die JSON-Datei und das Befehlsprotokoll bewahren die getrennten Vorgänge und Diagnosemeldungen. Rückgabecode 0 darf nicht als Nachweis dafür gelten, dass der vollständige Wiederherstellungsbedarf einer Person erfüllt wurde. S1: Unveränderte künstliche Quelldateien. Alle erwarteten Dateien waren vorhanden, ihre Bytes stimmten mit der Referenz überein und alle Formatprüfungen wurden bestanden. S2: Ein absichtlich falsches öffentliches Testpasswort wurde beim Zugriff auf eine Kopie des Repositorys aus S1 verwendet. Es wurden keine Dateien wiederhergestellt. Der Fall prüft die Zurückweisung eines bestimmten falschen Testpassworts, nicht das Vorhandensein oder Fehlen anderer Schlüssel. S3: In einer entbehrlichen Kopie des Repositorys aus S1 wurde ein Byte verschlüsselter Daten in einem Datenblock verändert. Der einzelne Block für documents/records.json wurde anhand seines bekannten Inhaltshashes im restic-Index gefunden. Geändert wurde das Byte hinter seiner 16 Byte langen Nonce. Größe und Header des Packs blieben unverändert. Die gewöhnliche Prüfung gelang; vollständiges Lesen und Wiederherstellung schlugen fehl. Elf Dateien wurden zurückgeholt. Die genauen Pack- und Block-IDs, die Byteposition, die Pack-Prüfsummen und die fehlende Datei sind in results.json festgehalten. Das Ergebnis gilt für diese gezielt erzeugte Beschädigung; die gewöhnliche Prüfung kann andere Schäden erkennen. S4: documents/contacts.csv wurde vom Backup ausgeschlossen, nachdem das vollständige Soll-Manifest erstellt worden war. Alle restic-Vorgänge gelangen. Der unabhängige Bestandsabgleich und der Hash-Abgleich über alle erwarteten Dateien blieben jedoch bei 11/12. S5: Der ältere vollständige Snapshot wurde wiederhergestellt, obwohl bereits ein neuerer existierte. documents/status.json enthält Revision 1 statt der benötigten Revision 2. Alle zwölf Dateien sind lesbar, aber nur elf stimmen mit dem Soll-Manifest des aktuellen Stands überein. Alle zwölf stimmen mit dem separat aufbewahrten Manifest der alten Quelle überein. Dies ist die korrekte Wiederherstellung einer für das Ziel falschen Version, keine durch restic verursachte Beschädigung. S6: documents/records.json enthält bereits vor dem Backup ungültiges JSON. Die fehlgeschlagene Formatprüfung der Quelle ist in synthetic-manifests.json dokumentiert. Alle wiederhergestellten Bytes stimmen mit der Quelle überein; derselbe JSON-Parser schlägt weiterhin fehl. Die Wiederherstellung hat den ungültigen Inhalt nicht verursacht. Bedeutung der Parser-Spalte -------------------------- Nur tatsächlich vorhandene Dateien werden geprüft. Fehlende Dateien sind in der Bestandsspalte erfasst und dürfen nicht als bestandene Formatprüfungen gezählt werden. TXT wird strikt als UTF-8 dekodiert. JSON verwendet json.loads. CSV verwendet csv.reader(strict) und prüft eine einheitliche Spaltenzahl. XML verwendet ElementTree.parse. ZIP liest alle enthaltenen Dateien und prüft ihre CRC-Prüfsummen. WAV liest alle angegebenen Audioframes und prüft deren Bytelänge. TOML verwendet tomllib.loads. Dies sind tatsächliche Lese- und Formatprüfungen, keine Prüfungen der Dateiendung. Sie belegen weder, dass eine bestimmte Desktop-Anwendung alle Eigenschaften darstellt, noch, dass der Inhalt die tatsächlichen Bedürfnisse einer Person erfüllt. Öffentliche Dateien ------------------- restore-lab.py Abschließender Quellcode zur Wiederholung des Versuchs; verwendet nur die Standardbibliothek. results.csv Kompakte numerische Ergebnisse. results.json Ergebnisse je Datei, Snapshot-IDs, Herkunft der Programmdatei, Skript-Hash und Einzelheiten der gezielt erzeugten Beschädigung. synthetic-manifests.json Vorab erstellte Soll-Referenzen und Ergebnisse der Formatprüfungen an den Quelldateien. command-log.json Tatsächliche Befehle, Rückgabecodes, stdout und stderr. Versuchspfade, Namen des ausführenden Benutzerkontos und Zeitstempelfelder wurden unkenntlich gemacht; operative Ergebnisse nicht. lab-readme.txt Diese Beschreibung von Methodik und Auswertung. Den Versuch unter Windows amd64 wiederholen ------------------------------------------ Voraussetzungen sind Python 3.11 oder neuer und die unten genannte offizielle ZIP-Datei. Der dokumentierte Lauf verwendete Python 3.12.10. Speichere restore-lab.py in einem neuen Arbeitsordner. Lade die offizielle ZIP-Datei herunter und vergleiche ihren SHA256-Wert mit der offiziellen Datei SHA256SUMS. Das Skript akzeptiert die Dateien nur, wenn sowohl der ZIP-Hash als auch der Hash der ausführbaren Datei mit den unten angegebenen Werten übereinstimmen. Es lädt selbst nichts herunter und benötigt keine systemweite Installation von restic. Veröffentlichung: https://github.com/restic/restic/releases/tag/v0.19.1 ZIP: https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_windows_amd64.zip Offizielle Prüfsummen: https://github.com/restic/restic/releases/download/v0.19.1/SHA256SUMS ZIP SHA256: da948ad707ed690426473aaba2046cd61f8f90f6f0e7dab6be0d5796531de67d SHA256 der entpackten ausführbaren Datei: b0dd1fd21eea5d8fe1325f55f7118213c21f36de8a261e04c0624a5ab9fd7830 Gemessene Versionsausgabe: restic 0.19.1 compiled with go1.26.4 on windows/amd64 Der ZIP-Hash wurde mit der Prüfsumme derselben offiziellen HTTPS- Veröffentlichung verglichen. Eine separate Prüfung der Signatur dieser Veröffentlichung wurde nicht durchgeführt. Führe in PowerShell aus deinem neuen Arbeitsordner folgenden Befehl aus: python .\restore-lab.py --restic-zip .\restic_0.19.1_windows_amd64.zip Das Skript erzeugt in diesem Arbeitsordner ein neues Verzeichnis namens c07-restore-lab-* und gibt LAB_ROOT aus. Es nimmt weder ein vorhandenes Repository noch einen Quell- oder Zielordner entgegen. Symbolische Links und Windows-Reparse-Points einschließlich Junctions werden abgelehnt. Die ZIP-Datei wird als Bytes gelesen; nur die namentlich festgelegte ausführbare Datei wird entpackt. Die absichtliche Beschädigung beschränkt sich auf die neu erstellte Repository-Kopie aus S3. Es gibt weder eine automatische Bereinigung noch Eingriffe in echte Daten. Die festen Zeichenfolgen PUBLIC-SYNTHETIC-LAB-ONLY... sind nicht geheime Testwerte. Jeder kann sie lesen. Verwende sie niemals zum Schutz echter Dateien. Die gestarteten restic-Prozesse erhalten diese Testwerte und übernehmen keine RESTIC_*-Einstellungen. Ihr Ordner für temporäre Dateien liegt unterhalb des neuen Versuchsordners. Globale Umgebungsvariablen und VPN-Einstellungen werden nicht verändert. Die Ergebnisse werden innerhalb von LAB_ROOT gespeichert. Keine Datei wird automatisch in einen Veröffentlichungsordner kopiert. Jede Wiederholung erzeugt einen neuen Versuchsordner. Zufällige Repository-Schlüssel, Snapshot-IDs, Pack-IDs und Laufzeiten unterscheiden sich zwischen Läufen. Die zu beschädigende Datei ist über ihren bekannten Inhaltshash festgelegt. Der veröffentlichte Quellcode wird zu Beginn gehasht und zum Abschluss erneut geprüft. Eine Skriptänderung während des Laufs verhindert deshalb dessen ordnungsgemäßen Abschluss. Grenzen ------- Der normale Testbestand umfasst 2.330 Bytes und ist bewusst klein. Der Versuch misst keine großen Repositorys, Wiederherstellungsgeschwindigkeiten, Laufwerksausfallraten, Medienlebensdauer, Widerstandsfähigkeit räumlich getrennter oder offline gelagerter Kopien, Wiederherstellung von Cloud- Konten, Aufbewahrung von Zugangsdaten, vollständige Betriebssystem- Wiederherstellung, Dateirechte, Zugriffslisten, alternative Datenströme, Darstellung in Anwendungen oder künftige Formatunterstützung. Bestandene Formatprüfungen gelten nur für diese Testdateien und Leseprogramme. Aus diesem Versuch ergibt sich keine Garantie für ein persönliches Backup. Relevante offizielle Dokumentation --------------------------------- https://restic.readthedocs.io/en/stable/045_working_with_repos.html https://restic.readthedocs.io/en/stable/050_restore.html https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html Die veröffentlichten Ergebnisse sind Beobachtungen zu Version 0.19.1. Das stable-Handbuch kann später geändert werden. Deshalb sind Versionsausgabe, Veröffentlichungsadresse, Prüfsummen, Befehle und Quellcode hier festgehalten. Zusätzliches Lernmaterial (2026-09-13) ------------------------------------- Das neue Vergleichsskript gleicht ein Versuchsprotokoll mit der veröffentlichten Referenz ab. Hinweise zur Vorbereitung, zu den Ergebnissen, den Grenzen und zur Erstellung der Abbildung stehen in comparison-readme.txt. Diese technische Ergänzung und die eigenständige Abbildung sind auf Englisch.