Backup kompletter VM

virtualization
german

#1

Unter UCS 3.1-1 nutzen wir UVMM mit mit qemu-kvm. Die Festplatten der VMs sind im Format qcow2. Nun würde ich gerne ein Backup der VMs im laufenden Betrieb einrichten. Normalerweise sollte der Weg doch sein:

  1. Suspend der VM
  2. Snapshot erstellen
  3. Resume der VM
  4. Snapshot wegsichern
  5. Snapshot löschen

Leider haben wir dazu noch keine funktionierende Lösung gefunden. Gibt es dazu von Univention eine Empfehlung?


#2

Hallo,

der Weg sieht erstmal sinnvoll aus. Haben Sie einen konkreten Punkt, bei dem etwas nicht funktioniert?
Beim Backup sollte man dann sicher auch die Maschinen-Konfiguration als XML sichern.

Eine offizielle Empfehlung gibt es jedenfalls im Moment nicht.

Viele Grüße,
Dirk Ahrnke


#3

Hallo Herr Ahrnke,

zum einen Frage ich mich, womit der Snapshot zu erstellen ist, virsh oder qemu-img.

Beim erstellen des Snapshots stellt sich die Frage, ob dieser dateiintern erstellt werden soll, oder ob es besser ist, mit einer 2. Datei zu arbeiten.
Bei dateiintern sehe ich den Vorteil, das es einfacher ist, den Snapshot wieder zu entfernen, aber das Problem, wie komme ich an den Snapshot-Punkt, um diesen Status in eine 2. Datei zu sichern.

Beim Arbeiten mit zwei Dateien ist das Wegsichern klar, aber wie bekomme ich dann meine beiden Dateien wieder zusammen?

Bei beiden Varianten bleibt noch die Frage, was passiert, wenn ich die VM mit der einmal gesicherten virtuellen Festplatte starte. Da ja wahrscheinlich durch das Suspend nicht alle Schreiboperationen abgeschlossen sind, kann es ja wahrscheinlich zu Dateifehlern kommen.

Vielleicht hat dazu ja jemand, der auch Virtualisierung mit KVM nutzt, eine Lösung.

Vielen Dank.

Mit besten Grüßen

Thore Plagemann


#4

Hallo,

ein komplexes Thema, für das keine fertige Lösung parat ist. Nur ein paar Hinweise:

Ein mit virsh erstellter Snapshot ist komplett: Speicherinhalt, Gerätestatus, Konfiguration, Plattenabbild. Klingt am sichersten, hat aber das Problem, daß beim Wiederherstellen die Zeit mitten im laufenden System einen Sprung macht, nicht alle Kernel/Geräte/Anwendungen verkraften das. Und man kommt an das System nicht ran zwischen Restore und Start.

Andererseits, ein purer Platten-Snapshot (mit qemu-img) kann gebootet werden. Das Filesystem (journal-basiert) spielt die hängenden Transaktionen ein, der Kernel bekommt frisch wie beim Einschalten die aktuelle Zeit. Und es hat den Vorteil: man kann evtl. vor dem Booten noch Dinge verändern (z.B. mit anderem Hostnamen/IP hochfahren, virtuelle Platte in anderes System einhängen etc.). Probleme machen dann nur Anwendungen, die nicht transaktionssicher arbeiten; heutige Datenbanken (mysql, postgresql) sollten da souverän sein. Man müßte sich die auf den Servern laufenden Anwendungen anschauen, ob man denen vor dem Snapshot eine Art Flush- oder Suspend-Kommando (aktuelle Transaktionen auf Platte ablegen) geben kann/muß.

An die Snapshots von Qemu/Kvm verwalteten Plattenabbildern kommt man über den nbd-Gerätetreiber (qemu-nbd) heran: der kann ein Block-Device mit dem Stand eines Snapshots liefern, das man dann bequem wegsichern kann, egal ob gemountet oder direkt als Abbild eines Blockgerätes.

Herzliche Grüße
Frank Greif.