← Alle Funktionen

Proxmox-VE-Backup (Preview)

Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am 2026-10-29

Restow sichert die virtuellen Maschinen und Container von Proxmox VE ab 8.4 über die Backup-Provider-API von Proxmox. Es ist eine Preview, seit 0.3.1 verfügbar und in jeder Edition, auch in Community. Als einzige Sicherung wird es noch nicht empfohlen: Die Grenzen stehen unten, direkt neben der Funktion.

Wie VMs und Container gesichert werden

VM-Festplatten gehen über NBD mit Dirty Bitmaps, sodass nur geänderte 4-MiB-Blöcke hochgeladen werden. Container gehen über restic. Die Backups liegen in einem Repository Ihrer Wahl, siehe Speicher.

Die Knotenseite hat zwei Teile: einen Storage-Plugin-Shim, der ein eigenes Werk unter AGPL-3.0-or-later ist, und den Helfer restow-pve, der unter Apache-2.0 steht. Gäste zählen bei der Wiederherstellbarkeit, bei Warnungen und bei Alarmen für überfällige Sicherungen (backup.overdue) mit, es sei denn, ein Administrator hat sie bewusst ausgeschlossen (seit 0.4.7, siehe einen Gast ausschließen).

Restore

Ein Restore legt eine neue VMID im Pool restow-restore an. Die allgemeinen Restore-Regeln stehen auf der Restore-Seite.

Der Restore eines Containers funktioniert seit 0.4.6 auf aktuellem Proxmox VE: Vorher scheiterten ein Container-Restore, eine Startprüfung eines Containers und „Als neuen Gast wiederherstellen“ eines Containers auf aktuellem Proxmox VE mit Can't use string ("restow") as a HASH ref, weil es die Storage-ID vor dem Info-Hash an den Backup-Provider übergibt; VMs waren nicht betroffen. Die Korrektur steckt im Plugin von restow-pve: Aktualisieren Sie restow-pve auf jedem Knoten, bevor Sie sich auf Container-Restores oder Startprüfungen verlassen. Für Sicherungsstände von Containern, die „Nicht gestartet“ zeigen oder eine fehlgeschlagene Restore-Prüfung aus der Zeit vor 0.4.3 haben, führen Sie „Jetzt Start prüfen“ oder „Jetzt prüfen“ aus, sobald der Knoten aktualisiert ist.

Einen Knoten anbinden

Seit 0.3.2 bindet ein Befehl einen Knoten an, mit dem Enrollment-Token darin. Der Knoten-Installer richtet den Benutzer restow@pve, die Rollen und den Restore-Pool selbst ein, legt einen eigenen API-Token an, prüft seine Rechte, bevor er etwas installiert, und wählt den Thin-Speicher für Fleecing selbst. Stattdessen lässt sich ein vorhandener Proxmox-VE-API-Token verwenden. Restow bewahrt dessen ID und Geheimnis verschlüsselt nur so lange auf, bis sich der Knoten damit angemeldet hat oder das Enrollment-Token abläuft, und übergibt sie diesem Knoten einmal. Für den nächsten Knoten erzeugen Sie in Restow einen weiteren Befehl.

Seit 0.4.0 aktualisiert sich restow-pve selbst, solange kein Backup oder Restore läuft; restow-pve update auf dem Knoten tut es von Hand. Seit 0.4.2 nimmt das Update des Servers die Knoten mit, und seit 0.4.3 startet „Knoten und Agenten jetzt aktualisieren“ diesen Schritt von Hand, siehe Knoten ziehen bei einem Server-Update nach.

Knoten, VMs und Container im Inventar

Seit 0.3.3 erscheint jeder Proxmox-VE-Knoten unter Server & Clients, Inventar, als aufklappbare Zeile. Sie zeigt den Online-Zustand des Knotens und Zahlen: geschützt, fehlgeschlagen, kein Job, noch nicht gesichert und, seit 0.4.7, ausgeschlossen („Ausgeschlossen: N“). Aufgeklappt zeigt jede VM und jeder Container Status, Backup-Job und Sicherungszustand und, wenn die letzte Sicherung fehlschlug, den Grund, verlinkt auf die eigene Seite des Gasts. Das Inventar ist für Administratoren, sobald ein Cluster verbunden ist. Die Seite VMs & Container zeigt, wenn eine Sicherung auf ihren Knoten wartet, und solange sie läuft.

Seit 0.3.4 scheitern Sicherungen nicht privilegierter Container auf ext4 nicht mehr am Ordner lost+found, und eine Container-Sicherung, die restic nicht vollständig lesen konnte (Exit-Code 3), behält ihren Sicherungsstand und nennt die nicht lesbaren Elemente.

Was jedes Backup enthält

