Proxmox-VE-Gäste wiederherstellen

Eine Wiederherstellung legt einen neuen Gast mit einer neuen VMID im Pool restow-restore an. Das Original bleibt unverändert. Restow stellt nie über einen vorhandenen Gast wieder her, übergibt Proxmox VE nie force, und der API-Token des Knotens kann Gäste nur in diesem Pool anlegen und löschen. Das ist dieselbe Regel wie bei jeder anderen Wiederherstellung in Restow, siehe Backup und Restore.

Einen ganzen Gast wiederherzustellen ist Sache der Administratoren. Ein Restore-Operator (die Rolle „Restore“) kann die Sicherungsstände eines Gasts lesen und Dateien daraus durchsuchen und herunterladen, siehe Dateien eines Gasts, aber keinen Gast als Ganzes wiederherstellen. Einzelne Dateien in den laufenden Gast zurückzulegen ist nicht gebaut (0.4.7): Dateien kommen als ZIP heraus.

Dateien statt eines ganzen Gasts

Brauchen Sie eine Datei oder einen Ordner, müssen Sie den Gast nicht wiederherstellen. Seit 0.4.0 listet Server & Clients → Datei-Restore Container und VMs mit einem Sicherungsstand, und Dateien durchsuchen bei einem Sicherungsstand auf der Seite des Gasts öffnet es. Wählen Sie die Dateien und laden Sie sie als ein ZIP herunter. Das Datei-Restore von VMs ist eine Preview. Siehe Dateien eines Gasts.

Einen Gast aus Restow wiederherstellen

Öffnen Sie den Gast: Server & Clients → VMs & Container oder den Abschnitt Proxmox VE unter Server & Clients → Inventar, und wählen Sie den Namen des Gasts.
Wählen Sie in der Tabelle Sicherungsstände bei dem gewünschten Sicherungsstand Als neuen Gast wiederherstellen.

Füllen Sie den Dialog aus und wählen Sie Wiederherstellen:

Feld	Bedeutung
Zielspeicher (Proxmox-VE-Speicher-ID)	Der Speicher, der die Festplatten des neuen Gasts aufnimmt, zum Beispiel `local-lvm`. Er muss auf dem Zielknoten existieren, Platz haben und Gast-Festplatten erlauben. Das Feld beginnt mit `local-lvm`: Ändern Sie es auf das, was Ihr Knoten hat.
Zielknoten	Der Knoten, der den Gast anlegt. Er beginnt mit dem Knoten des Originals. Ein anderer Knoten des Clusters geht, wenn dort `restow-pve` läuft und der Zielspeicher vorhanden ist.
Neue ID (leer: nächste freie)	Die VMID des neuen Gasts, 100 oder höher. Lassen Sie sie leer, wählt Proxmox VE die nächste freie.
Nach der Wiederherstellung starten	Standardmäßig aus.

Restow sagt „Wiederherstellung angefordert. Der Knoten startet sie bei seiner nächsten Meldung, meist innerhalb einer Minute.“ Verfolgen Sie sie in der Tabelle Läufe des Gasts: ein Lauf der Art Wiederherstellung, der als Erfolgreich oder Fehlgeschlagen endet.

Ist die Wiederherstellung fertig, liegt der neue Gast im Pool restow-restore von Proxmox VE. Prüfen Sie ihn und verschieben Sie ihn aus dem Pool, sobald Sie ihn übernehmen. Ein Gast, der im Pool bleibt, ist ein Gast, den der Token des Knotens löschen darf.

Das aktuelle Proxmox VE übergibt die Storage-ID an die Container-Wiederherstellung des Backup-Providers vor dem Info-Hash. Das Plugin von restow-pve vor 0.4.6 scheiterte daran mit Can't use string ("restow") as a HASH ref: Jede Wiederherstellung und jede Startprüfung (Nicht gestartet) eines Containers schlug fehl, auch Als neuen Gast wiederherstellen. VMs waren nicht betroffen. Das Plugin akzeptiert seit 0.4.6 beide Formen. Es wird mit dem Update von restow-pve installiert, das die Proxmox-VE-Daemons neu lädt: Der Server bietet es nach seinem eigenen Update an, und Knoten im Leerlauf aktualisieren sich selbst, oder Sie führen als root restow-pve update aus (Knoten aktualisieren und entfernen). Bis ein Knoten aktualisiert ist, schlagen Container-Wiederherstellungen auf ihm weiter fehl wie bisher. Die Korrektur wurde mit den Perl-Tests des Plugins getestet (mit und ohne Storage-ID), vor dem Release nicht gegen einen echten Proxmox-VE-Knoten.

Ein wiederhergestellter Gast hat die Konfiguration des Originals, abgesehen von den MAC-Adressen einer VM, die Proxmox VE neu vergibt. Eine IP-Adresse, die im Gast eingestellt ist, ist dieselbe wie beim Original. Lassen Sie Nach der Wiederherstellung starten aus und starten Sie den wiederhergestellten Gast nicht im selben Netz, solange das Original läuft, es sei denn, Sie haben das geändert.

Welche Sicherungsstände sich wiederherstellen lassen

