Startprüfungen

Eine Restore-Prüfung zeigt, dass sich die Bytes eines Sicherungsstands zurücklesen lassen und mit dem übereinstimmen, was gespeichert wurde. Sie zeigt nicht, dass der Gast startet. Eine Startprüfung geht einen Schritt weiter: Der Knoten des Gasts stellt den Sicherungsstand als temporären neuen Gast ohne Netzwerkverbindung wieder her, startet ihn, wartet, bis das System antwortet, und zerstört den Gast wieder. Das Ergebnis bewertet den Sicherungsstand.

Startprüfungen sind aus, bis ein Job sie einschaltet, und sie verlangen einem Knoten viel ab: eine vollständige Wiederherstellung, Arbeitsspeicher und Festplattenplatz. Lesen Sie Was eine Startprüfung braucht, bevor Sie sie einschalten.

Einschalten

Öffnen Sie den Job unter Server & Clients → VMs & Container → Backup-Jobs (Backup-Job anlegen oder Bearbeiten). Das Formular hat ein Feld Startprüfung mit drei Möglichkeiten:

Auswahl	Was geschieht
Aus	Es wird keine Startprüfung geplant. Das ist die Vorgabe.
Wöchentlich (neuester Sicherungsstand)	Einmal pro Woche und Gast bittet Restow den Knoten, den neuesten Sicherungsstand zu starten.
Nach jeder Sicherung	Sobald der neueste Sicherungsstand eines Gasts noch keine Startprüfung hat, bittet Restow um eine. Ein Sicherungsstand wird einmal gestartet.

Ist ein Zeitplan an, zeigt das Formular auch Nur Gäste mit höchstens so viel Arbeitsspeicher starten (MiB). Die Vorgabe ist 8192 (8 GiB). Ein Gast, der mehr Arbeitsspeicher braucht, wird nicht gestartet, die Prüfung wird übersprungen und sagt warum. Das Warten auf den QEMU Guest Agent dauert fünf Minuten. Das Formular hat dafür kein Feld.

Die Jobs gelten für die Gäste, die sie erfassen: einen zugeordneten Gast und, bei einem Job mit Alle Gäste ohne anderen Backup-Job, jeden Gast in keinem anderen Job. Ein Gast, der von der Sicherung ausgeschlossen wurde (seit 0.4.7), wird von keiner Startprüfung und keiner monatlichen Restore-Prüfung eines Jobs erfasst; das wöchentliche Zurücklesen seines neuesten Sicherungsstands läuft weiter (Einen Gast von der Sicherung ausschließen). Ein privilegierter Container wird nie gestartet, weil Proxmox VE ihn aus einem Backup-Provider nicht wiederherstellen kann. VM-Vorlagen werden gar nicht gesichert.

Jetzt Start prüfen fordert von Hand eine Prüfung eines Sicherungsstands an. Es steht bei jedem Sicherungsstand in der Tabelle Sicherungsstände auf der Seite des Gasts, neben Jetzt prüfen und Als neuen Gast wiederherstellen. Nur Administratoren können es nutzen. Restow sagt „Startprüfung angefordert. Der Knoten beginnt sie bei seiner nächsten Meldung, sobald er Platz dafür hat.“ Eine Prüfung desselben Sicherungsstands, die noch wartet, wird nicht doppelt eingereiht („Eine Startprüfung dieses Sicherungsstands wartet bereits.“), und eine Anforderung wartet bis zu 24 Stunden auf ihren Knoten.

Wo ein Gast nicht geprüft werden kann, sagt die Seite warum, statt die Schaltfläche anzubieten:

„Keine Startprüfung möglich: restow-pve ist auf dem Knoten des Gasts nicht installiert.“
„Keine Startprüfung möglich: restow-pve auf dem Knoten des Gasts führt keine Startprüfungen aus (aktualisieren Sie es, oder sie sind dort ausgeschaltet).“
„Keine Startprüfung möglich: Wiederherstellungen sind auf dem Knoten des Gasts ausgeschaltet.“
„Keine Startprüfung möglich: Proxmox VE kann privilegierte Container nicht über eine Backup-Schnittstelle wiederherstellen.“
„Keine Startprüfung für VM-Vorlagen.“

Über den Sicherungsständen sagt die Seite außerdem, was der Job tut („Startprüfungen: wöchentlich“, „Startprüfungen: nach jeder Sicherung“, „Startprüfungen: im Backup-Job aus“), und wann die letzte Prüfung lief.

Was eine Startprüfung braucht