Seit 0.3.5 haben VMs & Container und das Inventar eine Spalte „Sicherung“. Sie sagt, was der neueste Wiederherstellungspunkt enthält und was sein Lauf hinzugefügt hat, zum Beispiel „9,4 GB im Backup, +2,5 MB neu im letzten Lauf“, und zeigte das erste Backup beim Daraufzeigen. Seit 0.4.7 zeigt die Spalte des Inventars zwei weitere Zeilen als Text in der Zeile des Gasts, nicht nur beim Daraufzeigen, sodass sich beides lesen und kopieren lässt: die Größe der ersten Sicherung des Gasts („Erste Sicherung am <Datum>: <Größe> gespeichert“) und was eine Folgesicherung im Durchschnitt hinzufügt („Durchschnitt je Folgesicherung: +<Größe> (letzte N Sicherungen)“). Die frühere Spalte „Größe“ heißt jetzt „Disk“. Auf der eigenen Seite eines Gasts zeigen die Wiederherstellungspunkte ihren Typ (erstes Backup, inkrementell oder vollständig gelesen), was sie enthalten und was sie hinzugefügt haben. Die erste Sicherung der neuen Sicherungskette eines Containers heißt seit 0.4.6 „Erste Sicherung“, nicht „Inkrementell“. Seit 0.4.3 lautet die Spalte in VMs & Container anders, siehe Reiter, Filter und ein Detailbereich.

Eine Container-Sicherung, die restic nicht vollständig lesen konnte, erscheint als „Mit Lücken erfolgreich“ („Letzte Sicherung unvollständig“ auf der Seite des Gasts), mit der Zahl der nicht lesbaren Elemente, und zählt im Inventar als „Unvollständig“.

„Jetzt sichern“ und Restore sagen, dass der Knoten die Aufgabe bei seiner nächsten Meldung (Check-in) startet. Ein zweiter Klick sagt, dass schon eine Sicherung wartet, und die Seiten aktualisieren sich alle 5 Sekunden, solange ein Gast auf seinen Knoten wartet oder gesichert wird.

Gäste direkt im Inventar schützen

Seit 0.3.6 lassen sich Gäste schützen, ohne das Inventar zu verlassen. Im aufgeklappten Knoten hat jede VM und jeder Container seinen Backup-Job als Auswahl: ein vorhandener Job, „Kein Backup-Job“ oder „Neuer Job …“. „Jetzt sichern“ startet eine Sicherung dieses Gasts.

Um mehrere Gäste zugleich zu bearbeiten, kreuzen Sie sie einzeln an, nehmen mit dem Kästchen in der Kopfzeile alle Gäste des Knotens oder wählen mit „Auswählen“ neben „N VMs und Container haben keinen Backup-Job“ alle Gäste ohne Job mit einem Klick aus. Danach fügen Sie die Auswahl einem Job hinzu („Zu Job hinzufügen …“) oder sichern die Gäste mit „Jetzt sichern“ gemeinsam. „Neuer Job …“ öffnet den Job-Dialog und legt die Auswahl in den neuen Job. Der Knoten startet eine angeforderte Sicherung bei seiner nächsten Meldung, meist innerhalb einer Minute.

Die Schutzspalte des Inventars heißt jetzt „Schutz“; sie trug zuvor dieselbe Überschrift „Sicherung“ wie die Spalte, die zeigt, was der neueste Wiederherstellungspunkt enthält.

Einen Gast bewusst von der Sicherung ausschließen

Viele Gäste eines Clusters sollen nicht gesichert werden, etwa Test-VMs oder Gäste, die anderswo gesichert werden. Ein Gast in keinem Backup-Job zählt in den Übersichten als „Kein Backup-Job“ und hält den Mandanten vom Grün ab, es sei denn, ein Administrator hat ihn bewusst ausgeschlossen (seit 0.4.7). Mandanten-Administratoren und die Administratoren des Provider-Teams dürfen eine VM oder einen Container ausschließen: „Von der Sicherung ausschließen“ steht auf der Seite des Gasts und, für eine Auswahl der Gäste eines Knotens, im Inventar; „Wieder einschließen“ nimmt es zurück, auf der Seite und in der Inventar-Zeile des Gasts. Nichts wird von selbst ausgeschlossen. Wie das übrige Proxmox-VE-Backup ist das eine Preview, in jeder Edition, auch in Community.

• Kein Job sichert ihn, auch nicht der Job für alle Gäste, und der empfohlene Job lässt ihn aus. Sein eigener Job bleibt gespeichert, sodass das Wiedereinschließen wiederherstellt, was er hatte. Das Ausschließen zieht seine wartenden Sicherungen zurück; „Jetzt sichern“ und das Aufnehmen des Gasts in einen Job werden abgelehnt, bis er wieder eingeschlossen ist.
• Er zählt nirgends als ungeschützt: nicht in den Übersichten, der Wiederherstellbarkeit, den Warnungen, backup.overdue, der Statistik oder der Provider-Ansicht (und nicht in „N VMs und Container haben keinen Backup-Job“), und er hält nie einen Mandanten vom Grün ab. Die Gästezahlen führen ihn als ausgeschlossen, und das Inventar zeigt „Ausgeschlossen: N“ je Knoten. In VMs & Container steht er als „Ausgeschlossen“ (grau, nie ein Problem) und hat einen eigenen Zustandsfilter.
• Seine Sicherungsstände bleiben. Sie bleiben wiederherstellbar, und die Aufbewahrung behandelt sie wie bisher. Die wöchentliche Prüfung seines neuesten Sicherungsstands läuft weiter; die monatliche Restore-Prüfung des Jobs und die Startprüfungen erfassen ihn nicht mehr.

