Proxmox-VE-Backup im Überblick

Restow sichert die virtuellen Maschinen und LXC-Container von Proxmox VE über die eigene Backup-Provider-API von Proxmox, die Schnittstelle, die Proxmox VE seit 8.4 für externe Backup-Produkte anbietet. Die Weboberfläche von Restow nennt eine VM oder einen Container einen Gast und einen Proxmox-VE-Server einen Knoten. Die Sicherungen landen im Repository des Mandanten, wie jedes andere Backup in Restow, und eine Wiederherstellung legt einen neuen Gast neben dem Original an, nie darüber.

Die Weboberfläche nennt die Funktion VMs & Container. Sie finden sie unter Server & Clients → VMs & Container, wo seit 0.4.3 drei Reiter, Gäste, Backup-Jobs und Knoten, die Gäste mit Suche, Filtern und einem Detailbereich, die Jobs und die Knoten enthalten (Inventar, Gäste und Sicherungsstände), und in einem Abschnitt Proxmox VE unter Server & Clients → Inventar. Die Backup-Jobs der Gäste stehen seit 0.4.0 auch unter Server & Clients → Jobs, neben den Jobs der Rechner.

Neben Sicherung und Wiederherstellung ganzer Gäste kann Restow einen Sicherungsstand durchsuchen und einzelne Dateien und Ordner als ZIP herunterladen (Dateien eines Gasts, bei VMs eine Preview innerhalb der Preview), und es kann einen Sicherungsstand isoliert starten, um nachzuweisen, dass er startet (Startprüfungen). Beides gibt es seit 0.4.0.

Status und Tests

Eine Preview, in jeder Edition. Das Proxmox-VE-Backup ist keine Funktion von Business oder Service Provider. Nichts daran ist gesperrt.
Proxmox VE ab 8.4, auf x86_64. Proxmox VE 9 ist das Hauptziel. 8.4 wird nach bestem Bemühen unterstützt. Das Installationsskript für den Knoten lehnt ältere Versionen und andere Architekturen ab.
Als einzige Sicherung noch nicht empfohlen. Betreiben Sie es neben Ihren bisherigen Sicherungen, bis Sie selbst einen Gast daraus wiederhergestellt haben, und halten Sie für jeden wichtigen Gast eine unabhängige Sicherung vor.
Was getestet wurde. Die Release Notes von 0.3.1 und 0.3.2 nennen als bekannte Probleme, dass die Integration gegen echte qemu-nbd, qemu-img und restic getestet wurde und das Installationsskript für den Knoten gegen Attrappen für pveum und pvesm, aber noch nicht auf einem Proxmox-VE-Host. Jedes spätere Release bis 0.4.3 führt diese bekannten Probleme weiter, und keine der Release Notes bis 0.4.3 meldet einen Test auf einem Proxmox-VE-Host oder -Cluster. Seit 0.4.2 sagen die Release Notes es noch einmal: Die neuen Teile (eine Sicherung stoppen, die Restore-Prüfung nach jeder Sicherung, die neue Sicherungskette, die VM des Restow-Servers selbst) wurden nur gegen eine simulierte Proxmox-VE-API getestet, nie gegen einen echten Proxmox-VE-Cluster, und seit 0.4.3 sagen die Release Notes dasselbe von den neuen Teilen (die Restore-Prüfung, die auf eine Sperre wartet, der Reiter Knoten, das Update auf Anforderung), getestet gegen eine simulierte Proxmox-VE-API und einen simulierten S3-Speicher, und ergänzen, dass die neu gestaltete Seite VMs & Container mit DOM-Tests getestet wurde, nicht von Hand im Browser mit Tausenden Gästen. Die Release Notes von 0.4.0 ergänzen: Der Fortschritt laufender Sicherungen, die Zeilen des Helfers im Log des Laufs, das Wiederholungsfenster von fünf Minuten und das Schließen verlorener Läufe wurden gegen den simulierten Knoten der Testsuiten getestet, Startprüfungen und das Datei-Restore von VMs nur gegen simulierte Dienste. Der Ausschluss von Gästen (seit 0.4.7) wurde ebenfalls gegen einen simulierten Knoten getestet, nicht gegen einen echten Proxmox-VE-Knoten. Beginnen Sie mit einem Testknoten oder einigen Test-Gästen und stellen Sie daraus wieder her, bevor Sie sich darauf verlassen.
Die Funktion ist noch in Bewegung. Die Releases von 0.3.2 bis 0.4.3 haben sie jeweils verändert, zum Beispiel ein Befehl je Knoten (0.3.2), die Knoten im Inventar (0.3.3), eine Korrektur für die Sicherung nicht privilegierter Container (0.3.4), Größenangaben und unvollständige Container-Sicherungen (0.3.5), Gäste im Inventar schützen (0.3.6) und in 0.4.0 der Fortschritt laufender Sicherungen, Jobs unter Server & Clients → Jobs, das Datei-Restore von Containern und VMs und Startprüfungen, und seit 0.4.2 das Stoppen einer Sicherung, das Anhalten der Warteschlange eines Knotens, eine Restore-Prüfung direkt nach jeder Sicherung, die Rhythmen der Mail-Jobs für Gast-Jobs, eine neue Sicherungskette, wenn das Repository eines Containers fehlt, Repository zurücksetzen und der Schutz vor dem Sichern der VM des Restow-Servers selbst, und seit 0.4.3 die Reiter, Filter und der Detailbereich von VMs & Container, Restore-Prüfungen, die eine gesperrte Repository aussperrt (erneut versucht, dann „Nicht prüfbar“ statt eines roten Fehlers), und ein restow-pve, das die Proxmox-VE-Daemons nach einem eigenen Update neu startet, und seit 0.4.6 die Wiederherstellung von Containern auf dem aktuellen Proxmox VE (siehe unten) und seit 0.4.7 das bewusste Ausschließen eines Gasts von der Sicherung (Einen Gast von der Sicherung ausschließen). Die Roadmap nennt, was jedes Release geändert hat. Aktualisieren Sie nach einem Server-Update auch restow-pve auf den Knoten (sie fordern es von selbst an), siehe Knoten aktualisieren und entfernen.

