Backup-Jobs und Schutz

Vor der Aufnahme in einen Backup-Job wird nichts gesichert. Das ist dieselbe Regel wie bei Rechnern. Ein Gast gilt nur als geschützt, solange er auf seinem Knoten vorhanden ist, keine VM-Vorlage ist und von einem aktiven Backup-Job erfasst wird: dem Job, dem er zugeordnet ist, oder dem Job für alle Gäste, solange er keinem zugeordnet ist. Ein Gast, der in keinem Job ist, zählt überall (Status, Wiederherstellbarkeit, Inventar) als „in keinem Backup-Job“, es sei denn, eine Administration hat ihn bewusst von der Sicherung ausgeschlossen (Einen Gast von der Sicherung ausschließen).

Backup-Jobs für Gäste

Backup-Jobs für VMs und Container liegen auf der Seite VMs & Container (Server & Clients → VMs & Container), im Reiter Backup-Jobs (vor 0.4.3 ein Abschnitt derselben Seite). Sie sind ein eigenes Modell, getrennt von den Jobs für Postfächer und Rechner, siehe Backup-Jobs. Seit 0.4.0 stehen sie auch unter Server & Clients → Jobs, siehe Proxmox-VE-Jobs in der Job-Liste. Sie können einen auch im Inventar mit Neuer Job … anlegen, siehe unten.

Wählen Sie Backup-Job anlegen oder Bearbeiten bei einem vorhandenen Job. Der Dialog nennt das Repository, in dem die Sicherungen des Jobs landen (siehe Wo Sicherungen landen):

Feld	Bedeutung
Name	Pflichtangabe. Ein Name kann nur von einem Job genutzt werden.
Zeitplan	Seit 0.4.2 dieselben Rhythmen wie bei einem Mail-Job: alle paar Stunden, täglich, an gewählten Wochentagen, monatlich an einem Tag des Monats oder ein Cron-Ausdruck, jeweils zu einer Uhrzeit in einer Zeitzone, mit einer Vorschau der nächsten Läufe. Eine Sicherung öfter als stündlich wird nicht angeboten. Ein neuer Job beginnt täglich um 22:00, und ein Job von vor 0.4.2 behält seine tägliche Uhrzeit (das Feld hieß damals Täglich um).
Alle Gäste ohne anderen Backup-Job	Der Job erfasst jeden Gast, der keinem Job zugeordnet ist, auch Gäste, die später dazukommen. Nur ein Job je Mandant kann das eingeschaltet haben, und Restow lehnt einen zweiten ab („A job with this name, or a second job for all guests, exists already.“, englischer Text).
Tägliche Sicherungsstände, Wöchentliche Sicherungsstände, Monatliche Sicherungsstände	Die Aufbewahrung: wie viele Sicherungsstände bleiben. Die Vorgaben sind 7 tägliche, 4 wöchentliche und 6 monatliche.
Monatliche Restore-Prüfung	Optional. Stellt jeweils einen Gast im Pool `restow-restore` wieder her, prüft ihn und löscht ihn danach wieder. Braucht einen Speicher für die Restore-Prüfung, eine Proxmox-VE-Speicher-ID mit Platz für den wiederhergestellten Gast.
Startprüfung	Aus (die Vorgabe), Wöchentlich (neuester Sicherungsstand) oder Nach jeder Sicherung. Seit 0.4.0. Ist ein Zeitplan an, begrenzt Nur Gäste mit höchstens so viel Arbeitsspeicher starten (MiB) die Gäste, die gestartet werden (Vorgabe 8192). Siehe Startprüfungen.
VMs und Container in diesem Job	Eine Liste mit einem Kästchen für jeden Gast, der sich sichern lässt (seit 0.4.7 nicht die, die von der Sicherung ausgeschlossen sind). Kreuzen Sie die Gäste an, die in den Job gehören. Ein Gast, der in einem anderen Job ist, sagt „In <Job>“ und, sobald Sie ihn ankreuzen, „Wechselt aus <Job>“, weil ein Gast jeweils in einem Job ist. Seit 0.4.0.

Der Dialog hat kein Feld für den Sicherungsmodus. Der empfohlene Job und die Jobs aus dem Dialog nutzen den Modus snapshot, siehe Wie ein Job läuft.

