libvirt - qcow2 Backup-Strategie | rsync / blockcommit

[slu]

Hallo Michael,

Lustig daran ist, dass dieses neue Backup Feature nur bei laufender VM geht.

ja das hatte ich auch schon bemerkt

Hier kam ich immer in eine laufende Maschine bei meinen restore Tests, so sie beim Backup lief.

Das ist spannend, hast Du die mit virsh start DOMAIN gestartet?
Ich habe mich schon gefragt ob ich das evtl. anders machen muss.

Zu restore Test mit den neuen Backup Feature bin ich jetzt noch nicht gekommen, steht aber als nächstes an.

Wäre super wenn wir diesen Thread hier weiter führen könnten sobald Du da was probiert hast.

[ralfi]

Moin,
ich mach das schon seit Jahren mit zwei Bash-Skripten, welche vor und nach der eigentlichen Sicherung mit BAREOS ausgeführt werden.

virsh snapshot-create-as --domain <Domain-Name> overlay --disk-only --atomic --no-metada
erzeugt im laufenden Betrieb den Schnapschuss

virsh blockcommit <Domain-Name> hda --active --verbose --pivot
schreibt die Änderungen (hier auf hda, bekommt man aus dem Def-File der Domain oder über virsh domblklist raus) dann wieder Zustand zurück.

Funktioniert ohne Probleme.

[slu]

virsh snapshot-create-as --domain <Domain-Name> overlay --disk-only --atomic --no-metada
erzeugt im laufenden Betrieb den Schnapschuss

Das wäre nach aktueller Doku [1] der alte Weg.

virsh blockcommit <Domain-Name> hda --active --verbose --pivot
schreibt die Änderungen (hier auf hda, bekommt man aus dem Def-File der Domain oder über virsh domblklist raus) dann wieder Zustand zurück.

Funktioniert ohne Probleme.

Auch hier die Frage, was passiert mit dem RAM?

Wenn Du so ein Backup startest, ist die VM sofort hochgefahren oder kommt es einem starten gleich?


[1] https://libvirt.org/kbase/live_full_disk_backup.html

[mig]

moin moin

Ich mach es genau so wie ralfi

https://nopaste.debianforum.de/41533

Alle meinen VMs haben einen guest agent, und qcow2 Platten

Ich hab bei allen meinen Restoretests immer den RAM dabeigehabt.

Lg
Michael

Edit: doppelpost gelöscht und nopaste link

[ralfi]

Moin,

also ich weiss nicht genau ob wir uns da richtig verstehen, denn ich benutze den "--disk-only" Parameter weil für mich die konsistenten HDD Images wichtiger sind als die anderen System-Zustände.

Die VM wird nicht in einen Suspend Mode gefahren wo der RAM mit gesichert wird, also RAM ist wech aber HDD ist konsistent da falls was passiert. Das man bis zum Exzess treiben und bspw alle Stunde ein Image in ein BAREOS Volume schreiben welches ständig immer überschrieben wird oder wie auch immer. Ist für mich der günstigste Kompromiss gegenüber richtig teuren ausfallsicheren Clusterfilesystemen.

[slu]

Die VM wird nicht in einen Suspend Mode gefahren wo der RAM mit gesichert wird, also RAM ist wech aber HDD ist konsistent da falls was passiert.

Das ist halt der Punkt wo ich mir unsicher bin wie das technisch funktioniert wenn z.B. gerade ein größerer INSERT in der DB gelaufen ist...

Unabhängig von der VM sichern wir auch die Nutzdaten, man könnte also sehr schnell die DB einfach dropen und neu einspielen ohne das man den ganzen
Server neu installieren muss...

[ralfi]

Sorry für die später Antwort.

Eine Inkonsistenz bei dieser Art und Weise der Schnapsschuss Sicherung ist mir noch nie passiert. Ich benutze dieses Verfahren zur täglichen Sicherung seit gefühlt meiner Geburt ohne das jemals eine Inkonsistenz aufgretreten wäre. Ich musste allerdings auch fast nie auf die Datensicherung zurückgreifen...

