Zum Inhalt springen

Wiederherstellen und Restore-Prüfung

Eine Freigabe stellen Sie aus einem Sicherungsstand auf der Seite der Freigabe wieder her: Server & Clients → Freigaben, die Freigabe wählen, Tab Sicherungsstände. Wer darf das: Mandanten-Administratoren für ihre eigenen Freigaben und Provider-Administratoren, die in einem Mandanten arbeiten. Nutzer eines Mandanten und Restore-Operatoren haben in 0.4.7 keine Selbstbedienungs-Wiederherstellung von Freigaben; die Datei-Wiederherstellung der Restore-Rolle umfasst Rechner und Proxmox VE, keine Freigaben.

Der Tab Sicherungsstände listet jeden Sicherungsstand mit der Zahl seiner Dateien, dem, was er hinzufügte, und der Zahl der Berechtigungseinträge, die er enthält. Öffnen Sie einen, um seine Ordner und Dateien so zu durchsuchen, wie sie zu dieser Zeit waren.

  • Datei finden. Durchsucht die Namen aller Dateien in allen Sicherungsständen der Freigabe. Eine Suche braucht mindestens drei Zeichen des Namens. Treffer können Gelöscht sein (nicht mehr im neuesten Sicherungsstand), und Versionen zeigt jede Version einer Datei mit ihrer Änderungszeit und den Sicherungsständen, in denen sie steckt.
  • Die Suche nutzt einen Dateikatalog, den Restow nach jeder Sicherung aktuell hält. Er steht nicht zur Verfügung, solange er aufgebaut wird, wenn ein Provider-Administrator ihn ausgeschaltet hat (Dateikatalog in den Einstellungen der Runner) oder bei einer Freigabe mit mehr als 20 Millionen Dateien. Das Durchsuchen eines Sicherungsstands geht auch ohne ihn.
  • Eine Version, die nur in Sicherungsständen steckt, die die Aufbewahrung inzwischen entfernt hat, ist mit „nur in Sicherungsständen, die entfernt wurden“ markiert.

Wählen Sie Dateien oder Ordner (oder Alles im Sicherungsstand) und dann Wiederherstellen. Der Dialog fragt Wohin:

Auswahl Was geschieht
Als ZIP herunterladen Der Server liest die Dateien aus dem Repository und bereitet ein ZIP vor. Es enthält die Berechtigungen nicht und braucht weder den Mounter noch Wiederherstellung in diese Freigabe erlauben.
Den ursprünglichen Ort Die Dateien gehen in die Freigabe zurück, aus der sie stammen, an dieselbe Stelle. Sie wählen Wenn eine Datei vorhanden ist, siehe unten. Braucht Wiederherstellung in diese Freigabe erlauben bei dieser Freigabe.
Einen neuen Ordner in derselben Freigabe Die Dateien gehen in Restow-Restore-<Datum>-<Uhrzeit> im Stamm der Freigabe (zum Beispiel Restow-Restore-20261016-103000). Braucht Wiederherstellung in diese Freigabe erlauben.
Eine andere Freigabe Die Dateien gehen in einen Ordner einer anderen Freigabe, bei der Wiederherstellung in diese Freigabe erlauben an ist. Leer: ein neuer Ordner mit Datum und Uhrzeit im Namen. Der Ordner wird angelegt, wenn es ihn nicht gibt. Unter dieser Auswahl öffnet Als Kopierjob nach Zeitplan wiederholen den Editor für einen Kopierjob mit eingetragener Quelle, Ziel und Ordner.

Wenn eine Datei vorhanden ist (nur beim ursprünglichen Ort):

  • Überschreiben. Die wiederhergestellte Datei ersetzt die vorhandene, wenn sie abweicht.
  • Beide behalten. Eine fehlende Datei wird wiederhergestellt. Eine gleiche Datei (gleiche Größe und Änderungszeit) bleibt unberührt. Eine abweichende Datei bleibt, und die wiederhergestellte Kopie wird daneben als <Name> (restored 2026-10-16 1030)<Endung> abgelegt (der Zusatz „restored“ steht im Produkt auf Englisch). Nichts wird überschrieben.
  • Überspringen. Eine vorhandene Datei bleibt; die wiederhergestellte wird ausgelassen.

Die beiden anderen Optionen des Dialogs:

  • Berechtigungen wiederherstellen. Schreibt Besitzer und Berechtigungen so zurück, wie sie gesichert wurden. Beim ursprünglichen Ort und bei einem neuen Ordner ist die Option an, bei einer anderen Freigabe aus: Der andere Dateiserver kennt womöglich nicht dieselben Konten, und ein unbekanntes Konto in einer Berechtigung kann Menschen aus den wiederhergestellten Dateien aussperren. Schalten Sie sie dort nur ein, wenn beide Server dieselben Konten kennen.
  • Geschriebene Dateien prüfen. Liest jede Datei nach dem Schreiben zurück. Langsamer. Bei NFS-Zielen standardmäßig an (bei soft-Mounts könnte ein Schreibvorgang, der ein Zeitlimit überschritt, sonst unbemerkt verloren gehen), bei SMB aus.