Die Änderung steht im Audit-Log als pve.guest.excluded; die API-Route ist PUT /api/v1/pve/guests/:id/excluded. restow-pve braucht dafür kein Update.

VMs & Container: Reiter, Filter und ein Detailbereich

Seit 0.4.3 hat VMs & Container drei Reiter mit Zahlen: Gäste (der Standard), Backup-Jobs und Knoten.

• Suche und Filter. Die Gästetabelle durchsucht ID und Namen und filtert nach Knoten, Art (VM oder Container), Backup-Job (auch „Kein Backup-Job“) und Zustand. „Nur Probleme“ zeigt die Gäste, die einen Blick brauchen: ein fehlgeschlagener Lauf, Warnungen oder Lücken, eine Restore-Prüfung, die fehlschlug oder nicht laufen konnte, das Warten auf einen getrennten oder angehaltenen Knoten oder gar keine Sicherung. Die Spalten lassen sich sortieren (ID, Name, Knoten, letzte Sicherung, Größe der Sicherung, Zustand), Seiten fassen 25 bis 250 Gäste, und die Tabelle nennt, wie viele Gäste die Filter übrig lassen. Reiter, Suche, Filter, Reihenfolge, Seite und der geöffnete Gast stehen in der Adresse, ein Link öffnet also dieselbe Ansicht.
• Ein Zustand je Zeile. Eine Zeile zeigt ein Zustandskennzeichen, nach Priorität gewählt, mit einem kleinen Fortschrittsbalken, solange ihre Sicherung läuft, oder „+N“, wenn weitere Zustände zutreffen. Grün bleibt dem Nachweis vorbehalten: Nur eine Restore-Prüfung, die den neuesten Sicherungsstand zurückgelesen hat, ist grün („Restore-Prüfung bestanden“), und eine Sicherung, die nur erfolgreich war, ist ein schlichtes „Gesichert“.
• Detailbereich. Ein Klick auf eine Zeile (oder ihren Namen) öffnet einen Bereich mit jedem Zustand des Gasts, dem vollständigen Fehler und den Warnungen des letzten Laufs in einem scrollbaren Block, der sich kopieren lässt, der Restore-Prüfung mit dem, was sie gefunden hat, den Größen, dem Backup-Job, den neuesten Läufen und den Aktionen: jetzt sichern, stoppen, zurückziehen, jetzt prüfen und die Seite des Gasts öffnen.
• Die Spalte „Sicherung“ lautet zum Beispiel „Erste: 32 GB am 3. Okt. · Letzte: +210 MB“: wie groß die erste (volle) Sicherung war und was die letzte Folgesicherung hinzugefügt hat. Was der neueste Sicherungsstand enthält, steht im Tooltip, und der Bereich zeigt die neuen Daten jeder der letzten 30 Sicherungen als kleine Balken.
• Kein Springen mehr. Die Tabellen der Gäste und Jobs behalten feste Spaltenbreiten und eine Zeilenhöhe, lange Texte werden auf eine Zeile gekürzt, und „Jetzt sichern“, „Stoppen“, „Zurückziehen“ und „Wird gestoppt…“ haben dieselbe Größe, die Seite bewegt sich also nicht mehr, während Backups laufen. Fehlertexte stehen nicht mehr in Rot unter einer Zeile, und Warnungen stehen nicht mehr nur in einem Tooltip.

Der Reiter Knoten zeigt je Knoten den Heartbeat, die Version von restow-pve mit „Auf … aktualisieren“, wenn der Server ein neueres Release anbietet, die Version von Proxmox VE, wie viele Gäste der Knoten hat, seine Warteschlange und seine Probleme. Die Steuerung der Warteschlange und das Widerrufen stehen im Zeilenmenü. Der Hinweis, dass der Proxmox-VE-Host selbst nicht gesichert wird (seine eigenen Dateien sichert der Restow-Agent auf dem Host), ist eine Zeile auf diesem Reiter und lässt sich ausblenden.

Fortschritt, Lauf-Log und Jobs

Seit 0.4.0 zeigen VMs & Container, das Inventar und die Seite eines Gasts den Fortschritt eines laufenden Backups, zum Beispiel „34 % · 3,2 GB von 9,4 GB · 85 MB/s“. Es braucht restow-pve 0.4.0 auf dem Knoten; seit 0.4.1 sagt ein Backup auf einem älteren Knoten, dass der Fortschritt restow-pve 0.4.0 auf diesem Knoten braucht und welche Version der Knoten hat, statt für seinen ganzen Lauf „Noch kein Fortschritt gemeldet“ zu zeigen. Die eigenen Zeilen des Helfers erreichen jetzt das Log, das Restow zum Lauf führt: die Lauf-ID, was restic hinzugefügt hat, was es nicht lesen konnte und den Commit des Sicherungsstands. Ein Backup, das mit Lücken erfolgreich war, nennt die ersten 20 Elemente, die restic nicht lesen konnte.