Allerdings geschehen DB Zugriffe des Nachts unter Last natürlich selten. Ich würde es einfach mal mit einer Test-VM probieren und in einer Schleife ständig auf die DB zugreifen und dann einen Schnappschuss machen, mal schauen was passiert. Dann ist es halt eine Abwägungsfrage. Der wirklich große Vorteil ist, dass die VM während des gesamten Vorganges jederzeit verfügbar ist und nicht in den Paused-Zustand versetzt wird.

[weshalb]

Sicherheitshalber würde ich einen Dump der DB über die üblichen Möglichkeiten extra machen. Wird ja dann ebenfalls mit gesichert.

[slu]

Endlich hab ich mal richtig Zeit gefunden mich damit nochmal zu beschäftigen und tatsächlich gibt es eine Möglichkeit den Speicher mit zu sichern (war mit seither nicht klar).

Dieser Thread ist sehr interessant:
https://www.mail-archive.com/libvirt-us ... 12677.html

Damit ergeben sich folgende Schritte:

Code: Alles auswählen

virsh snapshot-create-as --domain vmtest backuptest --diskspec hda,file=/mnt/test/overlay.qcow2,snapshot=external --memspec file=/mnt/test/mem.qcow2,snapshot=external --atomic --live --no-metadata
# jetzt kann man die orginale Disk und das Mem Image sichern
virsh blockcommit vmtest hda --active --verbose --pivot
# zur Sicherheit kontrollieren
virsh domblklist vmtest

Jetzt kommt der spannende Teil die VM kann nun wie folgt wieder hergestellt werden:
1) Shutdown der VM
2) kopieren der .qcow2 Disk an die ursprüngliche Stelle
3) virsh restore mem.qcow2

Sobald das abgeschlossen ist steht die VM wieder laufend da.

Was mir noch nicht klar ist, für was die Option "--live" genau ist.

[reox]

Sagt doch die Man page

Code: Alles auswählen

If --live is specified, libvirt takes the snapshot while the guest is running. 
This increases the size of the memory image of the external checkpoint. 
This is currently supported only for external checkpoints. 

[slu]

Sagt doch die Man page

Das stimmt, vielleicht denke ich zu kompliziert.

Code: Alles auswählen

If --live is specified, libvirt takes the snapshot while the guest is running. 
This increases the size of the memory image of the external checkpoint. 
[...]

Mich hat das "increases the size of the memory image" verwirrt, vermutlich ist damit gemeint
das sonst nur der Status gespeichert wird?
Ist aber auch egal "live" sagt ja schon wähend dem laufen

[reox]

ohne es 100% zu wissen, denke ich das damit das image des RAM gemeint ist - wenn man es denn auch angibt.
Ich habe bei mir eine etwas andere Lösung gewählt und verwende --quiesce in kombination mit qemu-guest-agent - dadurch kann man aber auch den State nicht speichern.

Was mich noch nervt ist, dass blockcommit unter buster zwar die Option --delete in der manpage stehen hat, aber diese nicht implementiert ist.
Ist eigentlich die einzige Lösung wie man herausfinden kann ob der snapshot noch aktiv ist über virsh domblklist?

[slu]

Ich habe bei mir eine etwas andere Lösung gewählt und verwende --quiesce in kombination mit qemu-guest-agent - dadurch kann man aber auch den State nicht speichern.

Ja das wird in dem Mailinglist Thread auch erwähnt und als ziemlich/fast sicher beschrieben, wenn der RAM aber zusätzlich mit kommt kann das nicht schaden.
Leider geht --quiesce in der Kombination mit --memspec nicht, ein Kompromiss muss man halt eingehen

[slu]

Was mich noch nervt ist, dass blockcommit unter buster zwar die Option --delete in der manpage stehen hat, aber diese nicht implementiert ist.

Falls Du das extern weg kopierst --no-metadata?