Dann zeigt Bitte prüfen Sie, was wohin geht, und Wiederherstellen bestätigt. Die Wiederherstellung erscheint unter Läufe als Lauf der Art Wiederherstellung mit Live-Fortschritt und endet als Abgeschlossen oder Mit Warnungen (für Dateien, die sich nicht schreiben ließen: ein Name, den das Ziel nicht aufnehmen kann, fehlende Rechte, kein Platz). Wiederherstellungen und Kopien belegen die Ziel-Freigabe wie eine Sicherung: ein Lauf je Freigabe gleichzeitig, eine Wiederherstellung in eine Freigabe wartet also, solange eine Sicherung von ihr läuft.

Eine Wiederherstellung löscht nie etwas und schreibt nie außerhalb ihres Ordners. Der einzige Lauf, der löscht, ist ein spiegelnder Kopierjob, innerhalb seines eigenen Zielordners.

Wiederherstellung in diese Freigabe erlauben ist standardmäßig aus, bei jeder neuen Freigabe. Solange der Schalter aus ist, kann keine Wiederherstellung und kein Kopierjob in die Freigabe schreiben. Der Schalter steht im Dialog zum Hinzufügen und unter Einstellungen der Freigabe, und eine Änderung steht im Audit-Log. Der Grund ist einfach: Eine Wiederherstellung an den ursprünglichen Ort kann Dateien überschreiben, an denen Menschen arbeiten. Schalten Sie ihn nur bei Freigaben ein, in die Sie wiederherstellen wollen, zum Beispiel bei der Freigabe eines zweiten Standorts, die Kopien empfängt. Eine Freigabe, die keine Wiederherstellung erlaubt, sagt das im Dialog („Diese Freigabe erlaubt keine Wiederherstellung in sich.“) und verlinkt auf ihre Einstellungen. Die Ursache einer abgelehnten Wiederherstellung ist share.restore_not_allowed.

Bei SMB schreibt eine Wiederherstellung die Berechtigungen Datei für Datei zurück, soweit das Konto der Ziel-Freigabe es darf. Sie versucht zuerst den Besitzer mit der Zugriffssteuerungsliste und den Überwachungseinträgen, dann die Zugriffssteuerungsliste mit dem Besitzer, dann die Liste allein, und zählt die erreichte Stufe je Datei.

  • Um Besitzer zu setzen, braucht das Konto SeRestorePrivilege auf dem Server. Um Überwachungseinträge zu setzen, braucht es SeSecurityPrivilege. Ohne sie schreibt die Wiederherstellung trotzdem den Inhalt und endet Mit Warnungen mit share.acl_partial („Berechtigungen wurden nicht für jede Datei gesichert oder wiederhergestellt“). Dateien, die die vom Ziel geerbten Berechtigungen behielten, stehen als Berechtigungen nicht wiederhergestellt in der Liste.
  • DOS-Attribute (schreibgeschützt, versteckt, System, Archiv) und die Erstellungszeit werden zuletzt gesetzt, nach bestem Bemühen. Die Attribute, die eine Offline-Datei kennzeichnen, werden nie wiederhergestellt.
  • SMB-Daten in eine NFS-Freigabe oder umgekehrt: Der Inhalt wird wiederhergestellt, die Berechtigungen nicht, mit einer Warnung.
  • NFS: NFSv4- und POSIX-ACLs werden nach bestem Bemühen wiederhergestellt. Mit root_squash lässt sich der Besitzer nicht ändern: Besitzer nicht wiederhergestellt.
  • Die Berechtigungen einer einzelnen Datei werden nur zusammen mit der Datei wiederhergestellt.

Was ein Sicherungsstand nicht enthält und nicht zurückgeben kann: alternative Datenströme, Zugriffszeiten und jede Konsistenz über Dateien hinweg. Siehe Fehlerbehebung und Grenzen.