Die Tabelle der Jobs zeigt die Zahl der Gäste (der Tooltip sagt Alle Gäste oder Ausgewählte Gäste), den Zeitplan (zum Beispiel „täglich um 22:00“ oder Nur von Hand bei einem Job ohne Zeitplan), den Nächsten Lauf und seit 0.4.3 die Aktuelle Runde (Läuft nicht oder „2 von 5 fertig“ mit der Zahl der fehlgeschlagenen). Beim Löschen eines Jobs wird nachgefragt: Die Gäste des Jobs werden danach nicht mehr gesichert, und vorhandene Sicherungsstände bleiben erhalten.

Wie ein Job läuft

Alle paar Minuten sucht der Restow-Worker nach fälligen Jobs, nach dem Zeitplan des Jobs in seiner eigenen Zeitzone gelesen. Für jeden fälligen Job legt er eine Sicherungsaufgabe je Gast an, den der Job erfasst und den ein Knoten mit dem Helfer hostet. Ein Gast, der eine VM-Vorlage ist, nicht mehr gemeldet wird oder auf den schon eine Sicherung wartet, bleibt außen vor. Bei seiner nächsten Meldung startet der Knoten die Sicherung über Proxmox VE (vzdump, Modus snapshot: Der Job-Dialog hat kein Feld für suspend oder stop, weiterhin in 0.4.7) auf den Speicher restow, mit Fleecing auf seinem Thin-Speicher. Die Notiz der Sicherung in Proxmox VE ist der Gastname, gefolgt von (Restow). Die Aufbewahrung läuft auf dem Restow-Server: Das Storage-Plugin lehnt Entfernen und Prune in Proxmox VE ab.

Die Sicherung einer laufenden VM ist inkrementell, wenn die Dirty Bitmap erhalten blieb, siehe Vollständiges Lesen nach einem Neustart.

Während eine Sicherung läuft, zeigt der Gast ihren Fortschritt (zum Beispiel „34 % · 3,2 GB von 9,4 GB · 85 MB/s“), siehe Fortschritt einer laufenden Sicherung. Ein Job, den ein Restow-Update unterbricht, geht nicht verloren: Ein Knoten mit restow-pve 0.4.0 oder neuer versucht es fünf Minuten lang weiter, siehe Während Restow aktualisiert.

Aufbewahrung

Die Aufbewahrung behält die Sicherungsstände, die die Regeln nennen, und entfernt die übrigen. Sie läuft nur auf dem Server. Wird ein Sicherungsstand bereinigt, gibt Restow die Chunk-Verweise frei, die er hielt, löscht sein Manifest und vergisst bei einem Container seinen restic-Snapshot. Die Chunks selbst gibt später die Garbage Collection der Speicherprüfung frei.

Es gelten die Regeln des Jobs, dem der Gast zugeordnet ist. Ein Gast, den nur der Job für alle Gäste erfasst, ohne Zuordnung, wird nach den Vorgaben bereinigt: 7 tägliche, 4 wöchentliche und 6 monatliche Sicherungsstände, unabhängig davon, was die Felder dieses Jobs sagen. Das gilt weiterhin in 0.4.7. Ordnen Sie den Gast dem Job zu, wenn er dessen Regeln folgen soll. Der empfohlene Job (unten) behält dieselben Zahlen wie die Vorgaben.

Ein Sicherungsstand bleibt außerdem erhalten, solange Restow die Aufbewahrung des Gasts wegen eines verdächtigen Sicherungsstands anhält, siehe Ransomware-Erkennung. Ein Sicherungsstand, den ein unveränderbares Repository noch sperrt, bleibt, bis die Sperre abgelaufen ist, siehe Unveränderbare Backups.

Restore-Prüfungen

Restow liest einen Sicherungsstand zurück und vergleicht ihn mit dem, was es aufgezeichnet hat: Bei einer VM liest es eine Stichprobe von 8 Datenblöcken je Festplatte aus dem Repository zurück und vergleicht sie mit der SHA-256 in der Blockkarte, bei einem Container führt es restic check auf einer 5-%-Teilmenge des Repositorys aus. Das geschieht zu drei Zeitpunkten:

Direkt nach jeder Sicherung (seit 0.4.2). Der Commit eines neuen Sicherungsstands markiert ihn, und der nächste Proxmox-VE-Durchlauf des Workers (alle fünf Minuten) liest ihn zurück: höchstens 20 angeforderte Prüfungen je Durchlauf, die älteste Anforderung zuerst. Seit 0.4.3 ist die Prüfung zwei Minuten nach dem Commit fällig, wenn restic auf dem Knoten das Repository losgelassen hat. Die Einstellung Jeden neuen Sicherungsstand direkt nach der Sicherung prüfen unter Installation → Proxmox VE ist standardmäßig eingeschaltet. Ein Provider-Administrator kann sie lesen, ein Inhaber des Provider-Teams ändert sie, und sie gilt für die ganze Installation: Es gibt keine Einstellung je Mandant. Ausgeschaltet wartet ein neuer Sicherungsstand auf die wöchentliche Prüfung.
Wöchentlich, der neueste Sicherungsstand jedes Gasts, höchstens 10 je Durchlauf.
Wenn Sie es anfordern. Jetzt prüfen bei einem Sicherungsstand auf der Seite des Gasts prüft genau diesen, auch einen älteren. In der Wiederherstellbarkeit prüft Jetzt prüfen bei einem Gast dessen neuesten Sicherungsstand und Alle ungeprüften prüfen den neuesten Sicherungsstand jedes Gasts, den noch keine Prüfung gelesen hat und auf den keine wartet. Eine eingereihte Prüfung zeigt Prüfung eingereiht und läuft in wenigen Minuten; seit 0.4.6 sagt die Zeile Prüfung eingereiht unter der letzten Prüfung und die Seite des Gasts über dem früheren Ergebnis, bis das neue Ergebnis da ist, und beide aktualisieren sich in der Zwischenzeit alle paar Sekunden; die Wiederherstellbarkeit sagt außerdem, bei wie vielen Gästen die Wiederherstellbarkeit noch nicht nachgewiesen ist und wie viele Prüfungen auf den nächsten Durchlauf warten. Seit 0.4.3 nimmt Alle ungeprüften prüfen auch die Gäste, deren Prüfung nicht laufen konnte.

Eine rote Prüfung zeigt jetzt, was sie gefunden hat, zum Beispiel den Fehler von restic oder den Block, der sich nicht lesen ließ, unter ihrem Zeichen 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“. Das Ergebnis steht in der Spalte Restore-Prüfung auf der Seite des Gasts und fließt in die Wiederherstellbarkeit ein. Die Fußzeile der Wiederherstellbarkeit nennt den Zeitplan für Microsoft 365 als solchen und sagt in einer eigenen Zeile, wie VMs und Container geprüft werden.

Eine Prüfung, die eine gesperrte Repository aussperrt, ist keine fehlgeschlagene Prüfung (seit 0.4.3). Bei einem Container braucht die Prüfung die Sperre des Repositorys, und ein anderer Vorgang, meist die eigene Sicherung des Gasts, kann sie halten. Der Server entfernt veraltete restic-Sperren vor der Prüfung und vor der Aufbewahrung, wartet bis zu zwei Minuten auf eine Sperre, die ein anderer Vorgang hält, prüft einen Gast nicht, solange ein Vorgang von ihm läuft, und prüft einen neuen Sicherungsstand frühestens zwei Minuten nach seinem Commit. Eine Prüfung, die eine Sperre weiter aussperrt, wird verschoben und zehn Minuten später erneut versucht, das vorherige Ergebnis gilt so lange. Nach zwei Stunden steht Nicht prüfbar: Repository gesperrt da, gelb, nie rot und nie grün, mit der Angabe, wer die Sperre hält. Einzelheiten und die andere Ursache, eine Prüfung, die restic abgebrochen hat: Restore-Prüfungen, die nicht laufen konnten. Eine fehlgeschlagene Prüfung behält die Zeilen der restic-Ausgabe, die sie erklären, nicht nur die letzte.

Die Monatliche Restore-Prüfung eines Jobs geht weiter und stellt wirklich wieder her: etwa einmal im Monat je Gast, jeweils ein Gast, stellt sie den neuesten Sicherungsstand im Pool restow-restore wieder her, prüft, dass der wiederhergestellte Gast eine lesbare Konfiguration hat, und löscht ihn wieder. Sie braucht freie Kapazität auf dem Zielspeicher und ist standardmäßig aus. Privilegierte Container bleiben außen vor, weil Proxmox VE sie nicht wiederherstellen kann.

Ein Text hinter einem Badge oder einer abgeschnittenen Zeile, hier und bei der Startprüfung (die Restore-Prüfung einer VM oder eines Containers auf der Seite des Gasts und in der Tabelle der Wiederherstellbarkeit), öffnet sich seit 0.4.6 bei Hover oder Tastaturfokus in einer Karte mit dem ganzen Text, den Sie markieren und mit der Schaltfläche Kopieren kopieren können, statt in einem Browser-Tooltip.

