libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Benutzeravatar
mig
Beiträge: 151
Registriert: 26.02.2003 13:21:58
Wohnort: wien
Kontaktdaten:

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von mig » 16.11.2021 17:38:45

Hallo

So schaut mein xml von der VM aus

Code: Alles auswählen

<domain type='kvm' id='3' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <qemu:capabilities>
    <qemu:add capability='incremental-backup'/>
  </qemu:capabilities>
Ohne freischalten des incremental-backup gabs kein full-backup :-)

Sonstige Nebenwirkungen konnte ich bei noch nicht feststellen.
Habs mal auf 3 von meinen VMs getestet (alles qcow images)

@abi Danke für dein Programm dies hab ich auch schon getestet und funktioniert gut, solang man halt apparmor für die session deaktiviert
Ein Frage die slu auch schon gestellt hat, ist der state der VM (also auch RAM):
Bei qcow images wird doch der state mitgespeichert oder liege ich hier falsch?
Bei RAW imagaes gibt es dann keine Sicherung des RAMs der VMs?

LG
Michael

slu
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 16.11.2021 19:49:27

mig hat geschrieben: ↑ zum Beitrag ↑
16.11.2021 17:38:45

Code: Alles auswählen

<domain type='kvm' id='3' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <qemu:capabilities>
    <qemu:add capability='incremental-backup'/>
  </qemu:capabilities>
Ohne freischalten des incremental-backup gabs kein full-backup :-)
Genau so ist es, jetzt funktioniert es, sehr schön.

Interessant ist aber das ein http://libvirt.org/schemas/domain/qemu/1.0 404 zurück gibt.
Ich war immer der Annahme das dieses xml Schema dann geladen werden müsste...
mig hat geschrieben: ↑ zum Beitrag ↑
16.11.2021 17:38:45
Bei qcow images wird doch der state mitgespeichert oder liege ich hier falsch?
So weit hatte ich noch gar nicht gedacht, das heißt aber der RAM der VM liegt immer
im qcow2, wäre das nicht von der Performance schwierig?
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

Benutzeravatar
mig
Beiträge: 151
Registriert: 26.02.2003 13:21:58
Wohnort: wien
Kontaktdaten:

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von mig » 17.11.2021 08:06:44

Hallo Slu

Nur wenn du einen Snapshots machst.
Und das neue Backup Feature macht ja auch nichts anderes, also so im Prinzip.
Aber ist halt "gefährliches Halbwissen"

https://serverfault.com/questions/10694 ... by-libvirt

Lg Michael

slu
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 17.11.2021 12:53:16

@ Michael,

danke für den Link.

Hab heute mit meinem Win10 Test noch etwas weiter gespielt:
1) VM gestartet
2) Backup erstellt
3) VM heruntergefahren
4) virsh edit -> storage auf backup file
5) VM gestartet

Ich hätte jetzt erwartet das die VM direkt wieder eingeschaltet da steht, passiert aber nicht,
das Windows startet neu.

Mit anderen Worten, ist mein Backup wirklich gut?

Das Thema ist noch viel spannender als ich mir das gedacht habe :wink:
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

Benutzeravatar
mig
Beiträge: 151
Registriert: 26.02.2003 13:21:58
Wohnort: wien
Kontaktdaten:

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von mig » 17.11.2021 21:12:28

Hallo Slu

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

Darum läuft immer noch mein cronjob der mittels eins bash scriptes Snapshots macht diese auf mein NAS kopiert und wieder commitet.
bzw nur die disks kopiert wenn die Vm abgeschaltets ist.
Hier kam ich immer in eine laufende Maschine bei meinen restore Tests, so sie beim Backup lief.

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

Lg
Michael

slu
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 18.11.2021 10:07:09

Hallo Michael,
mig hat geschrieben: ↑ zum Beitrag ↑
17.11.2021 21:12:28
Lustig daran ist, dass dieses neue Backup Feature nur bei laufender VM geht.
ja das hatte ich auch schon bemerkt :)
mig hat geschrieben: ↑ zum Beitrag ↑
17.11.2021 21:12:28
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.
mig hat geschrieben: ↑ zum Beitrag ↑
17.11.2021 21:12:28
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.
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

ralfi
Beiträge: 285
Registriert: 02.06.2011 11:16:11
Wohnort: Brandenburg

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von ralfi » 18.11.2021 17:05:05

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.
Viele Grüße, ralfi