Eine Sicherung, die niemand zurückgelesen hat, ist unbewiesen. Jeder Sicherungsstand einer Freigabe wird deshalb automatisch geprüft:

  1. Am Ende jedes Sicherungslaufs wählt der Runner bis zu 20 zufällige Dateien, deren Änderungszeit eine Stunde vor dem Start des Laufs oder früher liegt und die sich beim Hashen nicht änderten. Er meldet ihre SHA-256 mit dem Sicherungsstand.
  2. Der Server liest genau diese Dateien mit restic aus dem Repository der Freigabe zurück und vergleicht sie mit der SHA-256. Das ist die Restore-Prüfung. Sie läuft direkt nach der Sicherung, für jeden neuen Sicherungsstand, und auch auf Anforderung: Restore-Prüfung jetzt starten auf der Übersicht der Freigabe.
  3. Einmal pro Woche führt der Server restic check auf 5 % der Daten des Repositorys der Freigabe aus. Der Teil wechselt, sodass das ganze Repository in etwa fünf Monaten gelesen wird, und ein dort gefundener Schaden bewertet die Freigabe rot, bis eine spätere Prüfung es unversehrt findet.

Wie ein Sicherungsstand bewertet wird. Die Wiederherstellbarkeit bewertet eine Freigabe nach ihrem neuesten Sicherungsstand, eine Zeile je Freigabe (siehe Wiederherstellbarkeit):

Bewertung Bedeutung
Bereit (grün) Die Restore-Prüfung hat jede ausgewählte Datei zurückgelesen, und jede stimmte überein.
Gelb Die Restore-Prüfung ist bestanden, aber die Sicherung endete Mit Warnungen (einige Dateien ließen sich nicht lesen), oder der Sicherungsstand hatte keine Stichprobe (unten). Die Liste der Freigaben zeigt diesen Zustand als Prüfung überfällig, gleich aus welchem Grund; die eigene Zeile des Sicherungsstands sagt, ob es Warnungen oder fehlende Stichproben sind.
Nicht wiederherstellbar (rot) Die Restore-Prüfung ist fehlgeschlagen (eine Datei stimmte nicht überein oder ließ sich nicht lesen), oder eine neuere Prüfung des Repositorys fand einen Schaden. Das Ereignis ist Restore-Prüfung nicht bestanden.
Nicht nachgewiesen Der Sicherungsstand ist vorhanden, wurde aber noch nicht geprüft.
Noch keine Sicherung Nichts zu prüfen, bis die erste Sicherung abgeschlossen ist.

Eine Bewertung, die älter als acht Tage ist, ist in der Wiederherstellbarkeit als Überfällig markiert, gleich in welcher Farbe. Eine Freigabe, die in einem Backup-Job ist und 24 Stunden nach dem Einordnen in den Job keine Sicherung hat, ist ebenso markiert („Keine Sicherung innerhalb von 24 Stunden, nachdem die Freigabe in einen Backup-Job kam“).

Keine Stichprobe. Wurde jede Datei einer Freigabe in der Stunde vor der Sicherung geändert (eine stark genutzte Freigabe, oder eine erste Sicherung direkt nach einer Migration), gibt es nichts Stabiles zum Zurücklesen. Die Restore-Prüfung bewertet den Sicherungsstand dann gelb mit dem Hinweis „Noch keine Stichprobe zum Prüfen: Jede Datei wurde in der Stunde vor der Sicherung geändert“, und der Sicherungsstand zeigt Noch keine Stichprobe. Die nächste Sicherung nimmt Stichproben aus Dateien, die unverändert bleiben. Ein Kopierjob kopiert einen solchen Sicherungsstand nicht.

Eine Restore-Prüfung belegt, dass sich ausgewählte Dateien zurücklesen lassen und unverändert sind. Sie belegt nicht, dass sich jede Datei zurücklesen lässt, und das wöchentliche restic check liest jedes Mal nur einen Teil des Repositorys. Die ausführliche Erklärung, was eine Prüfung belegt, steht unter Wie Restow prüft, ob eine Sicherung wiederherstellbar ist.

Das Repository einer Freigabe ist ein gewöhnliches restic-Repository, file-shares/<Freigabe-ID>/ im primären Repository des Mandanten (restics config, data/, index/, keys/ und snapshots/). Jeder Sicherungsstand enthält die Dateien unter /share und die Berechtigungen unter /.restow (acls.jsonl.gz und manifest.json). Mit dem Repository-Passwort (Passwort anzeigen unter Einstellungen, wird im Audit-Log festgehalten) und Zugriff auf den Speicher kann restic es öffnen und die Dateien wiederherstellen, ohne Restow. Die Berechtigungsdatei ist ein gzip von JSON-Zeilen mit den Sicherheitsdeskriptoren, und restic wendet sie nicht an: Eine Wiederherstellung ohne Restow bringt den Inhalt zurück, nicht die Berechtigungen. In 0.4.7 öffnet restow-restore das Repository einer Freigabe nicht für Sie. Bewahren Sie das Repository-Passwort an einem Ort außerhalb von Restow auf.