Keine der beiden Prüfungen startet den Gast. Die Startprüfung eines Jobs tut es, in Isolation, siehe Startprüfungen. Die Wiederherstellbarkeit bewertet den neuesten Sicherungsstand dann nach der Startprüfung, wo es eine gibt.

In Proxmox VE gestartete Sicherungen

Eine Sicherung, die Sie in Proxmox VE auf den Speicher restow starten (in der Weboberfläche oder durch einen Proxmox-VE-Backup-Job), funktioniert genauso und erscheint in den Läufen des Gasts als in Proxmox VE gestartet. Bei einer VM muss Fleecing an sein, mit einem Thin-Speicher, zum Beispiel:

vzdump <vmid> --storage restow --mode snapshot --fleecing enabled=1,storage=<Thin-Speicher>

Eine Sicherung stoppen und eine Warteschlange anhalten

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 auch eine stoppen. Jedes Stoppen fragt vorher nach und wird im Audit-Log festgehalten.

Sicherung stoppen steht 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: Der Knoten sieht sie nie, und der Verlauf zeigt einen Lauf, der „Abgebrochen von“ und den Namen der Person sagt. Eine Sicherung, die der Knoten schon bekommen hat oder die läuft, erhält eine Abbruchanforderung, und die Seite sagt „Wird abgebrochen…“, bis der Knoten sie gestoppt hat, meist innerhalb von 15 Sekunden.
Wie der Knoten sie stoppt. restow-pve 0.4.2 oder neuer hält seinen Heartbeat aufrecht, solange eine Sicherung läuft (alle 15 Sekunden), und bekommt den Abbruchauftrag damit. Bei einer Sicherung, die Restow angefordert hat, stoppt er die vzdump-Aufgabe über die Proxmox-VE-API: vzdump beendet die Sicherung des Gasts, entfernt seinen Snapshot und das Fleecing-Image. Bei einer Sicherung, die in Proxmox VE gestartet wurde (ein Proxmox-VE-Backup-Job mit mehreren Gästen), beendet er den Restow-Provider dieses Gasts, sodass vzdump mit den anderen Gästen weitermacht.
Ältere Knoten. Der Server lehnt jeden Upload eines abgebrochenen Laufs ab (Blöcke, Commit, restic), ein Knoten vor 0.4.2 beendet die Sicherung also bei seinem nächsten Aufruf. Seit 0.4.3 öffnet der restic-Zugang eines abgebrochenen oder beendeten Laufs das Repository weiterhin und löscht die Sperrdateien, die dieser Lauf geschrieben hat, damit restic seine Sperre auf dem Weg nach draußen freigibt; jede andere Anfrage von ihm wird abgelehnt und im Audit-Log festgehalten (pve.node.denied). Welche Sperrdateien ein Lauf geschrieben hat, behält nur der API-Prozess: Nach einem API-Neustart (einem Update) lässt sich die Sperre eines Laufs nicht mehr von der eines anderen unterscheiden und bleibt, bis sie veraltet ist (30 Minuten), dann entfernt sie die nächste Prüfung oder die Aufbewahrung.
Das Ende. Der Lauf endet als Abgebrochen, nicht als fehlgeschlagen: Er löst keinen Fehleralarm aus, der Gast sagt nicht „Letzte Sicherung fehlgeschlagen“, die letzte Sicherung des Gasts bleibt, wie sie war, und die Sicherungsstände bleiben unberührt, weil nichts vom gestoppten Lauf festgeschrieben wird. Einen abgebrochenen Lauf, dessen Knoten 15 Minuten lang stumm bleibt, schließt der Worker.
Warteschlange anhalten (je Knoten, im Zeilenmenü des Reiters Knoten): Dem Knoten wird keine neue Sicherung übergeben, bis Sie Warteschlange fortsetzen wählen. Eine laufende Sicherung läuft weiter. Geplante Sicherungen warten und verfallen wie gewohnt nach 12 Stunden. Der Knoten zeigt „Angehalten von“ und den Namen der Person.
Alle wartenden zurückziehen, je Knoten im Zeilenmenü des Reiters Knoten oder für den ganzen Mandanten im Seitenkopf, zieht jede Sicherung zurück, die noch nicht begonnen hat. Laufende Sicherungen laufen weiter: Stoppen Sie sie einzeln.