restow-pve 0.4.0 oder neuer auf dem Knoten. Der Knoten meldet Restow, dass er Startprüfungen ausführen kann, und Restow schickt die Aufgabe nur an einen solchen Knoten. Ein Knoten mit einem älteren Helfer bekommt nie eine. Aktualisieren Sie ihn, siehe Knoten aktualisieren und entfernen.
Wiederherstellungen auf dem Knoten erlaubt. Ein Knoten, der Wiederherstellungen ablehnt (restow-pve config --allow-restores=false), führt auch keine Startprüfungen aus.
Arbeitsspeicher. Der Arbeitsspeicher des Gasts, wie in der Konfiguration des Sicherungsstands, darf das Limit des Jobs nicht überschreiten. Der Knoten muss außerdem so viel Arbeitsspeicher frei haben plus 1 GiB.
Speicher. Der Speicher für den temporären Gast braucht Platz für die Daten des Sicherungsstands plus ein Zehntel davon und 1 GiB. Er ist die Entscheidung des Knotens. Standardmäßig ist es der Fleecing-Speicher, ein lokaler Thin-Speicher, den jeder Knoten mit Sicherungen hat. Siehe Einstellungen auf dem Knoten.
Ein ruhiger Knoten. Je Knoten läuft eine Startprüfung zur Zeit, und nie neben einer Sicherung. Restow plant keine Prüfung, solange der Knoten eine Sicherung meldet, und der Knoten prüft vor dem Start noch einmal: Eine laufende Restow-Sicherung oder -Wiederherstellung oder jeder laufende vzdump-Task von Proxmox VE überspringt die Prüfung.

Eine Prüfung, die sich nicht sicher ausführen lässt, wird mit dem Grund übersprungen (zu wenig Arbeitsspeicher, zu wenig Platz, eine Sicherung läuft, eine andere Startprüfung läuft, Wiederherstellungen oder Startprüfungen sind auf dem Knoten ausgeschaltet). Übersprungene Prüfungen bewerten nichts und lösen keinen Alarm aus. Ein nicht bewerteter Sicherungsstand bleibt, wie er war.

Was der Knoten tut

Der Knoten des Gasts erledigt die Arbeit, mit dem API-Token, den er schon hat (er braucht kein neues Recht), und mit qm und pct, die der Dienst als root ausführt.

Prüft. Eine Prüfung zur Zeit (eine Sperrdatei je Knoten), keine Sicherung, genug Arbeitsspeicher und Platz, wie oben.
Stellt wieder her, auf dem normalen Weg der Wiederherstellung: eine neue VMID aus dem Cluster, im Pool restow-restore, ohne Start. Der ursprüngliche Gast wird nie angefasst. Eine Wiederherstellung, die scheitert, ist ein rotes Ergebnis.
Isoliert ihn vor dem Start. Der temporäre Gast bekommt das Tag restow-boottest und den Namen restow-boottest-<vmid>. Jede Netzwerkkarte bekommt link_down=1 oder wird mit der isolierten Bridge verbunden, die der Knoten nennt (ein Container verliert seine Netzwerkschnittstellen). PCI- und USB-Passthrough, serielle und parallele Ports des Hosts, virtiofs-Freigaben, die Geräte- und Bind-Mounts eines Containers und das Hook-Skript werden entfernt. ISO-Laufwerke werden geleert, onboot und protection werden ausgeschaltet, und das Gerät des QEMU Guest Agent wird eingeschaltet, damit ein installierter Agent antworten kann. Der Knoten liest die Konfiguration zurück: Ein Gast, der noch eine verbundene Netzwerkkarte hat, wird nie gestartet.
Startet ihn und wartet. qm start, dann alle fünf Sekunden ein Ping über den Guest Agent. Grün, sobald der Agent antwortet. Eine VM, die von selbst stoppt, ist rot. Eine VM, die weiterläuft, ohne dass bis zum Ende der Wartezeit eine Antwort kommt, ist gelb. Ein Container ist grün, sobald sein Init-Prozess läuft (pct exec <id> -- cat /proc/1/comm).
Zerstört den Gast in jedem Fall (stoppen, dann zerstören samt Festplatten). Eine Markerdatei hält den temporären Gast fest, bevor er existiert. Beim Start des Dienstes und vor jeder Startprüfung wird ein Überbleibsel zerstört: der Gast aus dem Marker, aber nur, wenn das Task-Log belegt, dass dieser Knoten ihn wiederhergestellt hat, und jeder Gast dieses Knotens im Pool restow-restore, der Tag und Namen trägt.

Mit gekappter Netzwerkverbindung erreicht der Gast keine anderen Systeme, und was er auf seine eigenen Festplatten schreibt, wird mit ihm verworfen. Der Start selbst lässt aber das Hochfahren des Gasts ablaufen, Dienste darin laufen also an. Wenn Sie dem Knoten eine isolierte Bridge nennen, stellen Sie sicher, dass diese Bridge wirklich nirgends hinführt.

Ergebnisse

Der Sicherungsstand zeigt sein neuestes bewertetes Ergebnis (grün, gelb oder rot) in der Spalte Startprüfung auf der Seite des Gasts. Jede Prüfung, auch eine übersprungene, ist außerdem ein Lauf der Art Startprüfung in der Tabelle Läufe, und sein Status sagt, wie sie endete.

