Backups und Zeitpläne

Verlauf und Fortschritt

Jeder Sicherungslauf steht unter Täglich → Verlauf mit Live-Fortschritt (erledigte/gesamte Elemente, Bytes, eine ETA), der der Web-Oberfläche über Server-Sent Events zugestellt wird. Bricht die Verbindung ab, verbindet Restow sich von selbst neu, und die Liste ist höchstens ein paar Sekunden veraltet. Ein Lauf kann wartend, läuft, abgeschlossen, mit Problemen abgeschlossen (einzelne Elemente scheiterten, der Lauf wurde aber beendet), fehlgeschlagen oder abgebrochen sein; eine Restore-Prüfung, die nicht abgeschlossen werden konnte, erscheint als Nicht abgeschlossen, wird wiederholt. Seit 0.4.7 zeigt eine Mail-&-SaaS-Sicherung, die Microsoft Graph oder der Speicher nach allen Wiederholungen gebremst hat, Vom Dienst gedrosselt, wird wiederholt (gelb, nicht Fehlgeschlagen), und eine für ein Objekt, das nicht mehr gesichert wird, zeigt Nicht gesichert: Konto deaktiviert, Nicht gesichert: keine Lizenz oder Nicht gesichert: gesperrt (neutral); keine davon ist ein Fehler, siehe Fehlererklärungen. Die Job-Seite nennt die Phasen einer SharePoint-Website-Sicherung (Liest die Website, Listen) und der Suche nach Websites und Gruppenpostfächern. Ein Abbruch stoppt beim nächsten Prüfpunkt; bereits Gespeichertes bleibt im Speicher, und die nächste Sicherung setzt am letzten abgeschlossenen Snapshot an, statt von vorn zu beginnen.

Fehlgeschlagene Elemente werden beim nächsten Lauf automatisch erneut versucht und bleiben mit ihrem Grund sichtbar; nach drei aufeinanderfolgenden Fehlschlägen desselben Elements löst Restow eine Warnung aus, statt endlos still weiter zu versuchen.

Drei Wege, eine Sicherung von Hand auszulösen, alle ausgehend vom Reiter Schutz des Einrichtungsbereichs (Mandanten-Einstellungen; ein Service Provider öffnet ihn für einen Mandanten mit Mandantenseite öffnen im Mandanten-Umschalter oder im Zeilenmenü von Mandanten → Mandanten verwalten):

Jetzt sichern für ein Objekt, auf der Seite, die der Link Je Objekt sichern öffnet: setzt am letzten Snapshot an; nur neue und geänderte Elemente werden gelesen (ein inkrementeller Lauf).
Vollsicherung, im Menü neben dieser Schaltfläche: liest alles erneut. Die Deduplizierung hält den zusätzlichen Speicherbedarf klein, dauert aber länger; nutzen Sie sie bei Verdacht auf Abweichungen, nicht routinemäßig.
Jetzt sichern auf dem Reiter Schutz selbst (Alle sichern im Verlauf und auf der Seite je Objekt): reiht je geschütztem Objekt des Mandanten einen Job ein; bereits eingereihte Objekte oder solche mit nicht verbundener Quelle werden übersprungen, nicht doppelt eingereiht.

Eine Sicherung, die für ein Objekt eingereiht ist, dessen Sicherung noch läuft (der nächste geplante Lauf, Jetzt sichern), wartet auf diese Sicherung und lässt jede andere durch. Vor 0.4.7 hielt ein solcher Job die Backup-Warteschlange aller Mandanten auf, bis die laufende Sicherung endete.

Die meisten ersten Sicherungen laufen aber ohnehin nicht so an: Sobald ein Objekt geschützt wird, sei es durch ein Einschließen (einzeln oder als Sammelaktion), einen Verzeichnisabgleich, der es neu aktiv findet, oder einen IMAP-Import, reiht Restow seine erste Sicherung automatisch ein, ohne auf einen Zeitplan zu warten. Siehe Die ersten Schritte.

Zeitpläne

Ohne Zeitplan läuft nichts von selbst. Unter Mandanten-Einstellungen → Jobs & Zeitpläne hat jeder eine Art, einen Rhythmus und einen Umfang:

Art	Was sie tut
Sicherung	Sichert jedes aktive geschützte Objekt oder ein gewähltes.
Verifizierung	Liest eine Stichprobe der letzten Sicherung über den Restore-Pfad zurück und vergleicht sie mit dem Manifest; solange ein Verifizierungs-Zeitplan aktiv ist, wird zusätzlich jede neue Sicherung verifiziert. Siehe Wie Restow prüft, ob eine Sicherung wiederherstellbar ist.
Integritätsprüfung	Prüft gespeicherte Packs auf Schäden und repariert sie aus Kopien; ein monatlicher (oder seltenerer) Lauf prüft alles, ein häufigerer eine Stichprobe. Ein Pack, das sie im Moment nicht lesen konnte (eine abgebrochene Übertragung, ein Berechtigungsfehler), wird als vorübergehend nicht lesbar gemeldet, nicht als beschädigt (seit 0.4.2, siehe Beschädigt oder vorübergehend nicht lesbar).
Verzeichnis-Sync	Liest Nutzer, Postfächer und OneDrives aus Entra ID, damit neu geschützte Personen von den Regeln erfasst werden.
Aufbewahrung	Wendet die Backup-Aufbewahrungsrichtlinien an, die Sie auf dem Reiter Aufbewahrung des Einrichtungsbereichs festlegen (ein Standard je Mandant plus Ausnahmen je Objekt). Der tägliche Lauf räumt Sicherungsstände ab, behält immer den neuesten abgeschlossenen Sicherungsstand jedes Objekts und räumt nichts ab, was unter Legal Hold steht. Seit 0.4.0 räumt er außerdem keinen Sicherungsstand eines Objekts ab, das einen ungeklärten verdächtigen Sicherungsstand hat (siehe Ransomware-Erkennung), und bei einem Repository mit unveränderbaren Backups lässt er einen Sicherungsstand in Ruhe, solange seine Sperre nicht abgelaufen ist. Derselbe tägliche Lauf verlängert die Sperren der Daten, die noch verwendet werden. Solange keine Richtlinie existiert, wird nichts davon entfernt.

Der Rhythmus ist entweder ein Preset (alle N Minuten/Stunden, täglich, an gewählten Wochentagen, monatlich an einem Tag des Monats, jeweils zu einer festen Ortszeit und Zeitzone) oder ein roher fünfteiliger Cron-Ausdruck, mit einer Live-Vorschau der nächsten Läufe und einem Mindestabstand von 15 Minuten zwischen ihnen. Empfohlene Zeitpläne übernehmen trägt in einem Schritt die für einen Mandanten fehlenden nach.

Restow zeigt unverblümt an, wenn der Schutz unvollständig ist: Kein Sicherungs-Zeitplan für alle geschützten Objekte bedeutet, dass Sicherungen nur laufen, wenn jemand sie von Hand startet; kein Verifizierungs-Zeitplan bedeutet, dass die Wiederherstellbarkeit dauerhaft unbewiesen bleibt, selbst wenn Sicherungen selbst weiter erfolgreich laufen.

Repositories und Kopien

Der Speicher-Standard der Installation (ab 0.2.1). Der Inhaber kann unter Installation → Standard-Repository & Netzlaufwerke einen lokalen Pfad oder einen S3-kompatiblen Bucket als Standardspeicher hinterlegen, mit frischer Anmeldung. Er wird vor dem Speichern durch einen Test geprüft, mit dem Master-Schlüssel versiegelt gespeichert und hat danach Vorrang vor STORAGE_* und S3_* aus der Umgebung; wird er entfernt, gilt wieder die Umgebung. Mandanten auf dem Standardspeicher bleiben durch eigenes Präfix und eigenen Schlüssel getrennt. Eine Änderung, die den Ort verschieben würde, wird abgelehnt, solange ein Mandant Daten darauf hat. Der Speicherbereich eines Mandanten bietet den Standardspeicher immer an, mit Speicher-Standard der Installation nutzen, solange das eigene Primärziel keine Daten hat. Ab 0.3.0 bindet der optionale Mounter dafür NFS-Freigaben über die Weboberfläche ein.