Einen ganzen Job lassen Sie seit 0.4.5 in der Jobliste starten und stoppen: Jetzt starten bei einem Proxmox-VE-Job (Server & Clients → Jobs) reiht eine Sicherung jedes Gasts ein, den der Job umfasst, wie sein Zeitplan es täte, ohne den Zeitplan zu verschieben (Gäste, die schon eine wartende Sicherung haben, auf einem Knoten ohne restow-pve liegen oder die unbestätigte VM des Restow-Servers sind, werden ausgelassen und gezählt); Stoppen zieht die wartenden Sicherungen des Jobs zurück und bittet die laufenden, anzuhalten, und sie enden abgebrochen, nicht fehlgeschlagen. Siehe Backup-Jobs.

Das Audit-Log hält pve.backup.cancelled, pve.queue.cancelled, pve.queue.paused und pve.queue.resumed fest, für einen ganzen Job pve.job.run_requested und pve.job.cancelled. Rechner und Freigaben haben ein eigenes Stoppen (Server und Clients, Freigaben). Die Routen hinter den Schaltflächen stehen unter API-Referenz.

Die VM des Restow-Servers selbst

Die VM, auf der Restow läuft, mit Restow selbst zu sichern, kann sich gegenseitig blockieren: Die Sicherung hält den Server an oder friert ihn ein, der die Sicherung empfängt, und für die Wiederherstellung braucht es genau den Server, der wiederhergestellt werden soll. Seit 0.4.2 erkennt Restow diese VM und fragt Sie, bevor es sie sichert. Sichern Sie sie stattdessen mit der Sicherung von Proxmox VE selbst (vzdump) auf einen anderen Speicher, und behalten Sie die Datenbank-Dumps von Restow (Restow selbst sichern).

Erkannt an ihrer SMBIOS-UUID. Die Konfiguration einer VM enthält smbios1: uuid=..., was der Gast als /sys/class/dmi/id/product_uuid sieht. Die api liest ihre eigene, restow-pve 0.4.2 oder neuer meldet die UUID jeder VM mit dem Inventar, und eine Übereinstimmung markiert den Gast. RESTOW_HOST_SMBIOS_UUID in der Umgebung der api überschreibt die Datei, für einen Host, der /sys verbirgt (Umgebungsvariablen). Eine Platzhalter-UUID (nur Nullen) passt nie.
Von Hand markiert. Restow in einem LXC-Container, auf einem anderen Host oder hinter einem Knoten vor 0.4.2 wird nicht von selbst gefunden. Ein Administrator kreuzt auf der Seite des Gasts Dies ist der Restow-Server an. Das Abwählen nimmt die Markierung zurück, und die Bestätigung mit ihr.
Was sich ändert. Der Gast zeigt in den Listen und im Job-Editor eine Markierung Restow-Server. Kein Job plant eine Sicherung von ihm, Empfohlenen Job anlegen lässt ihn aus, und Jetzt sichern und das Aufnehmen in einen Job werden abgelehnt, bis ein Administrator das Risiko im Dialog bestätigt („Trotzdem sichern“; im Job-Editor ein Kästchen, „Ich kenne das Risiko und möchte, dass dieser Job die VM trotzdem sichert“). Ohne die Bestätigung antwortet die API mit 409 (urn:restow:problem:pve-restow-server). Das Audit-Log hält pve.guest.restow_server (markiert oder Markierung aufgehoben) und pve.guest.self_backup_confirmed fest.

Einen Gast von der Sicherung ausschließen (seit 0.4.7)

Viele Gäste eines Clusters sind nicht zum Sichern gedacht: Test-VMs oder Gäste, die schon eine andere Sicherung abdeckt. In keinem Job würde jeder als „in keinem Backup-Job“ zählen und den Mandanten von Grün abhalten. Seit 0.4.7 schließt eine Administration einen solchen Gast bewusst aus.