So funktioniert es

Auf dem Knoten

Zwei Teile laufen auf jedem Proxmox-VE-Knoten, der gesichert werden soll:

Der Storage-Plugin-Shim. Zwei kleine Perl-Module, die Proxmox VE als Speicher vom Typ restow mit dem Inhaltstyp backup lädt. Sie nehmen nur die Aufrufe von Proxmox VE entgegen und reichen jeden an den Helfer weiter. Sie enthalten keine Restow-Logik. Der Shim ist ein eigenes Werk unter AGPL-3.0-or-later, weil er von den AGPL-lizenzierten Speicher-Klassen von Proxmox VE abgeleitet ist.
Der Helfer restow-pve. Ein Go-Programm (nur Standardbibliothek, Apache-2.0), das als systemd-Dienst restow-pve.service als root läuft. Er meldet sich jede Minute bei Restow (seit 0.4.2 alle 15 Sekunden, solange eine Sicherung läuft) mit den Sicherungen, an denen er arbeitet, holt Aufgaben ab, meldet alle fünf Minuten die Gäste des Knotens und erledigt die eigentliche Arbeit: VM-Festplatten lesen, restic für Container ausführen, Wiederherstellungen bereitstellen, Startprüfungen ausführen.

Die Verbindung geht nur nach außen. Der Knoten ruft Restow auf, und Restow ruft den Knoten nie auf. Restow reiht Aufgaben ein (Jetzt sichern, Wiederherstellung, Restore-Prüfung, Startprüfung), und der Helfer führt sie über die lokale Proxmox-VE-API (127.0.0.1:8006) mit einem API-Token aus, der auf dem Knoten bleibt. Sicherungen, die ein Restow-Job oder Jetzt sichern anfordert, laufen als gewöhnliche Proxmox-VE-Sicherung (vzdump) auf den Speicher restow, mit Fleecing auf dem Thin-Speicher des Knotens.

Fortschritt einer laufenden Sicherung

