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 Sicherungsstände des Endpoints: Öffnen Sie den Rechner unter Server & Clients → Inventar, wählen Sie einen Sicherungsstand und klicken Sie sich durch seine Ordner. Server & Clients → Datei-Restore bietet denselben Browser und denselben Restore-Dialog, ohne den Rechner erst zu öffnen: Wählen Sie einen Rechner, dann einen Sicherungsstand. Wählen Sie Dateien oder Ordner in der Liste aus. Ein ausgewählter Ordner schließt alles darin ein. Jedes erfolgreiche Backup erzeugt einen Sicherungsstand. Restore-Operatoren arbeiten nur in Datei-Restore.

Ein Sicherungsstand trägt zwei Markierungen, die aus anderen Funktionen kommen:

Unveränderbar bis <Datum> erscheint, wenn der Speicher selbst eine Compliance-Sperre für den Sicherungsstand bestätigt. Siehe Unveränderbare Backups.
Verdächtig erscheint, wenn die Ransomware-Erkennung darin Anzeichen eines Angriffs gefunden hat. Ist der neueste Sicherungsstand verdächtig, bieten die Restore-Ansichten den neuesten ohne Befunde an.

Der Dateibrowser sagt, welche Ordner ein Sicherungsstand enthält (Dieser Sicherungsstand enthält:), mit einem Link zu den Ordnern des Jobs, und zeigt einen Hinweis, wenn ein Datenordner des Rechners nicht darin ist. Siehe Datenordner, die ein Job auslässt.

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 Rechners 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, den nur root ändern kann. Gibt es keinen, nimmt er / unter Linux und /Users unter macOS.
Das Ziel ist ein schlichter absoluter Pfad, ohne .., ., doppelte oder abschließende Schrägstriche. Sonst schlägt der Lauf mit dem Code invalid_task fehl.
Jeder Ordner über dem Ziel darf nur von root änderbar sein. Der übergeordnete Ordner muss existieren. Ein Ordner, in den alle schreiben dürfen und der das Sticky-Bit trägt, etwa /tmp, ist in Ordnung. Ein Ziel im Home-Ordner eines Benutzers wird mit dem Code target_unusable abgelehnt, weil ein Benutzer, dem ein Ordner auf dem Weg gehört, den neuen Ordner gegen einen Link tauschen könnte, während root hineinschreibt.
Der Agent legt das Ziel mit Modus 0700 an, nur root kann es also betreten. Die wiederhergestellten Dateien behalten ihre eigenen Modi und Eigentümer.
Das Ziel darf nicht existieren oder muss ein leerer Ordner sein, der root gehört. 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. Gesperrte Rechner sind im Inventar ausgeblendet, bis Sie Gesperrte Rechner anzeigen wählen, und Datei-Restore führt sie in einer eigenen Gruppe, Gesperrte Rechner. Ein Rechner, der aus Restow entfernt wurde, lässt sich, solange seine Sicherungen gespeichert sind, noch durchsuchen und herunterladen (seit 0.4.6), aber nie als Ziel eines Restores nutzen: Die Liste der entfernten Rechner im Inventar verlinkt Dateien wiederherstellen (Deinstallation).

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, ebenso ein entfernter Rechner, bis seine Sicherungen gelöscht sind (seit 0.4.6).

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 10.000 Pfade je ZIP. Der Server liest jede einzeln gewählte Datei und jeden einzeln gewählten Ordner mit einem eigenen restic-Prozess, tausende Einzeldateien dauern also entsprechend. Ein übergeordneter Ordner ist viel schneller, und die Oberfläche weist ab 50 Einzeldateien darauf hin.
Das Durchsuchen listet einen Ordner nach dem anderen auf, Seite für Seite. Die Oberfläche lädt die erste Seite beim Öffnen eines Ordners und weitere mit Mehr laden. Eine Seite enthält bis zu 5.000 Einträge (standardmäßig 1.000). 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).
Eintragsnamen lassen sich überall gefahrlos entpacken. Backslashes, Doppelpunkte und Steuerzeichen in Namen werden zu _, und Teile, die nur aus Punkten bestehen, entfallen. Ein Linux-Dateiname wie ..\..\x bleibt beim Entpacken unter Windows also ein Dateiname.
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.
Während der Server die Aufbewahrung oder eine Repository-Prüfung auf dem Repository ausführt, warten Durchsuchen und Herunterladen bis zu zwei Sekunden und antworten dann mit Die Sicherungsdaten sind gerade belegt (endpoint-repository-locked). Versuchen Sie es in einer Minute erneut. Ein vorbereiteter Download, der so abgewiesen wurde, lässt sich weiterhin starten.

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

Datei-Restore für Restore-Operatoren (seit 0.4.0)

Personen mit der Mandantenrolle Restore-Operator (die Mitgliedsrolle „restore“, tenant_restore) öffnen Server & Clients → Datei-Restore. Vor 0.4.0 konnten sie Postfächer und OneDrives wiederherstellen, aber keine Rechner. In Datei-Restore können sie:

die Rechner des Mandanten auflisten, die gesperrten in der Gruppe Gesperrte Rechner,
die Sicherungsstände eines Rechners lesen und sehen, ob sie unveränderbar sind,
die Dateien eines Sicherungsstands durchsuchen,
Dateien und Ordner als ZIP herunterladen,
Dateien auf den Rechner wiederherstellen, in einen neuen Ordner wie oben beschrieben (nicht auf einen gesperrten Rechner).