Proxmox-VE-Jobs stehen unter Server & Clients, Jobs, neben den Rechner-Jobs, mit einer Spalte Typ: die Gäste jedes Jobs, der Zeitplan, der letzte und der nächste Lauf, „2 von 5 Gästen fertig“, während eine Runde läuft, und ein von Hand gestartetes Backup als Zeile „Manuelle Sicherung“, bis es endet. „Neuer Job“ ist ein Menü mit einem Eintrag je Typ. Neben jedem Hinweis „kein Job“ zeigt „Empfohlenen Job anlegen“ eine Vorschau, was der Klick anlegt oder erweitert, und legt dann einen Job je Art an (für Proxmox VE: einen Job, täglich um 22:00 im Snapshot-Modus); ein zweiter Klick erweitert denselben Job, statt einen neuen anzulegen. Das ist für Administratoren und im Audit-Log festgehalten. Die Seite eines Gasts zeigt auch, was ein Folge-Backup im Schnitt hinzufügt.

Seit 0.4.2 bietet der Zeitplan eines Proxmox-VE-Jobs die Rhythmen eines Mail-Jobs: alle paar Stunden, täglich, an gewählten Wochentagen, monatlich oder als Cron-Ausdruck, in einer Zeitzone und nicht öfter als stündlich. Ein Backup, das vzdump mit Warnungen beendet (zum Beispiel „TASK WARNINGS: 1“), nachdem sein Sicherungsstand festgeschrieben war, zählt als „Erfolgreich mit Warnungen“, in Bernstein, nicht als fehlgeschlagen; restow-pve 0.4.2 fragt außerdem vzdump nicht mehr nach Notizen, die diese Warnungen auslösten.

Ein Backup, das läuft, während Restow aktualisiert wird, schlägt nicht mehr fehl: Der Knoten (restow-pve 0.4.0) versucht es fünf Minuten lang weiter, wo er vorher nach etwa 30 Sekunden aufgab, und ein Backup-Lauf, dessen Ende den Server nie erreichte, wird geschlossen, sobald der Knoten ihn nicht mehr meldet, statt 48 Stunden „läuft“ zu zeigen. restow-pve aktualisiert sich jetzt selbst: Es fragt zwei Minuten nach seinem Start (seit 0.4.1) und dann alle sechs Stunden und aktualisiert, solange kein Backup oder Restore läuft; restow-pve update tut es von Hand. Ältere Helfer laufen weiter, ohne Fortschritt, ohne die Wiederholung über fünf Minuten und ohne die Liste der aktiven Läufe.

Eine Sicherung stoppen

Seit 0.4.2 lässt sich eine Sicherung in der Weboberfläche stoppen, ohne SSH auf dem Knoten. Wer eine Sicherung starten darf, darf sie stoppen, jedes Stoppen fragt vorher nach, und es wird im Audit-Log festgehalten.

• Sicherung stoppen gibt es in der Tabelle VMs & Container, auf der Seite des Gasts und in der Lauf-Schublade. Eine Sicherung, die noch auf ihren Knoten wartet, wird sofort zurückgezogen („Zurückziehen“): Der Knoten sieht sie nie, und der Verlauf zeigt einen Lauf „Abgebrochen von <Benutzer>“. Eine, die der Knoten schon bekommen hat oder die läuft, bekommt eine Abbruch-Anforderung, und die Seite zeigt „Wird abgebrochen…“, bis der Knoten sie gestoppt hat.
• Wie der Knoten sie stoppt. restow-pve 0.4.2 hält seinen Heartbeat aufrecht, während eine Sicherung läuft, alle 15 Sekunden, und bekommt den Abbruchauftrag damit. Bei einer Sicherung, die Restow angefordert hat, beendet der Knoten die vzdump-Aufgabe über die Proxmox-VE-API; vzdump beendet die Sicherung des Gasts und entfernt seinen Snapshot und das Fleecing-Image. Eine in Proxmox VE selbst gestartete Sicherung, durch einen Proxmox-VE-Backup-Job mit mehreren Gästen, wird nur für diesen Gast gestoppt, und vzdump macht mit den anderen weiter.
• Wie sie endet. Der Lauf endet als „Abgebrochen“, nicht als fehlgeschlagen: kein Fehleralarm, kein „Letzte Sicherung fehlgeschlagen“, die letzte Sicherung des Gasts bleibt, wie sie war, und von dem gestoppten Lauf wird nichts festgeschrieben, die vorhandenen Sicherungsstände bleiben also unberührt.
• Je Knoten und je Mandant. „Warteschlange anhalten“ auf einem Knoten gibt ihm keine neue Sicherung mehr, bis die Warteschlange fortgesetzt wird; eine laufende Sicherung läuft weiter, und geplante Sicherungen warten (und verfallen wie gewohnt nach 12 Stunden). „Alle wartenden zurückziehen“ zieht jede Sicherung zurück, die noch nicht begonnen hat, für einen Knoten oder für den ganzen Mandanten.

Eine laufende Sicherung zu stoppen braucht restow-pve 0.4.2 auf dem Knoten. Ein Knoten vor 0.4.2 beendet eine abgebrochene Sicherung bei seinem nächsten Upload, weil der Server jeden Upload eines abgebrochenen Laufs ablehnt.

Knoten ziehen bei einem Server-Update nach