Seit 0.4.0 zeigt eine laufende Sicherung, wie weit sie ist, in VMs & Container, im Inventar und auf der Seite des Gasts: ein Balken mit einer Zeile wie „34 % · 3,2 GB von 9,4 GB · 85 MB/s“. Eine VM meldet die Bytes, die sie von ihren Festplatten gelesen hat (nur die geänderten Blöcke, wenn die Bitmap wiederverwendet wird), und was sie hochgeladen hat. Ein Container gibt weiter, was restic meldet, und restic durchsucht den Container jetzt zuerst, sodass es eine Gesamtmenge gibt, an der sich messen lässt. Bis die Gesamtmenge bekannt ist, sagt die Zeile, wie viel bisher gelesen wurde. Der Fortschritt braucht restow-pve 0.4.0 auf dem Knoten. Eine Sicherung eines älteren Helfers sagt weiter „Noch kein Fortschritt gemeldet“. Seit 0.4.1 sagt die Seite, was fehlt: „Der Fortschritt braucht restow-pve 0.4.0 auf <Knoten> (dort läuft <Version>). Aktualisieren Sie den Knoten.“

Während Restow aktualisiert

Ein Update von Restow startet die API neu und wendet Datenbankmigrationen an, was länger dauern kann, als ein Helfer früher wartete. Ein Knoten mit restow-pve 0.4.0 oder neuer versucht es fünf Minuten lang weiter, sodass eine Sicherung, die während eines Updates läuft, nicht scheitert. Seine Meldung listet außerdem die Läufe auf, an denen er arbeitet, und Restow schließt einen Lauf, sobald der Knoten ihn nicht mehr auflistet, statt ihn 48 Stunden lang „läuft“ zu lassen. Ältere Helfer funktionieren weiter, ohne das Wiederholungsfenster und ohne diese Liste. Der Update-Dialog fragt, was mit den laufenden Läufen geschehen soll, dazu gehören Proxmox-VE-Sicherungen, siehe Updates.

Die eigenen Zeilen des Helfers zu einer Sicherung (die Lauf-ID, was restic hinzugefügt hat und nicht lesen konnte, der Commit des Sicherungsstands) stehen seit 0.4.0 im Log, das Restow für den Lauf aufbewahrt. Vorher zeigte Proxmox VE sie nur in seinem Task-Log.

VM-Festplatten

Proxmox VE exportiert einen Schnappschuss jeder Festplatte der VM zu einem Zeitpunkt über NBD, zusammen mit einer Dirty Bitmap. restow-pve liest nur die geänderten 4-MiB-Blöcke (alle Blöcke bei der ersten Sicherung und immer dann, wenn die Bitmap verloren ist). Er überspringt Blöcke, die nur aus Nullen bestehen, und Blöcke, deren SHA-256 sich seit der letzten Sicherung nicht geändert hat, und lädt den Rest hoch. Nur geänderte Blöcke verlassen den Knoten.

Der Restow-Server prüft die SHA-256 jedes Blocks, den er erhält, zerlegt ihn in Chunks, verschlüsselt ihn mit dem Mandantenschlüssel, packt ihn und führt eine Blockkarte je Festplatte. Jeder Sicherungsstand enthält die vollständige Karte jeder Festplatte, ein sogenanntes synthetisches Vollbackup: Jeder Sicherungsstand lässt sich für sich wiederherstellen oder entfernen, ohne seine Vorgänger.

Proxmox VE verlangt für eine Sicherung über einen Backup-Provider Fleecing: Neue Schreibzugriffe der laufenden VM gehen in ein temporäres Abbild auf einem Thin-Speicher des Knotens, während die Sicherung den Schnappschuss liest. restow-pve verwirft jeden Block, den er erledigt hat, sodass dieses Abbild klein bleibt. Deshalb braucht jeder Knoten einen Thin-Speicher, siehe Voraussetzungen.

Ist der QEMU-Gast-Agent für die VM aktiviert und das Einfrieren des Dateisystems nicht ausgeschaltet, friert Proxmox VE die Dateisysteme des Gastes für den Moment des Schnappschusses ein. Ohne den Agent ist die Sicherung absturzkonsistent, als hätte man in diesem Moment den Stecker gezogen. Bei Windows-Gästen brauchen konsistente Sicherungen VSS über den Gast-Agent.

Vollständiges Lesen nach einem Neustart