Jeder Sicherungsstand lässt sich für sich wiederherstellen, gleich welcher Art, siehe Arten von Sicherungsständen. Das gilt auch für die Sicherungsstände eines Gasts, der von der Sicherung ausgeschlossen wurde (seit 0.4.7): Das Ausschließen beendet neue Sicherungen und rührt Vorhandenes nicht an. Markiert die Ransomware-Erkennung den neuesten Sicherungsstand des Gasts als verdächtig, verweist die Seite des Gasts auf den neuesten ohne Befund. Ein Sicherungsstand mit Lücken (eine Container-Sicherung, die restic nicht vollständig lesen konnte) stellt wieder her, was er enthält. Ein Sicherungsstand einer früheren Sicherungskette eines Containers, dessen Repository nicht mehr vorhanden ist, ist Nicht verfügbar (seit 0.4.2) und lässt sich nicht wiederherstellen, siehe Neue Sicherungskette und Repository zurücksetzen. Ein privilegierter Container lässt sich nicht wiederherstellen: Proxmox VE verweigert es, ihn aus einer Backup-Schnittstelle wiederherzustellen, und der Dialog sagt das („Privilegierte Container kann Proxmox VE aus einer Backup-Schnittstelle nicht wiederherstellen.“). Stellen Sie einen solchen Container von Hand als nicht privilegierten wieder her.

Was auf dem Knoten geschieht

Der Knoten startet die Wiederherstellung bei seiner nächsten Meldung, über die Proxmox-VE-API mit dem Token, der auf dem Knoten bleibt. Proxmox VE führt die Wiederherstellung selbst aus, und das Storage-Plugin liefert die Daten:

Eine VM. Für jede Festplatte startet restow-pve auf dem Knoten einen kleinen NBD-Server, der die Festplatte des Sicherungsstands bereitstellt, und Proxmox VE liest sie mit qemu-img convert in den Zielspeicher. Nullblöcke bleiben Löcher, die neue Festplatte bleibt also dünn besetzt. Die Konfiguration und die Firewall-Konfiguration des Gasts stammen aus dem Sicherungsstand. Der Sicherungsstand wird vom Restow-Server Block für Block gelesen.
Ein Container. restow-pve entpackt den restic-Snapshot in einen temporären Ordner auf dem Knoten, und Proxmox VE kopiert ihn in das neue Root-Dateisystem. Der Ordner ist standardmäßig /var/tmp/restow-pve (ändern mit restow-pve config --restore-tmp), er braucht also freien Platz für die Dateien des Containers. Der neue Container wird als nicht privilegierter angelegt.

Ein Knoten kann Wiederherstellungen für sich ablehnen: Mit restow-pve config --allow-restores=false antwortet Restow „Restores are off on this node“ (englischer Text), siehe Knoten aktualisieren und entfernen.

Aus der Proxmox-VE-Weboberfläche wiederherstellen

Ein Sicherungsstand ist in Proxmox VE auch eine Sicherung auf dem Speicher restow. In der Proxmox-VE-Weboberfläche hat der Speicher restow einen Reiter Backups, der die Sicherungsstände listet. Show configuration liest die Konfiguration des Gasts aus dem Sicherungsstand, und Restore stellt sie über dasselbe Plugin wieder her, mit Ihren eigenen Proxmox-VE-Berechtigungen, nicht denen des Tokens des Knotens. Der Lauf erscheint in Restow als in Proxmox VE gestartet. Remove wird abgelehnt („retention is managed in Restow“): Sicherungsstände entfernt nur die Aufbewahrung in Restow.

Ohne Restow wiederherstellen

Ist der Restow-Server weg, sind die Daten trotzdem lesbar:

VM-Festplatten. Das eigenständige Werkzeug restow-restore liest das Manifest eines Sicherungsstands und den Chunk-Speicher direkt und schreibt jede Festplatte der VM als dünn besetztes Raw-Abbild, disks/<Gerät>.raw, mit den Nullblöcken als Löchern. Jeder Block wird gegen die SHA-256 in der Blockkarte geprüft, und eine Festplatte mit einem Block, der nicht passt, wird nicht geschrieben. Es braucht den Speicher und den Master-Key, siehe Eigenständige Wiederherstellung. Ein Raw-Abbild hängen Sie selbst an eine neue VM an.
Container. Die Sicherungsstände eines Containers sind ein gewöhnliches restic-Repository unter pve-guests/<Gast-ID>/ im primären Repository des Mandanten, das restic selbst mit dem Repository-Passwort öffnen kann. Das Passwort liegt, mit dem Mandantenschlüssel versiegelt, als restow-repository-password.json neben dem Repository. In 0.4.7 sucht restow-restore endpoint-password nur in endpoints/ und öffnet dieses Passwort deshalb nicht für Sie.

Restore-Prüfungen

Eine Restore-Prüfung belegt, dass sich ein Sicherungsstand zurücklesen lässt, ohne einen Gast anzulegen: Sie läuft wöchentlich für den neuesten Sicherungsstand jedes Gasts und auf Anforderung mit Jetzt prüfen. Die optionale monatliche Restore-Prüfung eines Jobs stellt einen Gast im Pool restow-restore wieder her und löscht ihn wieder. Siehe Backup-Jobs und Schutz.

Eine Startprüfung geht weiter: Sie stellt einen Sicherungsstand als temporären Gast ohne Netzwerkverbindung wieder her, startet ihn, wartet auf den Guest Agent und zerstört ihn wieder. Sie ist aus, bis ein Job sie einschaltet, und Jetzt Start prüfen bei einem Sicherungsstand fordert von Hand eine an. Siehe Startprüfungen.

Wenn eine Wiederherstellung scheitert

Siehe Fehlerbehebung.