Läuft der Server mit einem neuen Release, bleiben seit 0.4.2 neue Läufe angehalten, während Proxmox-VE-Knoten und Agenten es installieren (sie sind dann frei), bis jeder erreichbare die neue Version meldet oder 15 Minuten vergangen sind. Installation › Updates zeigt den Fortschritt und nennt für einen nicht erreichten Knoten den Befehl für ein Update von Hand (/opt/restow-pve/bin/restow-pve update, als root). „Auf <Version> aktualisieren“ an einem Knoten, in der Knotentabelle neben seiner Version, fordert das Update jederzeit an; der Knoten installiert das signierte Release, sobald er frei ist, und startet neu. Proxmox VE selbst aktualisiert Restow nie.

Seit 0.4.3 startet „Knoten und Agenten jetzt aktualisieren“ auf der Karte der Knoten und Agenten unter Installation › Updates diesen Schritt von Hand. Das ist für einen Server gedacht, der ein neueres Release als seine Knoten und Agenten ausführt, obwohl kein Update in den Schritt geführt hat, in dem sie ihm folgen: Der Server wurde von Hand aktualisiert, oder die Antwort auf die Ankündigung eines Updates ging verloren. Knoten und Agenten, die zurückliegen, zeigen „Update verfügbar“. Ein Administrator mit Zugriff auf alle Mandanten startet es; neue Läufe werden höchstens 15 Minuten angehalten, erreichbare Knoten und Agenten installieren das Release, sobald sie frei sind, und die Pause endet, sobald sie fertig sind. Es wird im Audit-Log festgehalten. Ein falsches „Der Updater läuft nicht“ nach der Ankündigung eines Updates, das auch diesen Schritt übersprang, ist behoben: Der Server wartet jetzt bis zu einer Minute auf die Antwort des Updaters.

restow-pve startet jetzt die Proxmox-VE-Daemons, die sein Storage-Plugin laden (pvedaemon, pveproxy, pvestatd und pvescheduler), nach seinem eigenen Update neu, wie es der Installer tut; restow-pve update startet zusätzlich den Dienst restow-pve neu. Ein Knoten, den ein älteres restow-pve aktualisiert hat, startet die Daemons nach dem Start des neuen Releases einmal von selbst neu. Knoten mit restow-pve 0.4.1 reagieren weder auf „jetzt aktualisieren“ noch auf den Nachzieh-Schritt: Sie aktualisieren sich mit ihrer eigenen Prüfung (zwei Minuten nach dem Start des Dienstes, danach alle sechs Stunden) oder von Hand, sobald auf dem Knoten kein Backup und kein Restore läuft. Führen Sie als root /opt/restow-pve/bin/restow-pve update aus, danach systemctl restart restow-pve pvedaemon pvestatd pveproxy pvescheduler.

Wo Sicherungen landen, und eine neue Sicherungskette

Die Seite des Gasts, ihr Dialog „Jetzt sichern“, der Job-Dialog und der Anbindungsdialog nennen das wirksame primäre Repository des Mandanten, mit dem Installationsstandard auf der lokalen Platte des Servers hervorgehoben, und warnen „Sicherungen landen auf der eigenen Platte des Servers“, wenn das primäre Repository ein Verzeichnis auf einer Platte des Restow-Servers selbst ist (siehe Speicher).

Das restic-Repository eines Containers liegt nur im primären Repository. Seit 0.4.2 prüft der Server vor jeder Container-Sicherung, bevor sie ihren restic-Zugang bekommt, einmal je Lauf, ob das Repository dort liegt:

• Es liegt dort: Die Sicherung läuft wie immer.
• Nur auf einem anderen Ziel des Mandanten, zum Beispiel einem ausgemusterten primären Repository nach „Vorhandene Backups dort belassen, wo sie sind“: Die Sicherung wird mit einer Meldung abgelehnt, die sagt, die Sicherungen im Speicher mit „Vorhandene Backups verschieben“ umzuziehen oder das Repository zurückzusetzen. Es wird nichts angelegt.
• Nirgends: Ein neues Repository und eine neue Sicherungskette beginnen. Die Seite des Gasts sagt „Neue Sicherungskette am <Datum> begonnen: Das vorherige Repository wurde auf <Ziel> nicht gefunden“, die früheren Sicherungsstände zeigen „Nicht verfügbar“ (sie lassen sich nicht mehr wiederherstellen, durchsuchen oder prüfen, die Wiederherstellbarkeit zählt sie nicht mehr, und die Aufbewahrung lässt sie in Ruhe), und das Audit-Log hält es fest. Ein Speicher, der nicht antwortet, gilt nicht als „fehlend“: Die Sicherung schlägt dann fehl.

„Repository zurücksetzen“ im Gefahrenbereich des Gasts (nur Container) tut dasselbe auf Wunsch, für ein beschädigtes Repository oder eines auf einem Ziel, das es nicht mehr gibt: Der Name des Gasts wird eingetippt, es braucht eine frische Anmeldung, und es wird im Audit-Log festgehalten. Jeder Sicherungsstand des Containers wird sofort nicht verfügbar, und die nächste Sicherung beginnt eine neue Kette. Vor 0.4.2 scheiterte jeder Container mit vorhandenem Repository nach einem Wechsel des primären Repositorys mit „Vorhandene Backups dort belassen, wo sie sind“ mit „repository does not exist“; diese Wahl wird jetzt abgelehnt, solange Container restic-Repositories haben, und „Vorhandene Backups verschieben“ nimmt sie mit.