Die Dirty Bitmap einer VM liegt im Speicher des QEMU-Prozesses. Sie ist weg, nachdem die VM gestoppt und wieder gestartet wurde, nach einer Sicherung im Modus stop, nachdem eine Festplatte vergrößert oder verschoben wurde, und bei der Sicherung einer ausgeschalteten VM (Proxmox VE startet sie dafür pausiert). Die nächste Sicherung liest dann die ganze Festplatte auf dem Knoten, lädt aber trotzdem nur die Blöcke hoch, deren SHA-256 sich geändert hat, sodass sehr wenig über das Netz geht. Außerdem ist jede 30. Sicherung einer Festplatte absichtlich ein vollständiges Lesen, als Kontrolle der Bitmap.

Die Gästeliste zeigt das Ergebnis als Inkrementell oder Vollständiges Lesen (VM neu gestartet). Jeder Sicherungsstand eines Gastes zeigt seine eigene Art: Erste Sicherung, Inkrementell oder Vollständig gelesen, siehe Inventar, Gäste und Sicherungsstände.

Container

Container gehen über restic, nicht über Blöcke. Proxmox VE bereitet den Dateibaum des Containers vor, und restow-pve führt restic darüber aus, in ein restic-Repository je Container, pve-guests/<Gast-ID>/ im primären Repository des Mandanten. Der Knoten bekommt für jeden Lauf eine Zugangsberechtigung, die mit dem Lauf abläuft und nur Daten hinzufügen kann. Auf dem Knoten läuft das restic-Release, das Restow ausliefert (dasselbe wie beim Agent).

Nur geänderte Daten verlassen den Knoten, auf der Ebene der restic-Chunks, nicht der Blöcke. Seit 0.4.0 durchsucht restic den Container vor der Sicherung (der Helfer übergibt --no-scan nicht mehr), was etwas Zeit kostet und der Sicherung eine Gesamtmenge für ihren Fortschrittsbalken gibt. Der Ordner lost+found an der Wurzel des Containers und jedes Mountpunkts bleibt außen vor, wie bei vzdump. Kann restic einige Dateien nicht lesen, bleibt der Sicherungsstand erhalten und wird als unvollständig gekennzeichnet, siehe Mit Lücken erfolgreich.

restic braucht eine konsistente Quelle. Im Modus snapshot müssen die Volumes des Containers auf Speicher liegen, der Snapshots unterstützt (ZFS, LVM-thin, Ceph RBD, Btrfs). Auf Verzeichnis- oder NFS-Speicher fällt Proxmox VE für den Container selbst auf den Modus suspend zurück, der ihn kurz anhält und temporären Platz braucht.

Wohin die Daten gehen

Alle Sicherungsdaten gehen in das Repository, das Sie gewählt haben, für den Mandanten in Restow, wie der Rest Ihrer Sicherungen (siehe Backups und Zeitpläne):

VM-Festplatten gehen in den eigenen Chunk-Speicher von Restow für den Mandanten, und jeder Sicherungsstand hat ein versiegeltes Manifest. Der Knoten sendet die Blöcke über HTTPS, und der Server verschlüsselt sie. Der Knoten bekommt den Mandantenschlüssel nie.
Container gehen in die restic-Repositories unter pve-guests/<Gast-ID>/ im primären Repository des Mandanten. Restow erzeugt das Repository-Passwort und bewahrt es, mit dem Mandantenschlüssel versiegelt, in seiner Datenbank und neben dem Repository auf.

Seit 0.4.0 lässt sich ein Repository unveränderbar machen, und was das sperrt, schließt die Proxmox-VE-Daten ein: die Packs, die Manifeste und die umhüllten Schlüssel des Chunk-Speichers (der die VM-Festplatten enthält) und die Objekte data/, snapshots/, keys/ und config jedes Container-Repositorys. Die Ransomware-Erkennung beurteilt die Sicherungsstände von Containern und VMs, und ein verdächtiger Sicherungsstand hält die Aufbewahrung dieses Gasts an, siehe Unveränderbare Backups und Ransomware-Erkennung. Das Standard-Repository der Installation lässt sich nicht unveränderbar machen. Die Markierung Verdächtig erscheint auf der Seite des Gasts.

Seit 0.4.1 zählen die restic-Repositories von Containern in den Angaben zu Gespeichert in Restow (sie blieben früher außen vor und erschienen als 0 B). Ein Container-Repository zählt ab der nächsten Sicherung dieses Containers.