Wie. Von der Sicherung ausschließen auf der Seite des Gasts oder, für eine Auswahl der Gäste eines Knotens, im Inventar (Server & Clients → Inventar). Wieder einschließen auf der Seite und in der Inventarzeile des Gasts nimmt es zurück. Mandanten-Administratoren und die Administratoren des Provider-Teams dürfen das (die Rollen).
Kein Job sichert ihn. Auch nicht der Job für alle Gäste, und der empfohlene Job lässt ihn weg. Der eigene Job des Gasts bleibt vermerkt, sodass das Wiedereinschließen herstellt, was er hatte.
Wartende Sicherungen werden zurückgezogen. Das Ausschließen zieht die Sicherungen zurück, die für den Gast eingereiht sind. Eine, die dem Knoten schon übergeben war, bekommt eine Abbruchanfrage, und eine laufende endet, wie sie nach Stoppen enden würde. Eine Sicherung, die im selben Moment eingereiht wurde, wird beim nächsten Heartbeat des Knotens zurückgezogen, bevor der Knoten sie bekommt, und erscheint im Verlauf als abgebrochener Lauf mit „The guest was excluded from backup before it started.“
Jetzt sichern und ein Job werden abgelehnt. Jetzt sichern und das Zuordnen des Gasts zu einem Job antworten mit 409 (urn:restow:problem:pve-guest-excluded), bis er wieder eingeschlossen ist. Ihn aus seinem Job zu nehmen bleibt möglich.
Die Sicherungsstände bleiben. Sie bleiben wiederherstellbar, die Aufbewahrung behandelt sie wie bisher, und die wöchentliche Restore-Prüfung des neuesten Sicherungsstands läuft weiter. Die monatliche Restore-Prüfung des Jobs und Startprüfungen decken den Gast nicht mehr ab.
Er zählt nirgends als ungeschützt: nicht in den Übersichten, der Wiederherstellbarkeit, den Warnungen, Sicherung überfällig, der Statistik, den Job-Zählern der Ansicht über alle Mandanten oder der Provider-Ansicht, und er hält einen Mandanten nie von Grün ab. Die Zähler melden ihn als excluded (Inventar, Gäste und Sicherungsstände).
In den Listen. Bei VMs & Container steht ein ausgeschlossener Gast als Ausgeschlossen (grau, nie ein Problem, was seine früheren Läufe auch sagten), trifft nur den Zustandsfilter Ausgeschlossen und sortiert nach jedem Problem. Das Inventar zeigt Ausgeschlossen: N je Knoten, der Detailbereich des Gasts sagt Von der Sicherung ausgeschlossen unter seinem Job (dort lässt es sich nicht ändern), und der Job-Dialog bietet ausgeschlossene Gäste nicht mehr an.
API und Audit. PUT /api/v1/pve/guests/:id/excluded mit { "excluded": true } oder false, auditiert als pve.guest.excluded mit der Zahl der zurückgezogenen wartenden Sicherungen, bevor sie den Knoten erreichten (eine, die dem Knoten schon übergeben war, wird nicht mitgezählt). Einen Gast zweimal auszuschließen ändert nichts. GET /api/v1/pve meldet excludedAt und excludedBy je Gast und GET /api/v1/status die Zahl als guests.excluded (API-Referenz).
Nach dem Update. Es schließt keinen Gast aus: Gäste ohne Job zählen weiter als „in keinem Backup-Job“, bis eine Administration sie ausschließt. restow-pve braucht dafür kein Update; der Server zieht die Sicherungen eines ausgeschlossenen Gasts zurück, bevor ein Knoten sie bekommt. Das Ausschließen einer Auswahl im Inventar sendet eine Anfrage je Gast, weil es keine Sammelroute gibt; scheitert eine, bleiben die Gäste davor ausgeschlossen, und die Liste aktualisiert sich. Der Ausschluss lief vor dem Release nicht gegen einen echten Proxmox-VE-Knoten.

Proxmox-VE-Jobs in der Job-Liste

Seit 0.4.0 listet Server & Clients → Jobs die Jobs für VMs und Container neben den Jobs der Rechner. Die Spalte Typ sagt Proxmox VE oder Rechner, und die Seite ist unter Backup-Jobs erklärt. Was für Proxmox VE besonders ist:

Umfang. Die Zahl der VMs und Container des Jobs. Ein Job für alle Gäste ergänzt „und jeder Gast ohne anderen Job“ und zählt auch diese Gäste.
Zeitplan, Letzter Lauf, Nächster Lauf. Der Rhythmus in Worten (seit 0.4.2, zum Beispiel täglich zu einer Uhrzeit oder alle paar Stunden; Nur von Hand bei einem Job ohne Zeitplan) mit seiner Zeitzone, wann der Job zuletzt lief und wann er als Nächstes läuft. Solange eine geplante Runde läuft, zeigt die Zeile, wie weit sie ist („2 von 5 Gästen fertig“), mit der Zahl der laufenden, wartenden und fehlgeschlagenen.
Manuelle Sicherungen. Eine Sicherung, die jemand mit Jetzt sichern oder in Proxmox VE gestartet hat, steht als eigene Zeile Manuelle Sicherung · <Gast>, bis sie endet. Sie zeigt den Fortschritt und führt zur Seite des Gasts.
Jetzt starten und Stoppen (seit 0.4.5) stehen in jeder Zeile und in ihrem …-Menü, und ein Klick auf eine Zeile öffnet einen Detailbereich des Jobs, wie in den anderen Joblisten (Backup-Jobs).
Neuer Job ist ein Menü mit einem Eintrag je Typ. Der Eintrag Proxmox VE (VMs & Container) öffnet denselben Dialog wie Backup-Job anlegen, mit der Liste der VMs und Container, die in den Job kommen.
Der Editor der Rechner-Jobs sagt, dass VMs und Container auf Proxmox VE von Proxmox-VE-Jobs gesichert werden, mit Links zu VMs & Container und zu den Gästen im Inventar.

Bearbeiten und Löschen eines Proxmox-VE-Jobs geschehen weiterhin auf seiner eigenen Seite, VMs & Container.

Empfohlenen Job anlegen

Neben jedem Hinweis, dass etwas „keinen Job“ hat (in den Jobs, im Inventar, bei den Quellen, im Verzeichnis und bei VMs & Container) und als Alles ohne Job schützen auf der Karte Wiederherstellbarkeit im Dashboard schützt Empfohlenen Job anlegen mit einem Klick, was keinen Job hat. Für Proxmox VE legt es einen Job an:

benannt „VMs & Container · täglich 22:00“ und als Empfohlen markiert, täglich um 22:00 in der Zeitzone des Mandanten, im Modus snapshot,
mit 7 täglichen, 4 wöchentlichen und 6 monatlichen Sicherungsständen,
mit den Gästen, die ohne Job waren, als Mitgliedern, außer der VM, auf der Restow selbst läuft (Die VM des Restow-Servers selbst), und, seit 0.4.7, Gästen, die von der Sicherung ausgeschlossen wurden.

Eine Vorschau sagt zuerst, was der Klick anlegt oder ergänzt („Neuer Job: …“ oder „Zu … hinzufügen“), welche Gäste er aufnimmt und was er auslässt („… ist bereits in einem Job oder lässt sich nicht sichern“). Ein zweiter Klick legt keinen weiteren Job an: Er ergänzt neue Gäste im selben. Gäste, die schon in einem Job sind oder die ein Job für alle Gäste erfasst, werden nie verschoben. Nur Administratoren können es nutzen, und jeder angelegte Job und jeder ergänzte Gast steht im Audit-Log, wie eine Änderung im Editor. Die wöchentliche Restore-Prüfung läuft ohnehin für jeden Gast, Startprüfungen bleiben aus, bis Sie sie im Job einschalten.

Gäste im Inventar schützen

Seit 0.3.6 können Sie Gäste in Backup-Jobs aufnehmen, ohne das Inventar zu verlassen. Öffnen Sie Server & Clients → Inventar (mit dem Filter Alle oder Server). Sobald ein Cluster verbunden ist, listet der Abschnitt Proxmox VE jeden Knoten als Zeile, die Sie aufklappen können. Das ist für Administratoren.