Ist eigentlich die einzige Lösung wie man herausfinden kann ob der snapshot noch aktiv ist über virsh domblklist?

Mir ist kein anderer Weg bekannt.

[reox]

Ich habe bei mir eine etwas andere Lösung gewählt und verwende --quiesce in kombination mit qemu-guest-agent - dadurch kann man aber auch den State nicht speichern.

Ja das wird in dem Mailinglist Thread auch erwähnt und als ziemlich/fast sicher beschrieben, wenn der RAM aber zusätzlich mit kommt kann das nicht schaden.
Leider geht --quiesce in der Kombination mit --memspec nicht, ein Kompromiss muss man halt eingehen

Was mir noch nicht ganz klar ist: Wenn ich das RAM image habe, wie kann ich dann im Backup Fall die Maschine wieder starten? Den richtigen virsh befehl hab ich da noch nicht gefunden

Mir ist kein anderer Weg bekannt.

Hmm.. ich wollte in mein Backup script einen verlässlichen Check einbauen, ob das Snapshot Image gelöscht werden kann. Wenn es nämlich noch da ist, verweigert virsh snapshot-create-as den Dienst - aber es könnte ja sein, dass der Blockcommit nicht funktioniert hat und dann lösche ich das Image wohlmöglich einfach weg. Rein von der Ausgabe von domblkinfo kann man nicht immer 100% sicher sein, dass das Image nicht in betrieb ist. zB könnte ja ein weiterer snapshot dran hängen. Allerdings schreibt qemu-img info mir immer die gesamte Kette raus, auch wenn der blockcommit durchgeführt wurde. Und auf das original image kann ich mit qemu-img nicht zugreifen, solange die VM rennt...
Vllt ist aber auch genau das ein guter Test:

Code: Alles auswählen

# virsh snapshot-create-as --domain testvm --name backup-snapshot.qcow2 --no-metadata --atomic --quiesce --disk-only --diskspec vda,snapshot=external
Domain snapshot backup-snapshot.qcow2 created
# qemu-img info /vmimages/testvm.backup-snapshot.qcow2
qemu-img: Could not open '/vmimages/testvm.backup-snapshot.qcow2': Failed to get shared "write" lock
Is another process using the image [/vmimages/testvm.backup-snapshot.qcow2]?
# qemu-img info /vmimages/testvm.img
image: /vmimages/testvm.img
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 1.9G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
# virsh domblklist testvm
 Target   Source
--------------------------------------------------
 vda      /vmimages/testvm.backup-snapshot.qcow2
# virsh blockcommit testvm vda --active --pivot --wait --verbose --delete  # --delete wird unter Buster noch nicht unterstützt...
error: unsupported flags (0x2) in function qemuDomainBlockCommit
# virsh blockcommit testvm vda --active --pivot --wait --verbose
Block commit: [100 %]
Successfully pivoted
# qemu-img info /vmimages/testvm.img
qemu-img: Could not open '/vmimages/testvm.img': Failed to get shared "write" lock
Is another process using the image [/vmimages/testvm.img]?
# qemu-img info /vmimages/testvm.backup-snapshot.qcow2
image: /vmimages/testvm.backup-snapshot.qcow2
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 2.3M
cluster_size: 65536
backing file: /vmimages/testvm.img
backing file format: qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
# qemu-img info --backing-chain /vmimages/testvm.backup-snapshot.qcow2  # Leider kann man die Backing-Chain im Betrieb auch nicht ausgeben lassen, weil dazu alle images angeschaut werden...
qemu-img: Could not open '/vmimages/testvm.img': Failed to get shared "write" lock
Is another process using the image [/vmimages/testvm.img]?
    

Solange der snapshot aktiv ist, kann man keine info auslesen.

Übrigens, das was auf der ML steht funktioniert bei mir nach dem blockcommit nicht:

Code: Alles auswählen