Bei den Administratoren bleiben: die Einstellungen eines Rechners, Installationsbefehle, Jobs, Sichern (Jetzt sichern antwortet bei einem Restore-Operator mit 403), Restore-Prüfungen, das Lauf-Protokoll, Agent-Updates, das Sperren oder Deinstallieren eines Rechners und das Repository-Passwort. Die Weboberfläche lässt die Links zu Seiten weg, die ein Restore-Operator nicht öffnen darf, es gibt für ihn also kein Inventar und keine Seite des Rechners. Die Richtlinie der Agenten eines Rechners ist für alle nur lesbar, und die Route, die sie bedient, steht Restore-Operatoren offen, aber die Seite, die sie zeigt, gehört den Administratoren.

Jedes Lesen, jeder Download und jeder Restore steht im Audit-Log, mit dem Operator als Akteur (endpoint.snapshot.browsed, endpoint.snapshot.downloaded, endpoint.restore.requested). Siehe Audit-Log.

Bei Proxmox VE führt dieselbe Rolle Gäste mit einem Sicherungsstand in Datei-Restore auf und durchsucht und lädt die Dateien von Sicherungsständen von Containern und VMs herunter, stellt aber keinen ganzen Gast wieder her, sichert ihn nicht und führt keine Startprüfung durch. Siehe Dateien eines Gasts. Mehr zu den Rollen: Team und Rollen.

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 Rechner unter Server & Clients → Inventar, den Tab Einstellungen und die Karte Wiederherstellung ohne Restow.
Wählen Sie Repository-Passwort anzeigen und bestätigen Sie. Liegt Ihre Anmeldung länger als 10 Minuten zurück, bittet Restow Sie zuerst zu bestätigen, dass Sie es sind (mit einem Passkey oder durch erneutes Anmelden). Danach zeigt Restow 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.

Nur mit dem Master-Key

Der Server legt jedes Repository-Passwort außerdem neben sein Repository, versiegelt mit dem Mandantenschlüssel: endpoints/<Endpoint-ID>/restow-repository-password.json. Er schreibt die Datei, wenn sich ein Rechner anmeldet, und jeder Aufbewahrungs- oder Prüflauf ersetzt eine beschädigte oder veraltete. restic übergeht die Datei, und der Agent kann sie weder lesen noch ersetzen. Master-Key (KEK) und Speicher genügen deshalb, auch ohne Datenbank und ohne laufenden Restow-Server. Das eigenständige Werkzeug restow-restore (siehe Restow selbst sichern) stellt das Passwort wieder her, und reines restic stellt die Dateien wieder her:

restow-restore endpoint-password --storage /path/to/storage --key <KEK file or variable> \
  --endpoint <endpoint id> --out /root/endpoint-password
restic -r /path/to/storage/endpoints/<endpoint id> --password-file /root/endpoint-password \
  restore latest --target /srv/restore

--key nimmt den Master-Key (RESTOW_MASTER_KEY) als Dateipfad oder als Namen einer Umgebungsvariable, die ihn enthält. --out schreibt das Passwort in eine neue Datei mit Modus 0600 und überschreibt keine vorhandene. Ohne --out geht das Passwort auf die Standardausgabe, und sonst nichts. Die Endpoint-ID ist der Ordnername unter endpoints/, und die Weboberfläche zeigt sie auf der Seite des Rechners. Löschen Sie die Passwort-Datei, wenn der Restore abgeschlossen ist.

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. Rot braucht einen Beleg: einen abweichenden Hash, oder restic meldet, dass die Datei nicht im Snapshot steht oder dass Daten, die sie braucht, fehlen oder beschädigt sind. Ein Lesevorgang, der aus einem anderen Grund scheiterte (Repository beschäftigt, restic nicht startbar oder Repository nicht erreichbar), bewertet nichts, und der Test wird erneut angeboten.
Zusätzlich gibt der Server dem Agent eine verify_sample-Aufgabe mit denselben Dateien. Der Agent stellt sie mit einem einzigen restic restore in einen temporären Ordner unterhalb seines Datenverzeichnisses her, hasht jede Datei, löscht die Kopie und meldet, was er vorgefunden hat. Der Server beurteilt diesen Bericht nach denselben Regeln: Ein abweichender Hash, eine Datei, die nach einem fehlerfrei beendeten Restore fehlt, oder die eigenen Befunde von restic bewerten ihn rot; alles andere (eine volle Platte, ein während des Tests angehaltener Agent, ein nicht erreichbares Repository) bewertet nichts. Ein solcher Test erscheint als Nicht abgeschlossen, wird wiederholt und wird nach 1, 2, 4, 8, 16 und 24 Stunden erneut angeboten, solange die Sicherung die neueste des Rechners ist. Ein beurteiltes Ergebnis wird ein zweiter Bericht zum selben Snapshot.
Ist einer der beiden rot, ist der Endpoint rot. Einzelheiten: Prüfung im Detail.

Sie können einen Test selbst mit Restore-Prüfung starten auf der Seite des Rechners 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 nachgewiesen (`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 liest zurück und prüft: Er beweist, dass die Stichproben-Dateien unversehrt zurückkommen. Er beweist nicht jede Datei, er stellt nichts auf dem Rechner wieder her, 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 Rechners.