Restore

Es gibt drei Wege, Dateien aus einem Endpoint-Backup zurückzuholen. Keiner überschreibt etwas auf dem Rechner.

Weg	Nutzen Sie ihn, wenn
Restore auf den Rechner	Der Rechner läuft und sein Agent ist verbunden. Die Dateien landen in einem neuen Ordner.
Durchsuchen und als ZIP herunterladen	Sie die Dateien auf Ihrem eigenen Computer haben wollen oder der Rechner weg ist.
Restore ohne Restow	Restow selbst nicht verfügbar ist.

Alle drei beginnen im Tab Snapshots des Endpoints („Wiederherstellungspunkte“): Öffnen Sie den Endpoint, wählen Sie einen Snapshot und klicken Sie sich durch seine Ordner. Wählen Sie Dateien oder Ordner in der Liste aus. Ein ausgewählter Ordner schließt alles darin ein. Jedes erfolgreiche Backup erzeugt einen Snapshot.

Restore auf den Rechner

Wählen Sie die Dateien und Ordner aus und dann Auf den Rechner wiederherstellen.
Geben Sie optional einen Zielordner an: einen absoluten Pfad auf dem Rechner.
Bestätigen Sie mit Wiederherstellung anfordern.

Der Rechner startet den Restore bei seinem nächsten Kontakt, meist innerhalb weniger Minuten. Ist er aus oder offline, wartet die Anfrage, bis er wieder da ist. Sie können den Lauf unter Läufe in der Übersicht des Endpoints verfolgen, der den Ordner zeigt, in den wiederhergestellt wurde.

