Was die vzdump-Modi von Proxmox garantieren

Proxmox bietet drei Backup-Modi in einem einzigen Auswahlfeld an, und dadurch sehen sie aus wie drei Geschwindigkeiten derselben Sache. Das sind sie nicht. Sie unterscheiden sich darin, was mit dem laufenden Gast geschieht, und damit darin, wovon das Archiv überhaupt eine Kopie ist.

Erst die kurze Fassung, dann die lange:

Das Wort, das in dieser Tabelle die ganze Arbeit macht, ist crash-consistent. Es bedeutet: Das Archiv ist das, wonach die Festplatte ausgesehen hätte, wenn in genau diesem Augenblick jemand das Stromkabel gezogen hätte. Ein Journaling-Dateisystem kommt davon zurück. Eine Datenbank mit einer Transaktion in der Schwebe möglicherweise nicht, und eine Anwendung, die ihren Zustand über zwei Dateien verteilt, weiß nicht, dass eine davon älter ist als die andere.

Snapshot bedeutet nicht stillgelegt

snapshot ist die Voreinstellung und der einzige Modus, der nichts unterbricht. Proxmox legt einen Snapshot auf Speicherebene an und liest das Backup daraus, der Gast schreibt also die ganze Zeit weiter auf das laufende Volume.

Es gibt einen Weg, dieses Archiv besser zu machen: Der QEMU-Gast-Agent kann das Dateisystem im Gast für den Augenblick der Snapshot-Erstellung einfrieren. Das schreibt ausstehende Daten weg und liefert ein Archiv, das der Gast selbst für sauber hält. Ist der Gast-Agent installiert, läuft er und antwortet er, dann geschieht genau das.

Die Falle steckt in diesem „wenn“. Nichts im Ergebnis der API sagt Ihnen, ob das Einfrieren stattgefunden hat. Der vzdump-Task liefert eine Task-ID und am Ende einen Status. Ob qemu-guest-agent auf die Freeze-Anfrage geantwortet hat, ist eine Zeile im Task-Log und kein Feld, das Sie zurücklesen können.

Für jeden, der darauf automatisiert, ist das ein Entscheidungspunkt, und er verdient eine bewusste Wahl. Als wir den Backup-Weg für unsere Proxmox-Integration gebaut haben, sind wir dabei gelandet, Konsistenz als das aufzuzeichnen, was geschehen ist, nie als das, was verlangt wurde: Ein stop-Backup wird als konsistent verbucht, snapshot und suspend beide als crash-consistent, Punkt. Es gibt in unserem Schema einen Wert für „der Gast wurde stillgelegt“, und der Agent gibt ihn nie aus, denn ihn auszugeben hieße, Wissen über ein Einfrieren zu behaupten, das wir über die API nicht prüfen können.

Ein Archiv, das etwas schlechter beschrieben ist, als es ist, kostet Sie nichts. Ein Archiv, das besser beschrieben ist, als es ist, kostet Sie die eine Wiederherstellung, auf die es ankommt.

Suspend hält den Gast an und ist kein Mittelweg

suspend liest sich besser, als es sich verhält. Man nimmt an, es sei „Snapshot, aber sicherer“, ein Kompromiss zwischen keiner und voller Ausfallzeit. Tatsächlich hält es den Gast an, während die Daten gelesen werden.

Es gibt Ihnen dieselbe Zusage zur Crash-Konsistenz wie snapshot, denn eine Maschine anzuhalten ist nicht dasselbe, wie sie ausschreiben und zur Ruhe kommen zu lassen. Sie bekommen eine Unterbrechung und kein stärkeres Versprechen. Der Anwendungsfall ist schmal: ein Speicher-Backend, das überhaupt keine Snapshots kann, wo der Modus snapshot nichts hat, wovon er einen Snapshot nehmen könnte.

Stop ist die einzige ehrliche Zusage

stop fährt den Gast herunter, sichert ihn und startet ihn wieder. Es ist die längste Unterbrechung und der einzige Modus, in dem das Archiv unzweideutig die Kopie eines Dateisystems ist, auf das niemand geschrieben hat.