Die VM des Restow-Servers selbst

Die VM, auf der Restow läuft, mit Restow selbst zu sichern, kann in eine Sackgasse führen: Die Sicherung friert den Server ein oder macht einen Snapshot von ihm, obwohl er sie entgegennimmt, und ihr Restore braucht genau den Server, der wiederhergestellt wird. Seit 0.4.2 erkennt Restow diese VM an ihrer SMBIOS-UUID (restow-pve 0.4.2 meldet sie mit dem Inventar), oder ein Administrator setzt auf der Seite des Gasts den Haken „Dies ist der Restow-Server“, nötig, wenn Restow in einem Container, auf einem anderen Host oder hinter einem Knoten vor 0.4.2 läuft. Der Gast zeigt dann „Restow-Server“ in den Listen und im Job-Editor, kein Job plant eine Sicherung von ihm, der empfohlene Job lässt ihn aus, und „Jetzt sichern“ oder das Aufnehmen in einen Job braucht eine Bestätigung, die das Risiko nennt. Sichern Sie diese VM mit dem Backup von Proxmox VE (vzdump) auf einen anderen Speicher und bewahren Sie die Datenbank-Dumps von Restow auf.

Dateien eines Containers oder einer VM (bei VMs eine Preview)

Server & Clients, Datei-Restore listet jeden Container mit einem Sicherungsstand in der Gruppe „Proxmox-VE-Container“ und jede VM mit einem Sicherungsstand in der Gruppe „Proxmox-VE-VMs“, als Preview gekennzeichnet. Die Seite eines Gasts verlinkt seine Sicherungsstände dorthin („Dateien durchsuchen“). Sie durchsuchen einen Sicherungsstand und laden Dateien und Ordner als ein ZIP herunter. Lesen und Herunterladen stehen im Audit-Log, und ein vorbereiteter Download lässt sich einmal innerhalb von zehn Minuten von dem Administrator starten, der ihn vorbereitet hat.

• Container liest der Server aus dem restic-Repository des Containers; die Pfade sind die des Containers selbst.
• VMs zeigen einen Ordner je lesbarem Dateisystem der Datenträger der VM: Partitionen von GPT- und MBR-Datenträgern und lineare logische LVM-Volumes mit ext2, ext3, ext4 (das Journal wird im Speicher abgespielt), XFS, NTFS oder FAT12, FAT16, FAT32. Der Restow-Server liest die Datenträger mit eigenen Lesern in einem kurzlebigen, eingeschränkten Kindprozess aus dem Chunk-Store des Mandanten; nichts wird eingebunden, weder auf dem Server noch auf dem Knoten. Dateien, die sich nicht lesen lassen, werden in _not-restored.txt im ZIP benannt.

In einer VM nicht lesbar: btrfs, ZFS, ReFS, LVM thin, RAID, BitLocker und LUKS, NTFS-komprimierte und EFS-Dateien. Das XFS-Log und das NTFS-Log werden nicht abgespielt, ein absturzkonsistenter Sicherungsstand kann also die letzten Schreibvorgänge vermissen lassen: Vergleichen Sie eine wichtige wiederhergestellte Datei mit dem Original, bevor Sie sich darauf verlassen. Dateien werden heruntergeladen, nicht in einen laufenden Gast zurückgelegt; stellen Sie dafür den ganzen Gast als neuen Gast wieder her. Restore-Operatoren können Dateien von Containern und VMs ebenfalls durchsuchen und herunterladen.

Startprüfungen

Ein Proxmox-VE-Job kann den neuesten Sicherungsstand jedes Gasts starten, wöchentlich oder nach jedem Backup. Sie ist standardmäßig aus, mit einem Speicherlimit (standardmäßig 8 GiB) und einer Wartezeit auf den Guest Agent (standardmäßig fünf Minuten), und „Jetzt Start prüfen“ an einem Sicherungsstand fordert eine von Hand an. Der Knoten des Gasts stellt den Sicherungsstand als neuen Gast im Pool restow-restore wieder her, isoliert ihn vor dem Start (jede Netzwerkschnittstelle getrennt oder an einer isolierten Bridge; Passthrough-Geräte, serielle Ports, Bind-Mounts und das Hook-Skript entfernt), startet ihn, wartet auf den QEMU Guest Agent (bei einem Container: seinen Init) und zerstört den Test-Gast in jedem Fall; Überbleibsel werden beim Start des Dienstes entfernt. Je Knoten läuft ein Test zur Zeit, nie neben einem Backup, und nur mit genug Speicher und Platz.

Das Ergebnis ist grün, wenn der Guest Agent geantwortet hat, gelb, wenn die VM nur gestartet ist und nichts geantwortet hat (installieren Sie den QEMU Guest Agent für einen Nachweis), und rot, wenn die Wiederherstellung, der Start oder der Boot fehlgeschlagen ist. Die Wiederherstellbarkeit bewertet den neuesten Sicherungsstand nach seiner Startprüfung, wo es eine gibt, und zwei Ereignisse, boot_test.failed und boot_test.unproven, können Sie alarmieren. Sie braucht restow-pve 0.4.0 auf dem Knoten, und die Seite des Gasts sagt, wenn sein Knoten es nicht kann. Sie prüft keine Ports oder Anwendungen im Gast, Windows ohne Guest Agent ist höchstens gelb, und ein Gast, der Passthrough-Hardware zum Starten braucht, kann den Test nicht bestehen, weil diese Hardware dafür entfernt wird.