Unter Mandanten-Einstellungen → Repositories verwalten Sie, wo die Sicherungen eines Mandanten liegen. Die Sicherungen eines Mandanten werden in ein primäres Repository (Primärziel) geschrieben und optional in eines oder mehrere Kopie-Ziele, die dieselben Daten an einem anderen Ort erhalten (das klassische 3-2-1-Muster). Unterstützte Zieltypen:

Ein Serverpfad: das lokale Standard-Volume in den Containern, oder eine eingebundene NFS-Freigabe. Nur von Provider-Administrationen verwaltet.
S3-kompatibler Objektspeicher: Hetzner Object Storage, Amazon S3, Wasabi, Backblaze B2, Garage oder ein anderer S3-kompatibler Dienst, mit Voreinstellungen, die Endpunkt/Region/Adressierung für die bekannten Anbieter ausfüllen. Der Endpunkt muss HTTPS nutzen (siehe Verschlüsselte Übertragung (HTTPS)). Nur Buckets, die mit Object Lock angelegt wurden, lassen sich unveränderbar machen. Seit 0.4.2 setzt ein Lesezugriff auf S3, dessen Body mitten in der Übertragung abbricht (ein Restore, eine Restore-Prüfung oder die Speicherprüfung), ab dem ersten fehlenden Byte fort, gebunden an das ETag des Objekts, statt zu scheitern (Ein Pack lesen).

Das Testen eines Ziels schreibt, liest zurück und löscht ein kleines Objekt (und prüft bei einem lokalen Pfad zuerst das Verzeichnis). Der Test eines S3-Ziels erkennt zusätzlich, ob der Bucket Object Lock erzwingt, und zeigt Object Lock aktiv (WORM), oder sagt, dass der Bucket keines hat, dass der Anbieter es nicht unterstützt oder dass der Schlüssel die Object-Lock-Konfiguration des Buckets nicht lesen darf. Ein lokales oder NFS-Ziel trägt die Kennzeichnung „Kein Hardware-WORM“: Ein Dateisystem kann Unveränderbarkeit nicht erzwingen, und wer Zugriff auf den Server hat, kann seine Dateien ändern oder löschen. Ein Archiv dort ist nur durch Restow und die Hash-Kette geschützt. Ob die Backup-Daten eines Repositorys gesperrt werden, ist eine eigene Einstellung, die gleich folgt. Ein Ziel lässt sich erst nach einem erfolgreichen Test zum Primärziel befördern. Das Entfernen eines Ziels löscht dort bereits geschriebene Daten nie; das ist ein eigener Schritt beim Speicheranbieter, falls Sie sie wirklich entfernt haben wollen.

Eine Kopie prüfen vergleicht ihre Packs, Manifeste und verschlüsselten Schlüssel mit dem Primärziel und meldet, was (falls überhaupt) noch fehlt; neue Sicherungen erreichen die Kopie ab sofort sofort, und der Kopierjob spiegelt, was vor dem Hinzufügen der Kopie bereits vorhanden war.

Wo Sicherungen landen

Seit 0.4.2 nennt Restow das Repository, in das eine Sicherung geht, überall dort, wo Sie eine starten oder planen, damit es niemand nachschlagen muss: die Seite eines Gasts und ihr Dialog Jetzt sichern, die Job- und Verbinden-Dialoge für Proxmox VE, die Seite eines Rechners und einer Freigabe und die Job-Editoren. Eine Zeile sagt „Sicherungen landen in:“ und nennt das primäre Repository des Mandanten (ein Verzeichnis auf dem Server oder S3-kompatibler Objektspeicher, mit Pfad oder Bucket) oder Installationsstandard, wenn der Mandant kein eigenes primäres hat. Der Installationsstandard auf der lokalen Platte des Servers ist hervorgehoben als „Installationsstandard (lokale Platte des Servers)“, und sein Pfad wird nur Provider-Administratoren gezeigt. Ist der Installationsstandard nicht richtig eingerichtet, sagt die Zeile, dass Sicherungen nicht geschrieben werden können, bis der Anbieter ihn behebt oder ein primäres Repository hinzugefügt wird.