Für einen Datenbankserver, den jemand um drei Uhr nachts unter Druck wiederherstellen wird, ist das kein hoher Preis. Für eine Flotte von Webservern ist es ein Preis, den niemand jede Nacht zahlen will. Beides sind richtige Antworten auf verschiedene Fragen, und deshalb gehört der Modus in die Richtlinie und nicht in eine einzige globale Einstellung.

Ein Detail der Umsetzung zählt hier. Weil stop und suspend beide eine laufende Maschine unterbrechen, darf ein fehlender oder unbekannter Moduswert niemals auf einen von beiden durchfallen. In unserem Befehlsschema reist der Modus als das wörtliche Proxmox-Wort (snapshot, suspend, stop) und nicht als eigenes Vokabular, und ein nicht gesetzter Wert wird zu snapshot aufgelöst. Eine Übersetzungstabelle zwischen unseren Wörtern und ihren würde eine Fehlübersetzung genau dorthin legen, wo eine Fehlübersetzung die Maschine eines Kunden herunterfährt.

Die Parameter, die über den Start des Auftrags entscheiden

Vor der Konsistenz steht eine langweiligere Frage: Startet vzdump überhaupt. Vier Dinge an der Anfrage entscheiden das, und drei davon scheitern auf schwer lesbare Weise.

Der Zielspeicher muss Backups annehmen. Proxmox-Speicher hat eine content-Liste, und nur ein Speicher, dessen Liste backup enthält, kann ein vzdump aufnehmen. Das ist kein Hinweis. Schicken Sie den Auftrag an einen Speicher, der nur Disk-Images hält, lehnt Proxmox ihn mit einer Meldung wie storage 'x' does not support vzdump backups ab. Zutreffend, und bedeutungslos für den Kunden, der auf die Schaltfläche geklickt hat. Es lohnt sich, das vor dem Absenden zu prüfen, damit die Absage stattdessen „dieser Speicher nimmt keine Backups an“ sagen kann.

Ein verwandter Fall: Ein Speicher, der in der Ressourcenliste des Clusters mit dem Status unknown auftaucht, ist konfiguriert, antwortet aber nicht. Eine ausgefallene NFS-Freigabe sieht genau wie ein gültiges Ziel aus, bis der Auftrag scheitert.

Für „keine Kompression“ steht nicht das Wort, das Sie erwarten.

Proxmox schreibt „keine Kompression“ als 0 und nicht als none. none zu senden ist die Art Fehler, die eine stille Absage erzeugt statt einer klaren, und deshalb prüft unsere Testsuite die genaue Zeichenkette, die den Agenten verlässt, statt nur zu prüfen, dass der Aufruf geglückt ist.

Die Mail-Benachrichtigung ist voreingestellt laut, und an die falsche Person. Ohne ein ausdrückliches mailnotification=failure mailt Proxmox nach jedem Backup an root@pam. Auf einer Maschine, die von einer Plattform aus verwaltet wird, ist das Post an den Anbieter über etwas, das der Kunde getan hat.

Zwei optionale Felder sollten Sie kennen. notes-template hängt eine Notiz an das Archiv, und Proxmox setzt darin seine eigenen Platzhalter wie {{guestname}} ein. protected=1 markiert ein Archiv als geschützt, und Proxmox weigert sich dann, es wegzuräumen. Das ist der Mechanismus für die Kopie, die jemand vor einer riskanten Änderung zieht, und genau die falsche Voreinstellung für einen nächtlichen Auftrag.

Aufbewahrung ist kein vzdump-Parameter

An der Backup-Anfrage gibt es keine Einstellung zur Aufbewahrung. Das Wegräumen wird am Speicher konfiguriert, in Proxmox, und der Eigentümer des Speichers entscheidet, wie lange Kopien leben.

Das hat eine Entwurfsfolge für jeden, der darauf aufbaut: Ein Panel mit einem Feld „7 Kopien behalten“ greift entweder in die Speicherkonfiguration hinein oder löscht Archive selbst. Wir haben uns für keines von beidem entschieden und sagen das, statt mit einem Feld, das nichts tut, etwas anderes anzudeuten.

Eine Zeitüberschreitung ist kein Fehlschlag