Seit 0.4.6 zeigt eine Startprüfung, die nicht gestartet ist, die Meldung des Knotens unter ihrem Kennzeichen, auf der Seite des Gasts und in der Wiederherstellbarkeit, und Fehlertexte hinter einem Kennzeichen oder einer abgeschnittenen Zeile (die Startprüfung, die Restore-Prüfung einer VM oder eines Containers) öffnen sich bei Hover oder Tastaturfokus in einer Karte mit dem ganzen Text, markierbar und mit einer Schaltfläche Kopieren, statt in einem Browser-Tooltip.

Restore-Prüfungen nach jedem Backup

Seit 0.4.2 liest der Server von jedem neuen Sicherungsstand binnen Minuten nach seiner Sicherung eine Stichprobe der Datenblöcke zurück und vergleicht sie mit dem aufgezeichneten SHA-256 (bei einem Container ein restic-Check einer 5-%-Teilmenge). Der Durchlauf des Workers läuft alle fünf Minuten und nimmt höchstens 20 angeforderte Prüfungen je Durchlauf, älteste Anforderung zuerst, sodass ein großer Schwung Backups der Reihe nach drankommt („Prüfung eingereiht“). Die Einstellung „Jeden neuen Sicherungsstand direkt nach der Sicherung prüfen“ (Installation › Proxmox VE, Inhaber) ist standardmäßig an; ausgeschaltet wartet ein neuer Sicherungsstand auf die wöchentliche Prüfung. Der neueste Sicherungsstand jedes Gasts wird in jedem Fall mindestens wöchentlich geprüft, und es gibt keine Einstellung je Mandant.

In der Wiederherstellbarkeit prüft „Jetzt prüfen“ den neuesten Sicherungsstand eines Gasts und „Alle ungeprüften prüfen“ den neuesten Sicherungsstand jedes Gasts, den noch keine Prüfung gelesen hat. Auf der Seite eines Gasts prüft „Jetzt prüfen“ an einem Sicherungsstand genau diesen, auch einen älteren. Seit 0.4.6 steht nach „Jetzt prüfen“ in der Zeile „Prüfung eingereiht“ unter der letzten Prüfung und auf der Seite des Gasts über dem früheren Ergebnis, bis das Ergebnis da ist; beide aktualisieren sich währenddessen alle paar Sekunden. Eine rote Prüfung zeigt den Fehler, den sie gefunden hat (zum Beispiel den von restic), unter ihrem Kennzeichen in der Gästeliste, in der Wiederherstellbarkeit und auf der Seite des Gasts, statt nur „Blöcke stimmten nicht überein oder ließen sich nicht lesen“. Es ist eine stichprobenartige Rücklesung aus dem Speicher: keine Startprüfung und kein Restore auf Ihrem Knoten.

Ein gesperrtes Repository ist keine fehlgeschlagene Prüfung

Gleich nach einer Container-Sicherung konnte die neue Restore-Prüfung auf die Sperre stoßen, die ein anderer Vorgang noch auf dem restic-Repository des Containers hielt, meist die eigene Sicherung des Gasts, deren Sperre ein Abbruch oder ein Neustart der API zurückgelassen hatte. Sie zeigte dann ein rotes „Restore-Prüfung fehlgeschlagen“, obwohl sie nie gelaufen war. Seit 0.4.3 ist eine Prüfung, die eine Sperre aussperrt, keine fehlgeschlagene Prüfung:

• Sie wird erneut versucht. Die Prüfung wird um zehn Minuten verschoben, und das bisherige Ergebnis bleibt solange stehen. Der Gast zeigt „Restore-Prüfung verschoben“, seine Seite „Prüfung verschoben: Repository gesperrt“.
• Nach zwei Stunden steht der Sicherungsstand als „Nicht prüfbar: Repository gesperrt“ da: gelb (Achtung) in der Wiederherstellbarkeit, nie rot und nie grün, mit dem Bericht von restic, wer die Sperre hält. Über den Sicherungsstand ist dann nichts bekannt, er ist also kein Nachweis. Die wöchentliche Prüfung versucht es nach einem Tag wieder, die Prüfung nach dem nächsten Backup und „Jetzt prüfen“ oder „Alle ungeprüften prüfen“ früher. Eine Prüfung, die restic vor ihrem Ende gestoppt hat, steht ebenso als „Nicht prüfbar: Prüfung unterbrochen“ da.
• Weniger Sperren im Weg. Der Worker entfernt veraltete restic-Sperren (nur Sperren, die kein laufender Vorgang erneuert) vor der Prüfung und vor der Aufbewahrung, und restic wartet bei der Prüfung bis zu zwei Minuten auf eine Sperre. Ein Gast wird nicht geprüft, solange ein Lauf von ihm geht oder sein Knoten eine Sicherung von ihm angenommen hat, und ein neuer Sicherungsstand wird frühestens zwei Minuten nach seinem Commit geprüft. Seit 0.4.3 wartet restow-pve bei einer Container-Sicherung bis zu 15 Minuten auf die Sperre des Servers.