Seit 0.4.2 nennen die Seite des Gasts, ihr Dialog Jetzt sichern, der Job-Dialog und der Dialog zum Verbinden eines Knotens das Repository, in dem die Sicherungen landen, und warnen, wenn das ein Verzeichnis auf der Platte des Restow-Servers selbst ist (Wo Sicherungen landen). Ein Speicher-Verschieben kopiert die restic-Repositories der Container mit dem Rest, geprüft nach Größe und SHA-256, und Vorhandene Backups dort belassen, wo sie sind wird abgelehnt, solange Container Repositories haben (Das primäre Repository ersetzen). Fehlt das Repository eines Containers auf dem primären, beginnt die nächste Sicherung eine neue Sicherungskette (Neue Sicherungskette und Repository zurücksetzen).

Ein Knoten bekommt nie Speicher-Zugangsdaten: keine S3-Schlüssel, keine Mount-Pfade. Die Aufbewahrung läuft nur auf dem Restow-Server: Der Knoten kann keinen Sicherungsstand löschen oder ändern, und das Storage-Plugin lehnt „Entfernen“ und Prune in Proxmox VE mit dem Hinweis ab, dass die Aufbewahrung in Restow verwaltet wird. Wird ein Sicherungsstand bereinigt, gibt Restow die Chunk-Verweise frei, die er hielt, und die Garbage Collection der Speicherprüfung gibt die Chunks später frei.

Voraussetzungen

Was	Voraussetzung
Proxmox VE	8.4 oder neuer, auf x86_64 (prüfen mit `pveversion`). 9.x ist das Hauptziel.
QEMU	Das laufende QEMU der VM muss die Funktion für den Backup-Zugriff melden (`backup-access-api`). Eine VM, die vor dem QEMU-Upgrade gestartet wurde, braucht einen Neustart über Proxmox VE.
Thin-Speicher	Ein aktiver Thin-Speicher mit dem Inhaltstyp `images` auf jedem Knoten, für die Fleecing-Abbilder: LVM-thin (`local-lvm`), ZFS (`local-zfs`), Ceph RBD oder Btrfs. Ohne ihn lassen sich VMs nicht über einen Backup-Provider sichern.
Auf dem Knoten	root und `curl`. Das Installationsskript läuft als root und nutzt `pveum` und `pvesm`.
Netzwerk	Ausgehendes HTTPS (443) von jedem Knoten zu Ihrer Restow-Instanz. Zum Knoten muss nichts durchkommen. Siehe Netzwerk.
`restow-pve`	0.4.0 oder neuer für den Fortschritt laufender Sicherungen und für Startprüfungen, 0.4.2 oder neuer für Sicherung stoppen, für das Erkennen der VM des Restow-Servers selbst und für Sicherungen mit Warnungen, 0.4.3 oder neuer, um bei einer Container-Sicherung auf die Repository-Sperre zu warten und die Proxmox-VE-Daemons nach einem Update neu zu starten (Knoten mit 0.4.1 brauchen ein Update von Hand), 0.4.6 oder neuer, um auf dem aktuellen Proxmox VE einen Container wiederherzustellen und einen Container per Startprüfung zu prüfen (ältere Helfer scheitern mit `Can't use string ("restow") as a HASH ref`; VMs sind nicht betroffen). Knoten aktualisieren sich selbst und ziehen ein Server-Update nach, siehe Knoten aktualisieren und entfernen. Ältere Helfer sichern weiter.
In Restow	Eine öffentliche URL Ihrer Installation mit `https://`, die die Knoten erreichen (der Befehl enthält sie), und ein Administratorkonto.
Cluster	Ein Proxmox-VE-Cluster gehört zu einem Mandanten.

Netzwerk

Von	Nach	Port	Wofür
Knoten (`restow-pve`)	Ihre Restow-Instanz	443, HTTPS	Die Meldung jede Minute, Aufgaben, die Gästeliste, VM-Blöcke, restic-Uploads von Containern und die Downloads des Installationsskripts und der Updates (`/install/...`).
`restow-pve` auf dem Knoten	Die Proxmox-VE-API desselben Knotens	`127.0.0.1:8006`, nur auf dem Knoten	Sicherungen und Wiederherstellungen starten, Gäste und Speicher lesen.
Ihre Restow-Instanz	Ein Knoten	keiner	Restow verbindet sich nie mit einem Knoten.