Niveau sieht von unten oft wie Arroganz aus ...

slu
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 18.11.2021 18:01:34

ralfi hat geschrieben: ↑ zum Beitrag ↑
18.11.2021 17:05:05
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.
ralfi hat geschrieben: ↑ zum Beitrag ↑
18.11.2021 17:05:05
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
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

Benutzeravatar
mig
Beiträge: 151
Registriert: 26.02.2003 13:21:58
Wohnort: wien
Kontaktdaten:

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von mig » 19.11.2021 07:18:10

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
Beiträge: 285
Registriert: 02.06.2011 11:16:11
Wohnort: Brandenburg

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von ralfi » 19.11.2021 10:57:28

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.
Viele Grüße, ralfi

Niveau sieht von unten oft wie Arroganz aus ...

slu
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 19.11.2021 13:59:26

ralfi hat geschrieben: ↑ zum Beitrag ↑
19.11.2021 10:57:28
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...
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

ralfi
Beiträge: 285
Registriert: 02.06.2011 11:16:11
Wohnort: Brandenburg

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von ralfi » 24.11.2021 08:40:05

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.
Viele Grüße, ralfi

Niveau sieht von unten oft wie Arroganz aus ...

Benutzeravatar
weshalb
Beiträge: 1265
Registriert: 16.05.2012 14:19:49

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von weshalb » 26.11.2021 19:41:48

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

slu
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 29.12.2021 14:00:04

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.
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von reox » 29.12.2021 14:09:28

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
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 29.12.2021 14:48:32

reox hat geschrieben: ↑ zum Beitrag ↑
29.12.2021 14:09:28
Sagt doch die Man page ;)
Das stimmt, vielleicht denke ich zu kompliziert.
reox hat geschrieben: ↑ zum Beitrag ↑
29.12.2021 14:09:28

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 :wink:
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von reox » 29.12.2021 15:54:29

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 Debianqemu-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
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 29.12.2021 16:09:28

reox hat geschrieben: ↑ zum Beitrag ↑
29.12.2021 15:54:29
Ich habe bei mir eine etwas andere Lösung gewählt und verwende --quiesce in kombination mit Debianqemu-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 :wink:
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

slu
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 29.12.2021 16:11:14

reox hat geschrieben: ↑ zum Beitrag ↑
29.12.2021 15:54:29
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?
reox hat geschrieben: ↑ zum Beitrag ↑
29.12.2021 15:54:29
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.
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von reox » 30.12.2021 07:55:21

slu hat geschrieben: ↑ zum Beitrag ↑
29.12.2021 16:09:28
reox hat geschrieben: ↑ zum Beitrag ↑
29.12.2021 15:54:29
Ich habe bei mir eine etwas andere Lösung gewählt und verwende --quiesce in kombination mit Debianqemu-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 :wink:
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 :D
slu hat geschrieben: ↑ zum Beitrag ↑
29.12.2021 16:11:14
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
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 30.12.2021 11:45:45

reox hat geschrieben: ↑ zum Beitrag ↑
30.12.2021 07:55:21
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 :D
slu hat geschrieben: ↑ zum Beitrag ↑
29.12.2021 14:00:04
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!
reox hat geschrieben: ↑ zum Beitrag ↑
30.12.2021 07:55:21
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.

reox hat geschrieben: ↑ zum Beitrag ↑
30.12.2021 07:55:21
Ü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.
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von reox » 30.12.2021 12:26:16

slu hat geschrieben: ↑ zum Beitrag ↑
30.12.2021 11:45:45
virsh restore mem.qcow2
:facepalm: 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
slu hat geschrieben: ↑ zum Beitrag ↑
30.12.2021 11:45:45
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
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 30.12.2021 13:10:03

reox hat geschrieben: ↑ zum Beitrag ↑
30.12.2021 12:26:16
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!
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

slu
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 11.01.2024 11:17:36

Ich beschäftige mich wieder etwas mit dem Thema.

@abi sehr schön das Du Debianvirtnbdbackup 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
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

Benutzeravatar
abi
Beiträge: 2215
Registriert: 20.12.2001 19:42:56
Wohnort: München
Kontaktdaten:

Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von abi » 11.01.2024 11:20:47

slu hat geschrieben: ↑ zum Beitrag ↑
11.01.2024 11:17:36

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.

Antworten