Restore-Prüfungen, die vor dem Update an einer Sperre fehlschlugen, bleiben rot, bis der Gast das nächste Mal geprüft wird: Wählen Sie „Jetzt prüfen“ am Gast oder in VMs & Container. Siehe auch Verifizierung.

Optionale monatliche Restore-Prüfung

Ein Backup-Job für Proxmox VE hat die Option „Monatliche Restore-Prüfung (stellt einen Gast im Pool restow-restore wieder her und löscht ihn danach)“ mit einem zweiten Feld, „Speicher für die Restore-Prüfung“, für den Speicher, auf den der Testgast wiederhergestellt wird. Sie ist standardmäßig aus und braucht freie Kapazität auf diesem Speicher. Ist sie an, nimmt der Wartungsdurchgang des Servers, der alle fünf Minuten läuft, einen Gast des Jobs, der einen Sicherungsstand hat und seit 30 Tagen keine Restore-Prüfung hatte, stellt dessen neuesten Sicherungsstand als neuen Gast im Pool restow-restore wieder her, ohne ihn zu starten, und löscht ihn danach wieder. Privilegierte Container sind ausgenommen. Diese Läufe sind mit „Restore-Prüfung“ beschriftet.

Sie prüft den Restore-Weg auf Ihrem eigenen Proxmox-VE-Knoten. Sie kommt zur Stichprobenprüfung hinzu, die Datenblöcke des neuesten Sicherungsstands jedes Gasts aus dem Speicher zurückliest und mit dem aufgezeichneten SHA-256 vergleicht (bei Containern ein restic-Check einer 5-%-Teilmenge); diese läuft wöchentlich und, seit 0.4.2, nach jedem neuen Backup, braucht keine Kapazität auf Ihrem Proxmox-VE-Knoten und läuft, ob Sie die monatliche einschalten oder nicht.

Benannte Grenzen, nicht versteckte

• Proxmox VE ist eine Preview und wird als einzige Sicherung noch nicht empfohlen.
• Es wurde gegen qemu-nbd, qemu-img und restic getestet und, für die Knotenanbindung, gegen Attrappen der Knoten-Werkzeuge.
• Der Ausschluss eines Gasts von der Sicherung (seit 0.4.7) wurde mit den Testsuiten des Releases geprüft, nicht gegen einen echten Proxmox-VE-Knoten ausgeführt. Mehrere Gäste im Inventar auszuschließen sendet eine Anfrage je Gast, weil es keine Sammelroute gibt; scheitert eine, bleiben die Gäste davor ausgeschlossen, und die Liste wird aktualisiert.
• Die Restore-Prüfung nach jedem Backup ist eine Stichprobe, die aus dem Speicher zurückgelesen wird, keine Startprüfung. Eine laufende Sicherung zu stoppen braucht restow-pve 0.4.2 auf dem Knoten. Eine Prüfung, die ein gesperrtes Repository aussperrt, steht als „Nicht prüfbar“ in Gelb da und beweist nichts.
• Die Korrektur, mit der sich ein Container auf aktuellem Proxmox VE wiederherstellen lässt (seit 0.4.6), wurde mit Perl-Tests des Plugins getestet, dem Restore mit und ohne Storage-ID, und vor dem Release nicht gegen einen echten Proxmox-VE-Knoten ausgeführt.
• Eine Dateifreigabe, deren Repository nach einem Speicherwechsel fehlt, wird noch nicht mit einer neuen Sicherungskette geheilt, wie es bei einem Container geschieht; das ist geplant.
• Die seit 0.4.3 überarbeitete Seite VMs & Container wurde mit DOM-Tests geprüft, nicht visuell in einem Browser mit Tausenden Gästen.
• Die Knotenzeilen des Inventars zeigen noch nicht, dass eine Sicherung auf ihren Knoten wartet oder läuft; VMs & Container tun das.
• Fortschritt, die Zeilen des Helfers im Lauf-Log, Startprüfungen, VM-Datei-Restore, die Wiederholung über fünf Minuten, das Stoppen einer Sicherung, die Restore-Prüfung nach jedem Backup, ihre Wiederholung bei gesperrtem Repository und die neue Sicherungskette wurden gegen den simulierten Knoten der Testsuiten (und einen simulierten S3-Speicher) getestet, nicht gegen einen echten Proxmox-VE-Cluster oder S3-Anbieter. Dateien von VMs und Containern werden als ZIP heruntergeladen; einzelne Dateien in den laufenden Gast wiederherzustellen ist nicht gebaut. VM-Vorlagen lassen sich nicht sichern, ein Live-Restore ist nicht möglich, und privilegierte Container kann Restow nicht wiederherstellen.

Die Roadmap zeigt, was danach kommt, der Changelog, was jedes Release geändert hat.

Häufig gefragt

Server- und Client-Backup mit einem Agent →

Mehr in Wissen: Vollsicherung, inkrementell und synthetisch voll im Vergleich →

Fair verglichen mit Proxmox Backup Server: wo PBS die bessere Wahl ist →