Die Pfade auf Ihrer Instanz sind /agent/pve/v1/... (die API des Helfers), /agent/pve/restic/<Gast-ID>/... (das restic-Repository eines Containers, für den Knoten nur anhängend) und /install/pve.sh mit den Dateien unter /install/agent/<Version>/. Sie stehen in Ports und Rollen, und die Firewall-Seite steht in Netzwerk und Ports.

Der Helfer nutzt den Proxy seiner Umgebung (HTTPS_PROXY, NO_PROXY), wie der Linux-Agent, und vertraut dem Zertifikat, das Ihre Instanz vorzeigt. Eine private Zertifizierungsstelle braucht einen Eintrag im Truststore des Knotens.
Ein Reverse-Proxy vor Restow muss große Bodys durchlassen. Ein Block-Upload umfasst bis zu 64 MiB, und eine Container-Sicherung sendet restic-Packs von bis zu 128 MiB. Erhöhen Sie das Limit deshalb auf mindestens 128 MiB, wie bei den Agents.

Sicherheit in Kürze

Der Proxmox-VE-API-Token verlässt den Knoten standardmäßig nie. Das Installationsskript erzeugt ihn auf dem Knoten, und sein Secret bleibt in der Zustandsdatei des Helfers (/etc/restow-pve/state.json, nur root). Restow bekommt es nie. Der Token kann Gäste nur im Pool restow-restore anlegen und löschen und stellt nie über einen vorhandenen Gast wieder her.
Ein vorhandener API-Token, den Sie in Restow eintragen, läuft einmal durch Restow, siehe Knoten verbinden.
Das Enrollment-Token gilt für einen Knoten, einmal, 24 Stunden lang. Restow speichert nur seine SHA-256, und es reist in der Umgebung des Installationsskripts, nicht in dessen Argumenten.
Der Knoten authentifiziert sich mit einem eigenen Secret, von dem Restow nur die SHA-256 speichert. Ein Knoten darf Läufe nur für Gäste seines eigenen Clusters eröffnen, an seine eigenen offenen Läufe anhängen, einmal abschließen und die Sicherungsstände seines eigenen Clusters lesen. Er kann keinen Sicherungsstand löschen oder ändern. Ein kompromittierter Knoten kann deshalb Sicherungen seines Clusters lesen und hinzufügen, nicht löschen.
Das Datei-Restore bezieht den Knoten nicht ein. Der Server liest die Dateien eines Sicherungsstands selbst (die Festplatten einer VM in einem eingeschränkten Kindprozess, das restic-Repository eines Containers), und nichts wird eingehängt. Siehe Dateien eines Gasts.
Startprüfungen brauchen kein neues Recht. Der Knoten nutzt den Token, den er hat und der Gäste nur im Pool restow-restore anlegen und löschen kann, und qm und pct als root. Der temporäre Gast hat seine Netzwerkverbindung gekappt, bevor er startet.
Der Mandantenschlüssel bleibt auf dem Server. Die Blöcke werden dort verschlüsselt.
Die Installation ist signiert. Das Installationsskript und die Updates des Helfers prüfen die Release-Signatur und die SHA-256 jeder Datei, bevor etwas ausgeführt oder ersetzt wird.

Audit-Log

Aktionen zu Proxmox VE stehen im Audit-Log des Mandanten: ein Enrollment-Token erstellt, ein Knoten eingerichtet oder widerrufen, ein unzulässiger Zugriff eines Knotens abgewiesen, eine Sicherung des Gasts angefordert, eine Wiederherstellung als neuer Gast angefordert, eine Restore-Prüfung des Sicherungsstands angefordert, eine Startprüfung angefordert (seit 0.4.0), ein Backup-Job für VMs und Container geändert und ein Sicherungsstand eines Gasts gespeichert oder durch die Aufbewahrung entfernt. Seit 0.4.2 hält das Log außerdem fest: eine gestoppte Sicherung (pve.backup.cancelled), zurückgezogene wartende Sicherungen (pve.queue.cancelled), die angehaltene oder fortgesetzte Warteschlange eines Knotens (pve.queue.paused, pve.queue.resumed), ein angefordertes Update eines Knotens (pve.node.update_requested), das Repository eines Containers, das auf dem primären fehlte, sodass eine neue Sicherungskette begann (pve.repository.reinitialized) oder das ein Administrator zurückgesetzt hat (pve.repository.reset), einen als Restow-Server markierten oder wieder entmarkierten Gast (pve.guest.restow_server), die bestätigte Sicherung des Restow-Servers mit Restow (pve.guest.self_backup_confirmed) und die Proxmox-VE-Einstellungen der Installation (settings.pve.updated). Seit 0.4.0 wird auch jede gelesene Ordnerseite und jeder gestartete Download in einem Sicherungsstand eines Containers oder einer VM protokolliert, siehe Dateien eines Gasts.