Ein vzdump einer großen Maschine kann jede vernünftige Zeitgrenze einer Anfrage überleben. Wenn das geschieht, ist das Entscheidende: Es wurde nichts abgebrochen. Der Auftrag läuft auf dem Hypervisor weiter und wird nach seinem eigenen Zeitplan fertig oder scheitert.

Eine Zeitüberschreitung ist also eine Aussage über Ihre Verbindung, nicht über das Backup. Der Lauf bleibt offen, die Task-ID gilt weiter, und das Ehrliche für eine Oberfläche ist, „läuft noch“ zu sagen und später abzugleichen. Die Alternative, ihn als gescheitert zu markieren und jemanden einen zweiten starten zu lassen, setzt zwei vzdump-Aufträge auf denselben Speicher für dieselbe Maschine.

Während er läuft, ist der echte Fortschritt verfügbar: vzdump schreibt Zeilen wie 12% (1.2 GiB of 10.0 GiB) in sein Task-Log. Ein Fortschrittsbalken, der daraus gespeist wird, ist ehrlich. Ein Fortschrittsbalken aus einer Schätzung ist eine Vermutung mit einem Prozentzeichen dahinter.

Wiederherstellen ist eine andere Frage, und unique zählt

Die Frage nach dem Modus endet, sobald das Archiv da ist. Das Wiederherstellen hat seine eigene Falle, und es ist eine des Netzwerks.

Stellen Sie ein Archiv in eine neue VM wieder her, ohne neue Kennungen anzufordern, dann erbt die neue Maschine die MAC-Adressen des Originals. Läuft das Original noch, haben Sie jetzt zwei Maschinen mit derselben MAC an derselben Bridge, und das Symptom ist nicht „die Wiederherstellung ist gescheitert“, sondern „mit dem Netzwerk der Produktionsmaschine stimmt etwas nicht“. Das Flag unique am Wiederherstellungsaufruf verhindert das, und auf einer Plattform, die neben einem laufenden Original wiederherstellt, ist es keine Option, sondern eine Voraussetzung.

Zwei weitere Dinge lohnen sich vor der ersten Wiederherstellung:

• storage bedeutet hier etwas anderes. Beim Backup ist es der Ort, an den das Archiv geht, und es braucht backup in seiner Content-Liste. Beim Wiederherstellen ist es der Ort, an dem die Disks landen, und es braucht images. Gleicher Feldname, andere Anforderung.
• Nur die Disks kommen zurück. Eine wiederhergestellte Maschine ist eine Maschine mit den Disks und der Hardware aus dem Archiv. Adresszuweisungen, Firewallregeln und alles an Automatisierung, was am Original hing, leben in Ihren eigenen Systemen und nicht in der vzdump-Datei, und sie reisen nicht mit.

Was hier nicht gemessen ist

Alles oben über die Form der Aufrufe stammt aus dem API-Schema von Proxmox und aus dem Bauen dagegen; die Bedeutung der Modi stammt von Proxmox selbst und steht so in dessen Dokumentation.

Was wir bewusst nicht angeben, ist, wie viel Zeit jeder Modus kostet. Wir haben keine gemessene Pausendauer für suspend und keine gemessene Ausfallzeit für stop: Das hängt vom Gast, vom Speicher und von der Menge veränderter Speicherseiten ab, und eine auf einer Maschine gemessene Zahl würde als allgemeine zitiert. Die müssen von Ihrer eigenen Hardware kommen.

Zwei weitere Lücken gehören benannt. Alles hier betrifft QEMU-Gäste; Container-Backups haben ihre eigenen Regeln rund um Mountpoints und Bind-Mounts, und wir haben sie nicht gemessen. Und es gibt in all dem keinen inkrementellen Weg: vzdump auf einen einfachen Speicher schreibt jedes Mal ein volles Archiv. Für inkrementelles Backup ist der Proxmox Backup Server da, und das ist eine andere Software mit anderen Zusagen.

Das entstand beim Bauen des Proxmox-Backup-Wegs für Provibr, ein Server-Management-Panel für Hosting-Anbieter, wo ein Backup, das besser beschrieben ist, als es ist, der schlimmstmögliche Fehler wäre. Die Einrichtungsnotizen für die Hypervisor-Seite stehen in der Proxmox-Dokumentation, und die Seite zur Proxmox-Integration beschreibt, was der Agent kann.