libvirt - qcow2 Backup-Strategie | rsync / blockcommit

[badphoenix]

Danke für die zahlreichen Antworten, ich hab den Datenträger in der VM jetzt mit zerofill bereinigt.
Leider ergibt sich dadurch kein Unterschied, das Filesystem selbst kann es nicht mehr sein, da ich mittlerweile nur noch im gleichen Ordner in ein neues File kopiere (rsync --sparse oder cp --sparse=always).

Mit qemu-img convert -O qcow2 image.qcow2_backup image.qcow2 wird das File gleich noch mal kleiner, da "fehlen" dann sogar 6 GB (die md5sum unterscheidet sich vom Original).

Ich versteh es nicht ganz, ich möcht die VMs grundsätzlich gern auf einen neuen Server umziehen und hab einfach Angst vor einem Datenverlust.

[slu]

Ich bin über diesen Blogeintrag [1] auf virt-sparsify aus libguestfs-tools aufmerksam geworden, funktioniert ausgezeichnet.
Achtung die VM muss dazu heruntergefahren sein.

[1] https://kofler.info/kvm-images-platzspa ... d-sichern/

[abi]

hi,

im letzten Jahr hat sich bei libvirt/qemu einiges unter der Haube getan. Unter anderem bringt Qemu jetzt support für ein neues feature, sogenannte "dirty bitmaps" mit. Umgangssprachlich nennt man das auch "changed block tracking". Das erlaubt neben verbesserter live migration unter anderem auch richtige backups anzufertigen, im laufenden Betrieb,ohne Snapshots. Bullseye hat bereits eine libvirt/qemu version dabei die das unterstützt.

Ein Projekt von mir das diese Features nutzt und somit richtige Backups von laufenden maschinen unterstützt:

https://github.com/abbbi/virtnbdbackup

[slu]

Ein Projekt von mir das diese Features nutzt und somit richtige Backups von laufenden maschinen unterstützt:
https://github.com/abbbi/virtnbdbackup

Das ist ja ein tolles Projekt, vielen Dank für den Link und die ganze Arbeit.

Wie machst Du das mit dem RAM wenn so eine VM läuft oder erledigt das inzwischen libvirt/qemu?
Seither fahre ich die VM immer herunter, wäre schön wenn man darauf irgendwan mal verzichten könnte...

Edit:
Ich hatte mich an diesem Artikel [1] orientiert und "virsh backup-begin" wird erst ab libvirt 7.2.0 unterstüzt.
Leider ist in Bullseye aber noch libvirt 7.0.0 vorhanden.

Wenn ich das richtig verstehe machst Du das aber anders?

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

[abi]

Ich hatte mich an diesem Artikel [1] orientiert und "virsh backup-begin" wird erst ab libvirt 7.2.0 unterstüzt.
Leider ist in Bullseye aber noch libvirt 7.0.0 vorhanden.

Wenn ich das richtig verstehe machst Du das aber anders?

libvirt/qemu in bullseye bringt alles mit was man braucht:

Code: Alles auswählen

# virsh 
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # b
backup-begin 

[slu]

Code: Alles auswählen

<domainbackup>
  <disks>
    <disk name='hda' backup='yes'/>
      <target file='/tmp/testvdb.backup'/>
  </disks>
</domainbackup>

Ich wollte das mal testen, aber irgendwie geht das bei mir nicht.

Code: Alles auswählen

virsh backup-begin Win10ProTest backup_push_full.xml
error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domainbackup.rng
Extra element disks in interleave
Element domainbackup failed to validate content

Siehst Du was ihn stört?

[abi]

Siehst Du was ihn stört?

vmtl ein fehlendes

Code: Alles auswählen

</disk>

das xml sollte wohl wie folgt ausshehen:

Code: Alles auswählen

  <disks>
    <disk name='hda' backup='yes'>
      <target file='/tmp/testvdb.backup'/>
     </disk>
  </disks>
  

[slu]

vmtl ein fehlendes

Code: Alles auswählen

</disk>

Ok das hat tatsächlich Sinn gemacht und ist mir nicht aufgefallen, jetzt sieht es so aus:

Code: Alles auswählen

<domainbackup>
        <disks>
                <disk name='hda' backup='yes'>
                        <target file='/tmp/testvdb.backup'/>
                </disk>
        </disks>
</domainbackup>

virsh backup-begin Win10ProTest backup_setting.xml
error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domainbackup.rng
Extra element disks in interleave
Element domainbackup failed to validate content

Irgendwie sehe ich den Fehler nicht

[mig]

Probier mal ist jetzt ein snippet aus https://www.mail-archive.com/libvirt-us ... 12658.html
Nur so als Formatvorlage

Code: Alles auswählen

<domainbackup>
  <disks>
    <disk name='hda' type='file'>
      <target file='/path/scratch1.img'/>
      <driver type='raw'/>
    </disk>
    <disk name='hdc' type='file'>
      <target file='/path/scratch2.img'/>
      <driver type='raw'/>
    </disk>
  </disks>
</domainbackup>

LG
Michael

[slu]

So mein .xml "funktioniert" jetzt:

Code: Alles auswählen

<domainbackup mode='push'>
        <disks>
                <disk name='hda' backupmode='full' backup='yes' type='file'>
                        <target file='/tmp/testvdb.backup'/>
                        <driver type='qcow2'/>
                </disk>
        </disks>
</domainbackup>

Und ich lande gleich im nächsten Problem:

Code: Alles auswählen

virsh backup-begin Win10ProTest backup_setting.xml 
error: Operation not supported: incremental backup is not supported yet

Wenn ich das hier [1] richtig verstehe müsste ich das 'incremental-backup' feature aktivieren (obwohl ich ein full Backup möchte).
Das aber wiederrum wird als experimental [2] und damit NOT for production use deklariert.

[1] https://listman.redhat.com/archives/lib ... 00032.html
[2] https://listman.redhat.com/archives/lib ... 00034.html

@ abi,
wie machst Du das in deinem Programm für Bullseye?

[mig]

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]

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...

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?

[mig]

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]

@ 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

[mig]

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]

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.