Bekannte Grenzen

In 0.4.7 nicht möglich:

VM-Vorlagen sichern. Proxmox VE schaltet Fleecing für Vorlagen aus, und ohne Fleecing kann ein Provider keine VM sichern.
Live-Wiederherstellung. Proxmox VE verweigert sie für Backup-Provider. Ein wiederhergestellter Gast ist vollständig, bevor er startet.
Privilegierte Container wiederherstellen. Proxmox VE verweigert es aus einem Backup-Provider. Stellen Sie einen solchen Container von Hand als nicht privilegierten wieder her. Der Wiederherstellungsdialog sagt das.
Einzelne Dateien in einen laufenden Gast zurücklegen. Eine Wiederherstellung legt einen ganzen neuen Gast an. Seit 0.4.0 können Sie die Dateien eines Sicherungsstands durchsuchen und als ZIP herunterladen, aber Restow schreibt sie nicht in den Gast zurück. Das Datei-Restore von VMs kann btrfs, ZFS, ReFS, LVM thin, RAID, BitLocker und LUKS nicht lesen, und es spielt das XFS-Log und das NTFS-$LogFile nicht nach. Siehe Dateien eines Gasts.
Startprüfungen mit Anwendungs- oder Port-Prüfungen. Eine Startprüfung weist nach, dass der Gast startet und über den Guest Agent antwortet (ein Container: dass sein Init-Prozess läuft). Siehe Startprüfungen.
Mehr als ein Mandant je Cluster und Proxmox VE auf arm64.

Außerdem gut zu wissen:

Gast-Jobs sind getrennt. Backup-Jobs für VMs und Container liegen auf der Seite VMs & Container (im Reiter Backup-Jobs), getrennt von den Jobs für Postfächer und Rechner. Siehe Backup-Jobs und Schutz.
Jobs sichern im Modus snapshot. Der Job-Dialog hat kein Feld für den Modus suspend oder stop, weiterhin in 0.4.7.
Der Knoten selbst wird nicht gesichert. restow-pve sichert die VMs und Container eines Knotens, nicht den Knoten. Für die Dateien des Hosts, etwa /etc/pve und die Netzwerk- und Speicherkonfiguration, installieren Sie den Restow-Agent auf dem Host und nehmen ihn in einen Job für Server auf. VMs & Container sagt das in einer Zeile im Reiter Knoten, mit Host als Server hinzufügen.
Eine Sicherung einer VM zur Zeit. Proxmox VE erlaubt nur eine Sicherung einer VM gleichzeitig. Läuft eine andere Sicherung derselben VM (zum Beispiel ein Job zum Proxmox Backup Server), scheitert eine von beiden. Legen Sie sie zeitlich auseinander.
Ohne Restow. restow-restore schreibt die Festplatten eines VM-Sicherungsstands allein aus dem Speicher und dem Master-Key als dünn besetzte Raw-Abbilder. Die Sicherungsstände eines Containers sind gewöhnliche restic-Repositories unter pve-guests/<Gast-ID>/, aber in 0.4.7 sucht restow-restore endpoint-password nur in endpoints/ und öffnet deshalb das Passwort eines Container-Repositorys nicht, obwohl das versiegelte Passwort neben dem Repository liegt (restow-repository-password.json). Siehe Restow selbst sichern.
Gäste auf Knoten ohne den Helfer. Ein Gast, der seinen Knoten verlassen hat, erscheint als Nicht mehr gemeldet. Ein Gast, der auf einen Knoten ohne restow-pve umgezogen ist, lässt sich erst sichern, wenn der Helfer auch dort läuft.

Proxmox ist eine Marke der Proxmox Server Solutions GmbH. Restow ist nicht mit ihr verbunden und wird von ihr nicht empfohlen.