Die Warnung zur eigenen Platte des Servers. Ist das wirksame primäre Repository ein Verzeichnis auf einer Platte des Restow-Servers selbst und kein Netzwerkdateisystem wie NFS oder SMB (Restow liest dafür /proc/self/mountinfo für den Pfad und zählt den Installationsstandard ohne diese Datei als Platte des Servers), warnen der Bereich Repositories und die Dialoge, die Proxmox-VE-Knoten, Rechner und Freigaben hinzufügen: Sicherungen landen auf der eigenen Platte des Servers, mit einem Link zu Anderes Repository wählen. Fällt der Server oder seine Platte aus, sind die Sicherungen mit ihm verloren: Wählen Sie eine Netzwerkfreigabe oder einen S3-kompatiblen Objektspeicher, und siehe Restow selbst sichern.

Die Warnung zur Systemplatte (seit 0.4.5). Schlimmer als eine Platte des Servers ist seine Systemplatte, die Platte unter Betriebssystem, Docker und Datenbank: Füllen Sicherungen sie, stehen die Datenbank und Restow selbst still, nicht nur die Sicherungen. Die API erkennt das von innen aus ihrem Container, am Gerät und am Blockgerät des Pfads (ein Docker-Volume im Standard-Datenverzeichnis, ein Host-Verzeichnis auf der Root-Platte und ein Einhängepunkt, dessen Freigabe nicht eingehängt ist, zählen alle; eine vom Mounter eingehängte Freigabe oder ein Bind-Mount einer zweiten Platte nicht), den Installationsstandard und die Freigaben des Mounters eingeschlossen. Ein Verzeichnis-Repository auf der Systemplatte bekommt ein Badge Systemplatte und die Warnung „Sicherungen landen auf der Systemplatte des Servers“ auf der Seite Repositories, in der Zeile „Backups landen in“ der Job-Editoren und auf der Speicherkachel des Dashboards, wo Provider-Administratoren außerdem den freien Platz, seinen Verlauf der letzten Woche und den Tag sehen, an dem die Platte bei diesem Tempo voll wäre. Nichts wird blockiert; die API überwacht die Systemplatte auch auf knappen Speicherplatz (Datenbank). Legen Sie das Repository auf eine zweite Platte, eine Netzwerkfreigabe oder einen Objektspeicher.

Das primäre Repository ersetzen

Einen Mandanten auf ein anderes primäres Repository umzuziehen (eine größere Platte, ein anderer S3-Anbieter) ist ein normaler Vorgang, und Sicherungen und Wiederherstellungen laufen dabei weiter. Wählen Sie im Dialog, der ein Repository hinzufügt (Mandanten-Einstellungen → Repositories), statt Kopie die Rolle Primäres Repository ersetzen, und dann, wie die vorhandenen Backups umziehen:

Vorhandene Backups verschieben (empfohlen). Das neue Repository wird sofort als Kopie hinzugefügt, sodass jedes neue Backup es schon erreicht, und ein Hintergrundlauf kopiert alles, was vorher existierte: jedes Pack, jedes Backup-Manifest (von E-Mail und von den Sicherungsständen von VMs und Containern gleichermaßen), jeden umhüllten Mandantenschlüssel und, seit 0.4.2, die restic-Repositories der Container (pve-guests/<Gast-ID>/), Rechner (endpoints/<Endpoint-ID>/, auch widerrufene) und Freigaben (file-shares/<Freigaben-ID>/) des Mandanten. Jede Kopie wird gegen ihre Quelle geprüft, bevor das primäre Repository in einem Schritt umgeschaltet wird: Packs und Manifeste per SHA-256, eine Datei eines restic-Repositorys nach Größe und per SHA-256, mit dem restic sie benennt (restic benennt seine Daten-, Index-, Snapshot- und Schlüsseldateien nach dem Hash ihres Inhalts). config und die versiegelte Passwortdatei werden mit der Quelle verglichen, und die locks/ von restic werden übersprungen. Schaden an der Quelle lässt das Verschieben scheitern, statt sich zu verbreiten. Das Verschieben wartet vor dem Umschalten auf laufende Container-Sicherungen und Läufe von Dateifreigaben des Mandanten, und die Aufbewahrung von Containern und Freigaben wartet auf das Verschieben, damit keine restic-Datei unter ihm entfernt wird. Das alte Repository bleibt schreibgeschützt angebunden, bis Sie es von Hand entfernen, und es lässt sich nicht entfernen, solange es allein das Repository eines Containers, eines Rechners oder einer Freigabe hält.
Vorhandene Backups dort belassen, wo sie sind. Es wird nichts kopiert, und das neue Repository wird sofort zum primären. Seit 0.4.2 wird das abgelehnt, solange Container oder Freigaben des Mandanten restic-Repositories haben (storage-switch-blocked-by-repositories), und der Dialog bietet es gesperrt mit dem Grund an: Diese Repositories werden nur im primären Repository geschrieben und gelesen, nach einem solchen Wechsel fände also jeder Container und jede Freigabe ein leeres Repository auf dem neuen. Das geschah mit 0.4.1 und früher, als jeder Container mit vorhandenem Repository danach mit repository does not exist scheiterte (Neue Sicherungskette und Repository zurücksetzen). Das Befördern einer Kopie zum primären Repository wird aus demselben Grund abgelehnt, weil eine Kopie die restic-Repositories nie erhält. Wählen Sie für einen solchen Mandanten Vorhandene Backups verschieben (empfohlen). Widerrufene Rechner blockieren ein „Belassen“ nicht: Ihre Repositories werden nur gelesen, von dem Repository, das sie hält.
Aktive Rechner (Server und Clients) blockieren weiterhin jeden Wechsel des primären Repositorys (storage-active-endpoints), weil ein aktiver Agent weiter auf das alte primäre schreibt, während es kopiert wird: Widerrufen oder deinstallieren Sie sie zuerst, siehe Server und Clients.