# virsh snapshot-delete testvm backup-snapshot.qcow2
error: Domain snapshot not found: no domain snapshot with matching name 'backup-snapshot.qcow2'

[slu]

Was mir noch nicht ganz klar ist: Wenn ich das RAM image habe, wie kann ich dann im Backup Fall die Maschine wieder starten? Den richtigen virsh befehl hab ich da noch nicht gefunden

1) Shutdown der VM
2) kopieren der .qcow2 Disk an die ursprüngliche Stelle
3) virsh restore mem.qcow2

Sobald Du "virsh restore mem_image.qcow2" machst steht die Maschine wieder so da wie zum Zeitpunkt "virsh snapshot-create-as".
Wichtig, vorher die VM ausschalten und die disk.qcow2 durch das Backup ersetzen, sonst passt Disk Image nicht zum Mem Image!

Hmm.. ich wollte in mein Backup script einen verlässlichen Check einbauen, ob das Snapshot Image gelöscht werden kann.

Bin gerade am Scripten und prüfe einfach ob der Overlay noch aktiv ist:

Code: Alles auswählen

OVERLAY_FILE="${VMBACKUPLOCATION}/${VMGUEST}_OVERLAY_${TIMESTAMP}.qcow2"
VMGUESTSTORAGE=`virsh domblklist ${VMGUEST} --details | awk '/mnt/{print $4}'`
VMGUESTSTORAGETYPE=`virsh domblklist ${VMGUEST} --details | awk '/mnt/{print $3}'`
[...]        
               virsh blockcommit ${VMGUEST} ${VMGUESTSTORAGETYPE} --active --verbose --pivot
                if [ "${VMGUESTSTORAGE}" == "`virsh domblklist ${VMGUEST} --details | awk '/mnt/{print $4}'`" ]; then
                        echo "overlay disabled, remove overlay file.."
                        rm -v "${OVERLAY_FILE}"
                else
                        echo "WARNING blockcommit failed, overlay active!"
                        exit 1
                fi

Natürlich muss $VMGUESTSTORAGE vor dem Snapshot ermittelt werden.

Ist noch nicht ganz fertig, baue es gerade auf. Im Fehlerfall soll das Script immer abbrechen.

Übrigens, das was auf der ML steht funktioniert bei mir nach dem blockcommit nicht:

Code: Alles auswählen

# virsh snapshot-delete testvm backup-snapshot.qcow2
error: Domain snapshot not found: no domain snapshot with matching name 'backup-snapshot.qcow2'

--no-metadata
Dann wird nichts angelegt wenn ich deine Frage richtig verstehe.

[reox]

virsh restore mem.qcow2

ups, ja lesen hilft Danke!

Ich denke du solltest auch noch ein --wait beim blockcommit einbauen weil

Code: Alles auswählen

By default, this command returns as soon as possible, and data for the entire disk is committed in the background

Dann wird nichts angelegt wenn ich deine Frage richtig verstehe.

Achso ja ich versteh schon. Weil ich --no-metadata verwende weiß libvirt nicht um den snapshot. Alles klar. Ich hatte --no-metadata mehr oder weniger als "failsafe" damit ich nicht aus versehen den snapshot zurücksetze, was ich beim backup ja nie wollen würde.
Somit bleibt wohl nur zu warten bis blockcommit --delete korrekt funktioniert...

[slu]

Ich denke du solltest auch noch ein --wait beim blockcommit einbauen weil

Code: Alles auswählen

By default, this command returns as soon as possible, and data for the entire disk is committed in the background

Sehr guter Hinweis, danke!

[slu]

Ich beschäftige mich wieder etwas mit dem Thema.

@abi sehr schön das Du virtnbdbackup in Debian gebracht hast, vielen Dank für deine Arbeit!

Ich habe mir dein Video [1] angeschaut, warum wird da /dev/nbd4 verwendet, wie kommt es zu der 4?

Eine Frage die noch offen ist, was passiert mit dem RAM wenn die VM gesichert wird?

[1] https://youtu.be/dOE0iB-CEGM

