Im vorherigen Leitfaden haben Sie die erste VM in eine wiederverwendbare Vorlage umgewandelt und diese in Sekundenschnelle statt in Minuten geklont, nämlich „web02“ – eine voll funktionsfähige Kopie, deren Identität bereits festgelegt ist. Weder dieser Klon noch die ihm zugrunde liegende Vorlage existieren bisher an anderer Stelle. Bevor also eines von beiden Daten enthält, die einem Kunden fehlen könnten, richten Sie zunächst das Proxmox-eigene Sicherungssystem vollständig über das Panel ein.
Backup-Auftrag planen
„Datacenter“, „Backup“ in der linken Baumstruktur – hier öffnet sich eine Aufgabenliste, die auf einem neuen Knoten zunächst völlig leer ist. „Hinzufügen“ ist bislang die einzige nützliche Schaltfläche; sie öffnet ein Dialogfeld, in dem alle für eine geplante Sicherung erforderlichen Angaben an einem Ort erfasst werden: welche Gäste, welcher Speicher, wann und wie lange die erzeugten Daten aufbewahrt werden sollen.
Wählen Sie aus, was und wann gesichert werden soll
In der Tabelle „Einzuschließende Gäste“ auf der Registerkarte „Allgemein“ sind alle VMs auf dem Knoten mit einem Kontrollkästchen daneben aufgeführt – dieselben drei VMs wie in den beiden vorherigen Anleitungen. Indem nur „web02“ markiert wird – und nicht die Vorlage oder deren ungenutzte Schwester-VM –, bleibt dieser erste Auftrag auf die eine VM fokussiert, deren Wiederherstellung sich tatsächlich lohnt, falls etwas schiefgeht.
„Knoten bleibt aktiv“ – „Alle“ – sollte man auch in einem Labor mit nur einem Knoten wie diesem so belassen: In einem echten Cluster mit mehreren Knoten bedeutet dies, dass der Job dort ausgeführt wird, wo sich der jeweilige ausgewählte Gast an diesem Tag tatsächlich befindet, anstatt stillschweigend zu scheitern, wenn eine VM von dem Knoten migriert, an den der Job gebunden war. „Schedule“ akzeptiert entweder einen Kalenderausdruck im systemd-Stil oder, wie hier, eine einfache Uhrzeit, und der „Snapshot“-Modus sichert eine laufende VM, ohne sie anzuhalten, und weicht automatisch auf eine einfache Dateikopie aus, sobald sich herausstellt, dass eine VM angehalten wurde – genau wie bei „web02“ in diesem Labor.
Eine Aufbewahrungsrichtlinie festlegen
Auf der Registerkarte „Aufbewahrung“ wird ein Job nicht mehr nur als Zeitplan, sondern als tatsächliche Richtlinie definiert: Bleibt diese Einstellung unverändert, behält jeder einzelne Durchlauf sein eigenes Archiv für immer bei, wodurch der Zielspeicher mit jeder einzelnen Sicherung nach und nach gefüllt wird.
„Keep Last“, „Keep Daily“, „Keep Weekly“, „Keep Monthly“ und „Keep Yearly“ ergänzen sich gegenseitig, anstatt sich gegenseitig zu überschreiben – dasselbe mehrschichtige Aufbewahrungsmuster, das die meisten Backup-Tools verwenden, sobald eine Richtlinie länger als eine Handvoll der letzten Durchläufe bestehen bleiben muss. Der Hinweis unter den Feldern sollte aufmerksam gelesen werden: Wenn hier alle Felder leer gelassen werden, bedeutet dies nicht eine unbegrenzte Aufbewahrungsdauer, sondern dass Proxmox auf die Einstellungen des Speichers selbst oder des Knotens zurückgreift. vzdump.conf bereits definiert ist, was auf einem Knoten, der noch von niemandem optimiert wurde, möglicherweise weit weniger als erwartet speichert.
Durch Klicken auf „Erstellen“ werden beide Registerkarten als ein Auftrag übermittelt, und die Liste, die zunächst leer war, zeigt nun genau das an, was konfiguriert wurde:
„Next Run“ ist ein tatsächlicher Wert, der anhand des Zeitplans in dem Moment berechnet wird, in dem der Auftrag gespeichert wird, und nicht durch einen Platzhalter ersetzt wird. Mit dem „Schedule Simulator“ in derselben Symbolleiste lassen sich komplexere Kalenderausdrücke auf dieselbe Weise anhand zukünftiger Termine überprüfen, bevor man sich endgültig darauf festlegt.
Führen Sie eine Datensicherung durch und lesen Sie das Protokoll
Es ist selten sinnvoll, bis 02:30 Uhr zu warten, um einen brandneuen Job tatsächlich zu testen. Daher löst die Schaltfläche „Jetzt ausführen“ in derselben Symbolleiste den identischen Job unmittelbar nach einem Bestätigungsdialog aus. Das Ergebnis lohnt es sich, mindestens einmal vollständig durchzulesen, da jede weitere Sicherung, die dieser Job jemals ausführt, genau derselben Abfolge folgt:
Startet Proxmox die VM tatsächlich nur, um sie zu sichern?
Nein. starting kvm to execute backup task und stopping kvm after backup task Stattdessen sollte ein kurzlebiger Hilfsprozess eingesetzt werden: eine QEMU-Instanz, die die Festplatte von web02 einbindet und über QMP streamt, völlig unabhängig vom eigentlichen Bootvorgang von Debian darin. Das ist auch der Grund, warum das Protokoll Folgendes meldet: backup mode: stop Obwohl im Dialogfeld der Modus „Snapshot“ ausgewählt war, war web02 zum Zeitpunkt der Ausführung des Auftrags bereits angehalten, sodass gar kein laufender Gast für einen Snapshot vorhanden war, und Proxmox greift automatisch auf den einfacheren Weg zurück, anstatt den Auftrag als fehlgeschlagen zu werten.
Die prozentualen Balken in der Mitte zeigen jeweils die tatsächlichen Durchsatzwerte an – eine echte Fortschrittsanzeige und keine festgelegte Animation: Der Wert stieg zu Beginn von 556,7 MiB/s an und sank gegen Ende auf 4,4 MiB/s, als das Lesemuster weniger sequenziell wurde. backup is sparse: 14.94 GiB (93%) total zero data Das ist die Zeile, die die größte Einzelzahl in diesem gesamten Protokoll erklärt: Von einer Festplatte mit einer Nennkapazität von 16,0 GiB enthielten nur 7 % Daten, die Proxmox tatsächlich kopieren musste.
Überprüfen Sie das Archiv und seine tatsächliche Größe
Auf der Registerkarte „Backup“ jeder einzelnen VM wird der tatsächliche Verlauf der Archivdateien dieser VM angezeigt, unabhängig davon, durch welchen Auftrag oder welchen Speicher die einzelnen Dateien erstellt wurden.
Diese 563,53 MB ergeben sich aus der Überlagerung der Sparse-Erkennung aus dem Aufgabenprotokoll und der ZSTD-Komprimierung: Die 93 %, die bereits aus Null-Daten bestanden, verursachten fast keine Speicherkosten, und der verbleibende Teil wurde noch weit über seine Rohgröße hinaus komprimiert. Eine derart leere Festplatte ist der beste Fall, den eine neue VM bieten kann, und die Zahl steigt von hier aus nur noch an, da sich „web02“ im Zuge einer tatsächlichen Bereitstellung füllt – genau deshalb sind die Aufbewahrungslimits aus dem vorherigen Abschnitt bereits lange bevor dieses Wachstum zum Problem wird von Bedeutung.
Eine Sicherung nach Bedarf durchführen
Die Option „Jetzt sichern“ auf derselben Registerkarte „VM-Sicherung“ greift auf denselben „vzdump“-Mechanismus zurück wie der geplante Auftrag, nur dass dabei nicht auf einen Zeitplan gewartet wird und nicht jeder Gast berücksichtigt wird, den ein Auftrag andernfalls abdecken würde.
Aus diesem Feld „Notizen“ stammt eigentlich das „web02“, das im Archiv im vorherigen Abschnitt bereits zu sehen war: {{guestname}} ist eine Live-Vorlagenvariable, die zum Zeitpunkt der Sicherung mit dem Namen dieser VM ausgefüllt wird, und der Hinweistext unterhalb des Feldes listet die anderen verfügbaren Optionen für eine detailliertere Notiz auf. Die Option „Geschützt“, die hier deaktiviert ist, sollte man kennen, noch bevor man sie jemals benötigt: Wenn man sie aktiviert, wird dieses eine Archiv von allen Aufbewahrungsregeln und von der Funktion „Entfernen“ selbst ausgenommen – die einzige Einstellung, die den Unterschied zwischen einer versehentlichen Löschung und einer Sicherung ausmacht, die ein Team tatsächlich zum Überleben braucht.
Aus einer Sicherung wiederherstellen
Wählt man in derselben Liste ein Archiv aus und klickt auf „Wiederherstellen“, öffnet sich ein Dialogfeld, dessen Titel das Risiko bereits deutlich macht:
Bevor Sie bei einer bestehenden VM-ID auf „Wiederherstellen“ klicken: Vergewissern Sie sich, dass die aktuelle Festplatte der VM keine Daten enthält, die es wert sind, erhalten zu bleiben. Der Titel des Dialogfelds lautet aus genau diesem Grund „Überschreiben und Wiederherstellen“, und es gibt keinen separaten Bestätigungsschritt nach diesem einen Bildschirm.
Die Wiederherstellung auf eine andere, ungenutzte VM-ID umgeht dieses Risiko hingegen vollständig – dies ist nützlich, um zu testen, ob ein Archiv tatsächlich funktioniert, ohne die Live-VM zu beeinträchtigen, aus der es stammt. „Unique“ generiert in diesem Fall die Netzwerk-MAC-Adresse auf dieselbe Weise neu, wie es bereits vor zwei Anleitungen beim Klonen einer Vorlage der Fall war, da zwei VMs, die sich auf derselben Bridge eine MAC-Adresse teilen, in dem Moment kollidieren würden, in dem beide hochfahren. Die Option „Einstellungen überschreiben“ füllt die Felder „Name“, „Arbeitsspeicher“, „Kerne“ und „Sockel“ direkt aus der gespeicherten Konfiguration des Backups vor; diese Werte können hier bearbeitet werden, bevor die Wiederherstellung sie übernimmt – der letzte Kontrollpunkt, bevor der erste echte Disaster-Recovery-Pfad dieser Plattform tatsächlich existiert.
Zusammenfassend lässt sich sagen
- Ein geplanter Sicherungsauftrag vereint die Auswahl der Gäste, den Speicherort, den Zeitplan und die Aufbewahrungsdauer in einem Objekt auf Rechenzentrumsebene.
- Ein echtes Backup läuft über einen kurzlebigen Hilfsprozess, niemals über das Gastbetriebssystem selbst.
- Durch die Kombination aus Erkennung spärlich besetzter Blöcke und Komprimierung lässt sich eine Festplatte mit einer Nennkapazität von 16 GiB auf wenige hundert Megabyte schrumpfen.
- Das Wiederherstellen unter Verwendung einer bestehenden VM-ID überschreibt diese; eine andere ID in Kombination mit „Unique“ ermöglicht stattdessen eine sichere Prüfung des Archivs.
Im nächsten Leitfaden werden Sie zusätzlich zu den bereits laufenden Prozessen Überwachungs- und Benachrichtigungsfunktionen einrichten.