Unveränderbare Backups (seit 0.4.0)

Die Karte jedes Repositorys hat einen Teil Unveränderbare Backups. Er ist aus, bis eine Administration ihn mit Unveränderbarkeit ändern einschaltet; beim Update wird nichts gesperrt. Bei einem Bucket, der mit Object Lock angelegt wurde, wählen Sie Compliance- oder Governance-Modus und 1 bis 3650 Tage (S3 Object Lock, vom Speicher durchgesetzt); bei einem Verzeichnis (dem Docker-Volume, einer NFS-Freigabe) gibt es nur eine Löschverzögerung, die Restow selbst einhält und die die Karte „nicht unveränderbar“ nennt. Das Einschalten von Object Lock prüft den Bucket und lehnt einen ohne Object Lock ab.

Was gesperrt wird: die Packs, abgeschlossenen Manifeste und umhüllten Schlüssel des Chunk-Stores (Microsoft 365, IMAP, Proxmox-VE-VM-Disks) und die Objekte data/, snapshots/, keys/ und config jedes restic-Repositorys (Rechner, Freigaben, Proxmox-VE-Container). Nicht gesperrt: Prüfpunkte, Staging, Exporte, Downloads und die restic-Dateien in locks/ und index/.
Verlängerung und Prüfung: Der tägliche Aufbewahrungslauf verlängert die Sperren der Daten, die neue Sicherungsstände noch verwenden, und fragt, wie Jetzt prüfen auf der Karte, den Speicher nach der Sperre einer Stichprobe. Die Karte zeigt Warnungen zuerst (Objekte ohne Sperre, eine Verlängerung, die überfällig ist oder fehlschlug), die Kachel Speicher im Dashboard zählt die unveränderbaren Repositories des Mandanten, und Sicherungsstände zeigen Unveränderbar bis <Datum>, grün nur bei einer Compliance-Sperre, die der Speicher selbst gemeldet hat.
Wer es ändern darf: Wer das Repository konfigurieren darf, kann den Schutz erhöhen. Ihn zu senken (weniger Tage, ein schwächerer Modus, aus) ist dem Provider-Inhaber mit einer Anmeldung aus den letzten 10 Minuten vorbehalten und gilt nur für Daten, die ab dann geschrieben werden. Änderungen stehen im Audit-Log als storage.target.immutability_changed.
Aufbewahrung und Platz: Ein Sicherungsstand, dessen Sperre nicht abgelaufen ist, wird von Aufbewahrung, Speicherbereinigung und restic prune nicht entfernt, sodass gelöschte Daten ihren Platz bis zu Zeitraum plus 7 Tage später freigeben.
Das Standard-Repository der Installation lässt sich in 0.4.7 nicht unveränderbar machen: Geben Sie dem Mandanten ein eigenes Repository oder eine unveränderbare Kopie.