[abi]

Ich habe mir dein Video [1] angeschaut, warum wird da /dev/nbd4 verwendet, wie kommt es zu der 4?

ich hatte bei aufnahme des Videos schon ein paar nbd Geräte aktiv und musste auf ein Gerät
ausweichen das noch frei war.

Eine Frage die noch offen ist, was passiert mit dem RAM wenn die VM gesichert wird?

das RAM wird in dieser Sicherungsvariante nicht mitgesichert.

[slu]

ich hatte bei aufnahme des Videos schon ein paar nbd Geräte aktiv und musste auf ein Gerät
ausweichen das noch frei war.

Ok das dachte ich mir, dann ist der Punkt verstanden, danke.

das RAM wird in dieser Sicherungsvariante nicht mitgesichert.

Das ist tatsächlich noch so ein Punkt an dem ich hänge, laufen ich damit nicht Gefahr das noch was im RAM steht (Datenbank,..) das noch nicht (vollständig) geschrieben wurde?

Was passiert zum Beispiel wenn ein Client eine 10GB Datei kopiert und dann das Backup (bei 5GB) los läuft?
(ist normal nicht der Fall weil man es ja in die Nacht oder was auch immer legen kann).

Die Backups mit virtnbdbackup machen es möglich eine VM nach einem Totalverlust (Storage,...) wieder auf einer neuen Hardware (virsh define vm.xml / virsh edit vm [path,..]) mit dem
Stand Zeit X weiterlaufen zu lassen/starten, richtig?

Edit: Formatierung korrigiert

[abi]

Das ist tatsächlich noch so ein Punkt an dem ich hänge, laufen ich damit nicht Gefahr das noch was im RAM steht (Datenbank,..) das noch nicht (vollständig) geschrieben wurde?

Was passiert zum Beispiel wenn ein Client eine 10GB Datei kopiert und dann das Backup (bei 5GB) los läuft?
(ist normal nicht der Fall weil man es ja in die Nacht oder was auch immer legen kann).

Es geht darum ein konsistentes *online* Backup der Dateisysteme der virtuellen Maschine zu erstellen ohne einen Agenten verwenden zu müssen (sprich: einen backup agenten in der VM der erst mühsam das Dateisystem nach geänderten Daten scannen muss)

Bei einem Online backup muss man auf Applikationsebene sicherstellen dass eben alles Passt.

Im Gegensatz dazu gibt es ein OFFLINE backup:

1) man fährt eine VM runter, macht ein backup: 100% konsistent, vom Dateisystem hin bis zur Applikationsebene.
2) man hält eine VM in ihrer Operation an: Semi-konsistent: Wenn die VM z.B. mit "virsh save" gesichert wird, muss ebenfalls sichergestellt werden dass wärend dieser "save" und ein Freeze des Kompletten VM rams durchgeführt wird, dies zu einem Zeitpunkt geschieht wo eben entsprechende Dienste in der VM in einem Konsistenten Zustand sind.

Beide Varianten haben das Problem dass die VM zum Zeitraum der sicherung nicht aktiv genutzt werden kann! Das ist aber in Umgebungen wo ich 100% Erreichbarkeit meiner Dienste sicherstellen muss nicht Praktikabel.

Bei einem Online backup hat man die möglichkeit die entsprechenden Dienste der VM über den Qemu Agent in einen Konsistenten Zustand zu versetzen:

1) backup startet, es wird ein Checkpoint angelegt und währendessen über den qemu guest Agent ein Dateisystem freeze (und entsprechender sync um die Daten im cache auf die Disk zu schreiben) für diesen Kurzen Moment durchgeführt: Der checkpoint enhält dann zummindest ein konsistentes Dateisystem und die Sicherung kann beginnen. Das anlegen des Checkpoints dauert in der regel nur den Bruchteil einer Sekunde.
2) Wenn ich weitere dienste wie eine Datenbank habe deren Konsistenz ich sicherstellen will muss ich eben den Qemu Guest Agent über scripte so erweiterten dass er bei der Freeze Operation eben auch verhindert dass meine Datenbank in einem Inkonsistenten Zustand ist, hier muss ich dann auch die Applikationen die ich sichere beim Freeze mit berücksichtigen und diese für den kurzen Moment stillegen.