Standardziel. Ohne Zielordner legt der Agent einen neuen Ordner namens Restow-Restore-<yyyyMMdd-HHmmss> im ersten gesicherten Ordner an.
Das Ziel darf nicht existieren oder muss ein leerer Ordner sein. Sonst schlägt der Lauf mit dem Code target_not_empty fehl, und nichts wird angerührt. Der Agent übergibt restic außerdem --overwrite never und --verify. Die Dateien, die jetzt auf dem Rechner liegen, bleiben unverändert.
Dateinamen mit *, ? oder [ werden genau getroffen.
Sie können bis zu 200 Elemente pro Restore auswählen.
Der Agent lässt Ordner namens Restow-Restore-* aus späteren Backups aus, damit wiederhergestellte Dateien nicht ein zweites Mal gesichert werden.
Ein gesperrter Endpoint nimmt keinen Restore an, denn er nimmt keine Aufgaben an. Laden Sie die Dateien stattdessen als ZIP herunter.

Die Anforderung und das Ende des Restores stehen im Audit-Log (endpoint.restore.requested, endpoint.restore.finished). Schlägt ein Restore fehl, siehe Fehlerbehebung.

Durchsuchen und als ZIP herunterladen

Durchsuchen und Herunterladen arbeiten auf dem Server. Der Rechner muss nicht online sein, und ein gesperrter Endpoint lässt sich weiterhin durchsuchen und herunterladen.

Wählen Sie die Dateien und Ordner aus und dann Als ZIP herunterladen.
Ihr Browser lädt das ZIP herunter.

So verhält es sich:

Bis zu 50 Pfade je ZIP. Brauchen Sie mehr, wählen Sie einen übergeordneten Ordner.
Das Durchsuchen listet einen Ordner nach dem anderen auf, bis zu 5000 Einträge je Ordner. Hat ein Ordner mehr, sagt die Oberfläche, dass die Liste gekürzt ist. Wählen Sie den Ordner selbst, um alles darin einzuschließen.
Das ZIP zeigt den gewählten Ordner (docs/a.txt, nicht home/anna/docs/a.txt).
Symbolische Links und Spezialdateien tragen keinen Inhalt und fehlen im ZIP. Die Oberfläche kennzeichnet sie.
Restow prüft vorab, dass jeder gewählte Pfad im Snapshot existiert. Existiert einer nicht, scheitert die Anfrage, statt mitten im Download abzubrechen.
Das ZIP wird beim Senden gebaut, und nichts wird auf der Platte zwischengespeichert. Schlägt das Lesen unterwegs fehl, wird die Verbindung abgebrochen, sodass Sie nie ein ZIP erhalten, das vollständig aussieht und es nicht ist.
Große Ordner über sehr langsame Verbindungen: Der Server hält die Verbindung offen, solange restic liefert. Ein Proxy mit kurzem Leerlauf-Timeout vor Restow kann sie kappen.
Der Server führt nur eine begrenzte Zahl von restic-Prozessen gleichzeitig aus (6 insgesamt, 3 je Mandant). Ist die Grenze erreicht, bittet die Oberfläche Sie, es gleich noch einmal zu versuchen.

Durchsuchen und Herunterladen stehen im Audit-Log (endpoint.snapshot.browsed, endpoint.snapshot.downloaded).

Restore ohne Restow

Das Backup eines Endpoints ist ein gewöhnliches restic-Repository. Mit dem Repository-Passwort und Zugriff auf das Speicherziel können Sie es allein mit restic wiederherstellen, auch wenn Ihr Restow-Server nicht mehr existiert.

Öffnen Sie den Endpoint, den Tab Einstellungen und die Karte Wiederherstellung ohne Restow.
Wählen Sie Repository-Passwort anzeigen und bestätigen Sie. Restow zeigt das Passwort. Es wird nicht im Browser gespeichert und wieder ausgeblendet, wenn Sie das Fenster schließen.
Bewahren Sie das Passwort in einem Passwortmanager auf.

Das Anzeigen des Passworts steht im Audit-Log (endpoint.repository.password.revealed).

Bei einem lokalen Speicherziel ist das Repository der Ordner endpoints/<Endpoint-ID> im Speicherpfad. Der Befehl lautet dann:

restic -r /path/to/storage/endpoints/<endpoint id> restore latest --target /restore

Ersetzen Sie /path/to/storage durch den Ordner Ihres Speicherziels. restic fragt nach dem Repository-Passwort. Der Befehl stellt den neuesten Snapshot nach /restore wieder her. Bei einem S3-Speicherziel öffnen Sie den Bucket direkt mit restic (-r s3:..., mit endpoints/<Endpoint-ID> als Präfix), sofern das Repository unter diesem Pfad liegt.

Restore-Tests

Ein Backup, das niemand zurückgelesen hat, ist unbewiesen. Nach jedem neuen guten Backup beweist Restow, dass sich Dateien zurücklesen lassen.

So funktioniert es

Nach jedem erfolgreichen Backup wählt der Agent bis zu 20 zufällige Dateien aus dem Snapshot und meldet ihren Pfad, ihr SHA-256 und ihre Größe. Die Dateien sind regulär, nicht leer, höchstens 256 MiB groß und zusammen höchstens 1 GiB. Der Hash wird von der Datei auf der Platte gebildet, aber nur bei Dateien, die seit dem Snapshot nachweislich unverändert sind (gleiche Größe und Änderungszeit vor und nach dem Hashen). Eine spätere Abweichung weist deshalb auf das Backup hin, nicht auf eine nachträgliche Änderung.
Der Server liest diese Dateien mit restic dump aus dem Repository, bildet ihr SHA-256 und vergleicht es mit dem gemeldeten Wert. Das Ergebnis ist nur grün, wenn alle Hashes übereinstimmen und mindestens eine Datei getestet wurde. Eine Datei, die abweicht, fehlt oder sich nicht lesen lässt, macht den Snapshot rot. War das Repository nur beschäftigt, wird nichts bewertet, und der Job wird wiederholt.
Zusätzlich gibt der Server dem Agent eine verify_sample-Aufgabe mit denselben Dateien. Der Agent stellt sie in einen temporären Ordner unterhalb seines Datenverzeichnisses her, vergleicht das SHA-256, löscht die Kopie und meldet je Datei (hash_mismatch, missing, not_regular, read_error). Das wird ein zweiter Bericht zum selben Snapshot.
Scheitert einer der beiden, ist der Endpoint rot.

Sie können einen Test selbst mit Wiederherstellungstest starten am Endpoint anstoßen. Er braucht zuerst ein erfolgreiches Backup. Die Ergebnisse stehen unter Berichte, mit den Abweichungen, falls es welche gibt. Die Berichte sagen, ob ein Ergebnis „Vom Server zurückgelesen“ oder „Auf dem Rechner wiederhergestellt“ wurde. Der Server behält die Stichproben 90 Tage.

Zustände der Wiederherstellbarkeit. Die Bewertung gehört zu dem Backup, das geprüft wurde. Ein grüner Test eines älteren Backups zählt für ein neueres nicht.

Zustand	Bedeutung
Noch keine Sicherung (`no_backup`)	Es gibt noch kein gutes Backup.
Nicht geprüft (`unverified`)	Ein Backup existiert, aber kein Restore-Test hat genau dieses Backup geprüft.
Bereit (`green`)	Der Restore-Test des neuesten Backups ist bestanden.
Achtung (`yellow`)	Der Test ist bestanden, aber das Backup war teilweise: Einige Dateien ließen sich nicht lesen.
Nicht wiederherstellbar (`red`)	Ein Restore-Test des neuesten Backups ist fehlgeschlagen, oder eine neuere Repository-Prüfung hat Schäden gefunden.

Eine Bewertung, die älter als 8 Tage ist, wird als Überfällig angezeigt. Endpoints erscheinen in der Übersicht der Wiederherstellbarkeit neben Postfächern und OneDrives. Dieselbe Idee für Postfächer beschreibt Wie Restow prüft, ob eine Sicherung wiederherstellbar ist.

Ein Restore-Test beweist, dass die Stichproben-Dateien unversehrt zurückkommen. Er beweist nicht jede Datei, und er testet keinen vollständigen Restore des ganzen Rechners.

Repository-Prüfung und Aufbewahrung

Zwei weitere Jobs laufen auf dem Server, ohne den Rechner.

Repository-Prüfung: Einmal pro Woche liest restic check ein Zwanzigstel der gespeicherten Daten, in fester Reihenfolge, sodass das ganze Repository in etwa fünf Monaten gelesen wird. Das Ergebnis ist grün oder rot. Ein Schaden löst den Alarm „Speicherschaden gefunden“ aus und setzt den Endpoint auf Nicht wiederherstellbar.
Aufbewahrung: Einmal täglich entfernt der Server Snapshots jenseits der aufbewahrten Zahlen (standardmäßig 30 tägliche, 12 wöchentliche und 12 monatliche). Siehe Profile, Zeitplan und Hooks.

Beide Ergebnisse stehen unter Berichte des Endpoints.