Das ganze Bild, mit den Berechtigungen des Zugriffsschlüssels und dem, wovor es nicht schützt, steht unter Unveränderbare Backups.

Verschlüsselte Übertragung (HTTPS)

Ein S3-Repository sendet seine Zugriffsschlüssel (als Signaturen) und jedes Pack an den Speicherdienst, sein Endpunkt muss deshalb https:// sein. Seit 0.4.0 wird ein neuer oder geänderter Endpunkt über unverschlüsseltes http:// mit dem Grund endpoint_insecure („nur HTTPS“) abgelehnt, wenn Sie ein Repository anlegen, seinen Ort ändern, Einstellungen im Formular testen oder den Standard der Installation speichern. Die eine Ausnahme braucht keine Einstellung: http:// zum Rechner selbst (localhost, 127.0.0.1, [::1]), wo nichts über ein Netzwerk läuft.

Vor 0.4.0 gespeicherte Endpunkte laufen weiter. Backups, Restores, Tests, Kopien und Umzüge von ihnen weg laufen weiter, ebenso S3_ENDPOINT aus der Umgebung. Die Karte des Repositorys zeigt in Rot, dass es unverschlüsseltes HTTP nutzt und auf HTTPS umziehen sollte, Installation → Standard-Repository & Netzlaufwerke sagt dasselbe für einen gespeicherten Standard und für S3_ENDPOINT, und jeder Test trägt eine Warnung. Eine reine Namensänderung geht weiter; eine Ortsänderung braucht https://. Bleiben Speicherdienst und Bucket gleich, ist das Umstellen des Endpunkts auf HTTPS eine gewöhnliche Änderung, keine Migration.
Test- und Entwicklungsumgebungen, deren Objektspeicher im Compose-Netzwerk liegt (http://garage:3900), setzen S3_ALLOW_INSECURE=true in der .env (api und worker). Es akzeptiert http:// zu jedem Host und entfernt die roten Hinweise. Setzen Sie es nicht in der Produktion.
Mandanten-Administrationen können ein Repository nur auf einen öffentlichen HTTPS-Endpunkt zeigen lassen, unabhängig von der Einstellung.

Statistik und Berichte

Unter Täglich → Übersicht, Reiter Statistik (Administratoren), werden Sicherungsergebnisse, Restores, Speichervolumen und -wachstum, Wiederherstellbarkeit und (für Microsoft 365) Drosselungs-Wartezeiten als Verläufe über einen gewählten Zeitraum angezeigt (7/30/90 Tage, 12 Monate oder ein benutzerdefinierter Bereich), bezogen auf den aktiven Mandanten. Sicherungen, die ein Dienst gebremst hat, und Sicherungen von Objekten, die nicht mehr gesichert werden, stehen nicht in den Fehlerzählern der Statistik und des Dashboards (seit 0.4.7). In der Service-Provider-Edition haben die Statistiken aller Mandanten eine eigene Seite (seit 0.3.1, im Bereich Installation des Menüs: Statistik aller Mandanten). PDF exportieren erzeugt einen formatierten Bericht für den Zeitraum (dieselben Zahlen, aufbereitet zur Ablage oder zur Weitergabe an einen Kunden); Als CSV herunterladen exportiert den zugrunde liegenden Datensatz hinter einem Diagramm. Beides wird serverseitig erzeugt; dafür wird nichts über die Installation irgendwohin sonst gesendet.

Belegungszahlen (seit 0.4.1). Repositories → Belegung zählt unter Gespeichert die Packs des Chunk-Stores und auch die restic-Repositories von Rechnern, Freigaben und Proxmox-VE-Containern und sagt, wie viel davon wo liegt. Die Einsparung durch Deduplizierung, der Zuwachs und das Diagramm Chunk-Store pro Tag sind Zahlen des Chunk-Stores allein, weil ein restic-Repository keinen Verlauf führt. Das Repository eines Containers zählt ab seiner nächsten Sicherung, und Geschützte Daten nennt die Quellen, die es nicht einschließt (Rechner, Freigaben und Container).

Audit

Das Hinzufügen, Testen, Bearbeiten oder Befördern eines Repositorys sowie jede geplante oder manuelle Sicherung wird im Audit-Log erfasst.