virtnbdbackup versucht genau dies: wenn beim Backup ein checkpoint angelegt wird, wird vesucht über den qemu guest agent zummindest die Dateisysteme für diesen kurzen Moment anzuhalten. Inwieweit du das Treiben willst, musst du selbst entscheiden in dem du die Qemu Guest Agent scripts entsprechend erweiterst, dass neben dem default freeze auch applikationen gestoppt und kurz danach wieder gestartet werden.

Die gleiche Problematik habe ich aber auch wenn ich über die alte Sicherungsvariante mit Blockcommit und Snapshots "sichere" (oder bei einem normalen Dateisystem backup mit rsync): wer sagt dir dass zum Zeitpunkt des Snapshots alles Konsistent war? Auch hier muss über den Qemu Guest Agent dann sichergstellt werden dass bei anlegen des Snapshots die Applikation entsprechend kosnistent ist. Nur habe ich bei der alten blockcommit variante nicht die möglichkeit incrementiell oder differentiell zu sicheren und mein SIcherungszeitfenster reicht bei grossen VM's uu nicht aus.

Die Backups mit virtnbdbackup machen es möglich eine VM nach einem Totalverlust (Storage,...) wieder auf einer neuen Hardware (virsh define vm.xml / virsh edit vm [path,..]) mit dem
Stand Zeit X weiterlaufen zu lassen/starten, richtig?

Das ist es absolut. Die VM wird aber einen normalen boot durchführen und nicht wie mit "virsh save" ab einen gewissen Zeitpunkt weiterlaufen.
Das will man auch gegebenenfalls nicht, denn wenn was wenn die entsprechende Operation die zum Datenverlust geführt hat nach Restore dann sofort wieder anläuft?

Diese ganzen Thematiken sind nicht auf libvirt beschränkt, die Sicherungsmethode für Online backups auf diese weise (Changed Block Tracking mit agent der Konsistenz sicherstellt) ist quasi defakto Standard im Backup bereich, veeam und konsorten machen das bei Vmare oder Hyperv nicht anders.

[slu]

Das ist es absolut. Die VM wird aber einen normalen boot durchführen und nicht wie mit "virsh save" ab einen gewissen Zeitpunkt weiterlaufen.

Wäre ich bei dem 7 Minuten Video nicht den ganzen morgen unterbrochen worden hätte ich das schon selber beantworten können, sorry.

Das will man auch gegebenenfalls nicht, denn wenn was wenn die entsprechende Operation die zum Datenverlust geführt hat nach Restore dann sofort wieder anläuft?

Sehr guter Punkt!

Diese ganzen Thematiken sind nicht auf libvirt beschränkt, die Sicherungsmethode für Online backups auf diese weise (Changed Block Tracking mit agent der Konsistenz sicherstellt) ist quasi defakto Standard im Backup bereich, veeam und konsorten machen das bei Vmare oder Hyperv nicht anders.

Damit wäre auch beantwortet wie die anderen Hersteller das machen, irgendwie habe ich oft den Eindruck das hier die Technik gar nicht
so richtig hinterfragt wird, "einfach veeam nehmen und abhaken".

Es ist aber doch sehr wichtig zu verstehen wie ein Backup funktioniert, nichts schlimmeres als ein Backup das später nicht geht...

[slu]

@abi,
ist es geplant das virtnbdbackup in die bookworm-backports kommt?

[abi]

@abi,
ist es geplant das virtnbdbackup in die bookworm-backports kommt?

habe ich schon darüber nachgedacht, bin mir aber noch unsicher. Das Paket aus Unstable sollte aber ohne weiteres auch auf bookworm funktionieren.