Klappen Sie einen Knoten auf. Seine Zeile zeigt den Zustand des Knotens (Verbunden oder Getrennt), die Zahl der VMs und Container und Zählwerte wie Geschützt, Fehlgeschlagen, Ohne Job und Noch nicht gesichert. Die aufgeklappte Zeile listet seine Gäste mit ID, Name, Status, Backup-Job, Sicherung, Schutz und Jetzt sichern.
Wählen Sie den Job eines Gasts. Die Spalte Backup-Job ist für jeden Gast eine Auswahl: ein vorhandener Job, Kein Backup-Job oder Neuer Job …. Die Änderung gilt sofort. Kein Backup-Job nimmt den Gast aus seinem Job.
Wählen Sie Gäste aus. Sie können sie einzeln ankreuzen. Das Kästchen im Tabellenkopf (Alle VMs und Container dieses Knotens auswählen) nimmt alle Gäste des Knotens. Haben einige Gäste keinen Job, zeigt der Knoten „N VMs und Container haben keinen Backup-Job.“ mit Auswählen, das genau diese Gäste mit einem Klick auswählt. Gäste, die sich nicht sichern lassen (VM-Vorlagen und nicht mehr gemeldete Gäste), lassen sich nicht ankreuzen.
Handeln Sie auf der Auswahl. Die Leiste über der Tabelle zeigt „N ausgewählt“ mit Zu Job hinzufügen …, Jetzt sichern und Auswahl aufheben.
- Zu Job hinzufügen … ist eine Liste Ihrer Jobs mit Neuer Job … am Ende. Nachdem Sie einen Job gewählt haben, sind die Gäste in ihm („N VMs und Container sind jetzt im Job.“).
- Neuer Job … öffnet den Dialog für einen neuen Job und legt die Auswahl, sobald Sie ihn speichern, in den neuen Job. Neuer Job … in der Spalte Backup-Job eines einzelnen Gasts macht dasselbe für diesen Gast.
- Jetzt sichern sichert die ausgewählten Gäste gemeinsam.
Jetzt sichern für einen Gast ist die Schaltfläche am Ende seiner Zeile. Auf der Seite des Gasts öffnet sie seit 0.4.2 einen kurzen Bestätigungsdialog, der das Repository nennt, in dem die Sicherung landet; der Knoten startet die Sicherung bei seiner nächsten Meldung. Wartet oder läuft gerade eine Sicherung des Gasts, ist die Schaltfläche stattdessen Sicherung stoppen (Eine Sicherung stoppen und eine Warteschlange anhalten).

Eine Sicherung, die Sie anfordern, wird eingereiht: Der Knoten startet sie bei seiner nächsten Meldung, meist innerhalb einer Minute. Wartet auf diesen Gast schon eine Sicherung, sagt Restow das („Für diesen Gast wartet bereits eine Sicherung auf den Knoten.“) und reiht keine zweite ein. Auf der Seite VMs & Container und im Inventar sagt der Zustand des Gasts Wartet auf den Knoten und dann Sicherung läuft, mit dem Fortschritt der Sicherung. Der Tooltip von Wartet auf den Knoten sagt, seit wann („Angefordert am …“) und wann der Knoten sich zuletzt gemeldet hat. Die Markierung ist gelb, solange der Knoten getrennt ist, weil ein getrennter Knoten nichts startet, bis er sich wieder meldet. Beide Seiten aktualisieren sich alle fünf Sekunden, solange ein Gast auf seinen Knoten wartet oder gesichert wird.

Gut zu wissen

Das Inventar zeigt den Job, dem ein Gast zugeordnet ist. Ein Gast, den nur deshalb ein Job erfasst, weil dieser Alle Gäste ohne anderen Backup-Job eingeschaltet hat, wird gesichert und zählt in Status und Wiederherstellbarkeit als geschützt. Das Inventar und seine Zählwerte zeigen ihn trotzdem als Kein Backup-Job, weil der Gast keinem Job zugeordnet ist, und ebenso die Spalte Backup-Job von VMs & Container. Ordnen Sie ihn einem Job zu, um ihn dort als Geschützt zu sehen. Das gilt weiterhin in 0.4.7. Der Hinweis „N VMs und Container haben keinen Backup-Job“ auf VMs & Container, in der Job-Liste und bei Empfohlenen Job anlegen zählt die tatsächliche Abdeckung, ein Gast des Jobs für alle Gäste steht also nicht darin. Derselbe Hinweis im Inventar zählt nach Zuordnung, und Empfohlenen Job anlegen lässt dort einen solchen Gast aus („bereits in einem Job“).
Einen Gast aus einem Job zu nehmen, entfernt keine Sicherung. Der Gast behält seine Sicherungsstände, und sie behalten ihre Bewertung. Erfasst ihn kein Job für alle Gäste, zählt er als in keinem Backup-Job, und es entsteht kein neuer Sicherungsstand, bis Sie ihn wieder zuordnen.
Ein Gast auf einem Knoten ohne den Helfer lässt sich nicht sichern. Restow antwortet „No helper on that node: restow-pve is not enrolled on node … Install it there first.“ (englischer Text). Verbinden Sie den Knoten, siehe Knoten verbinden.
VM-Vorlagen lassen sich nicht sichern. Restow antwortet „Templates cannot be backed up“ (englischer Text).

Mehr dazu, was die Spalten und Zustände bedeuten: Inventar, Gäste und Sicherungsstände.