Ergebnis	Angezeigt als	Bedeutung
Grün	Gestartet	Der QEMU Guest Agent der wiederhergestellten VM hat geantwortet (der Tooltip nennt, nach wie vielen Sekunden), oder der Init-Prozess des wiederhergestellten Containers läuft. Das ist der Nachweis, dass das System hochgekommen ist.
Gelb	Gestartet, keine Antwort	Die wiederhergestellte VM ist gestartet und lief weiter, aber ihr Guest Agent hat nicht rechtzeitig geantwortet. Nichts beweist, dass das System darin funktioniert. Installieren Sie den QEMU Guest Agent in der VM, um den Nachweis zu bekommen.
Rot	Nicht gestartet	Die Wiederherstellung, der Start oder das Hochfahren ist fehlgeschlagen. Die Meldung sagt wie: Seit 0.4.6 zeigt eine Startprüfung, die nicht gestartet ist, die Meldung des Knotens unter ihrem Badge, auf der Seite des Gasts und in der Tabelle der Wiederherstellbarkeit, und ein längerer Text öffnet sich bei Hover oder Tastaturfokus in einer Karte mit dem ganzen Text und einer Schaltfläche Kopieren.
Grau	Übersprungen, Nicht durchgeführt	Der Knoten hat die Prüfung nicht ausgeführt (siehe oben) oder konnte sie gar nicht durchführen. Bewertet nichts.
Grau	Nicht geprüft	Für diesen Sicherungsstand gibt es noch keine Startprüfung.

Die Wiederherstellbarkeit bewertet den neuesten Sicherungsstand eines Gasts nach seiner Startprüfung, wo es eine gibt. Rot, wenn die Startprüfung oder die Restore-Prüfung fehlgeschlagen ist. Sonst entscheidet eine bewertete Startprüfung: grün nur für einen Gast, der geantwortet hat, gelb für eine VM, die nur gestartet ist. Ohne bewertete Startprüfung entscheidet die Restore-Prüfung wie bisher. Die Zeile der Wiederherstellbarkeit sagt, welche Prüfung sie genutzt hat, siehe Wiederherstellbarkeit.

Benachrichtigungen und Audit

Eine rote Startprüfung löst das Ereignis Startprüfung nicht bestanden aus (boot_test.failed, ein Fehler) und eine gelbe Startprüfung ohne Nachweis (boot_test.unproven, eine Warnung), einmal je Prüfung. Sie kommen in der Glocke, in Ereignisregeln und in Webhooks an und stehen in der Gruppe Wiederherstellbarkeit der Benachrichtigungsmatrix. Siehe Benachrichtigungen und Berichte.
Eine Startprüfung, die Sie mit Jetzt Start prüfen anfordern, steht im Audit-Log als pve.boot_test.requested („Startprüfung des Sicherungsstands angefordert“). Prüfungen, die ein Job plant, erscheinen als Läufe des Gasts, nicht als Audit-Einträge.

Einstellungen auf dem Knoten

Der Knoten entscheidet selbst. Als root auf dem Knoten:

Befehl	Was er tut
`restow-pve config --boot-tests=false`	Der Knoten führt keine Startprüfungen aus und meldet sie nicht mehr an. `--boot-tests=true` schaltet sie wieder ein.
`restow-pve config --boot-test-storage <Speicher>`	Der Speicher für die temporären Gäste. Vorgabe: der Fleecing-Speicher.
`restow-pve config --boot-test-bridge <Bridge>`	Die Netzwerkkarten von Startprüfungen mit dieser isolierten Bridge verbinden, statt sie mit `link_down=1` zu kappen. `-` löscht sie.

Jeder Befehl speichert die Einstellung und sagt „Saved. Restart the service: systemctl restart restow-pve“ (englischer Text). restow-pve status zeigt den Stand („boot tests: on, storage local-lvm, NICs link_down=1“, englischer Text). Der Knoten meldet sich innerhalb einer Minute bei Restow, und die Seite des Gasts zeigt dann, ob er Startprüfungen ausführen kann. Während eine Startprüfung läuft, nennt /var/lib/restow-pve/boottest/current.json den temporären Gast, und /run/restow-pve/boottest.lock hält die Sperre.

Was eine Startprüfung nicht prüft

Sie prüft keine Ports, Dienste oder Anwendungen im Gast, und sie schaut weder auf einen Bildschirm noch auf eine serielle Konsole. Grün heißt, dass das Betriebssystem hochgekommen ist und der Guest Agent (oder der Init-Prozess des Containers) geantwortet hat.
Eine Windows-VM ohne Guest Agent ist bestenfalls gelb.
Ein Gast, der Passthrough-Hardware zum Starten braucht, kann scheitern, weil die Prüfung diese Hardware entfernt.
Sie ersetzt keine Wiederherstellung in ein eigenes Netzwerk. Sie weist nur den Start nach.

Was getestet wurde

Die Release Notes von 0.4.0 führen Startprüfungen als nur gegen einen simulierten Proxmox-VE-Knoten getestet auf, noch nicht gegen einen echten Proxmox-VE-Cluster, und die bekannten Probleme von 0.4.0 gelten in 0.4.7 weiter. Kein Release bis 0.4.2 meldet einen Test auf einem Proxmox-VE-Host. Probieren Sie Startprüfungen zuerst an ein oder zwei Testgästen aus, beobachten Sie, was der Knoten tut, und prüfen Sie, dass die temporären Gäste danach weg sind, bevor Sie sie für einen Cluster einschalten.