libvirt - qcow2 Backup-Strategie | rsync / blockcommit
-
- Beiträge: 10
- Registriert: 16.06.2005 20:23:39
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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.
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.
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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/
Achtung die VM muss dazu heruntergefahren sein.
[1] https://kofler.info/kvm-images-platzspa ... d-sichern/
Gruß
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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
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
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Das ist ja ein tolles Projekt, vielen Dank für den Link und die ganze Arbeit.abi hat geschrieben:04.11.2021 22:28:39Ein Projekt von mir das diese Features nutzt und somit richtige Backups von laufenden maschinen unterstützt:
https://github.com/abbbi/virtnbdbackup
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
Gruß
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
libvirt/qemu in bullseye bringt alles mit was man braucht:slu hat geschrieben:06.11.2021 13:12:46Ich 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?
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
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Code: Alles auswählen
<domainbackup>
<disks>
<disk name='hda' backup='yes'/>
<target file='/tmp/testvdb.backup'/>
</disks>
</domainbackup>
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
Gruß
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
vmtl ein fehlendes
Code: Alles auswählen
</disk>
Code: Alles auswählen
<disks>
<disk name='hda' backup='yes'>
<target file='/tmp/testvdb.backup'/>
</disk>
</disks>
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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>
Irgendwie sehe ich den Fehler nichtvirsh 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
Gruß
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Probier mal ist jetzt ein snippet aus https://www.mail-archive.com/libvirt-us ... 12658.html
Nur so als Formatvorlage
LG
Michael
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>
Michael
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
So mein .xml "funktioniert" jetzt:
Und ich lande gleich im nächsten Problem:
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?
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>
Code: Alles auswählen
virsh backup-begin Win10ProTest backup_setting.xml
error: Operation not supported: incremental backup is not supported yet
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?
Gruß
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Hallo
So schaut mein xml von der VM aus
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
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>
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
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Genau so ist es, jetzt funktioniert es, sehr schön.mig hat geschrieben:16.11.2021 17:38:45Ohne freischalten des incremental-backup gabs kein full-backupCode: 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>
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...
So weit hatte ich noch gar nicht gedacht, das heißt aber der RAM der VM liegt immermig hat geschrieben:16.11.2021 17:38:45Bei qcow images wird doch der state mitgespeichert oder liege ich hier falsch?
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
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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
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
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
@ 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
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
Gruß
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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
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
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Hallo Michael,
Ich habe mich schon gefragt ob ich das evtl. anders machen muss.
ja das hatte ich auch schon bemerktmig hat geschrieben:17.11.2021 21:12:28Lustig daran ist, dass dieses neue Backup Feature nur bei laufender VM geht.
Das ist spannend, hast Du die mit virsh start DOMAIN gestartet?mig hat geschrieben:17.11.2021 21:12:28Hier kam ich immer in eine laufende Maschine bei meinen restore Tests, so sie beim Backup lief.
Ich habe mich schon gefragt ob ich das evtl. anders machen muss.
Wäre super wenn wir diesen Thread hier weiter führen könnten sobald Du da was probiert hast.mig hat geschrieben:17.11.2021 21:12:28Zu restore Test mit den neuen Backup Feature bin ich jetzt noch nicht gekommen, steht aber als nächstes an.
Gruß
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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.
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 ...
Niveau sieht von unten oft wie Arroganz aus ...
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Das wäre nach aktueller Doku [1] der alte Weg.ralfi hat geschrieben:18.11.2021 17:05:05virsh snapshot-create-as --domain <Domain-Name> overlay --disk-only --atomic --no-metada
erzeugt im laufenden Betrieb den Schnapschuss
Auch hier die Frage, was passiert mit dem RAM?ralfi hat geschrieben:18.11.2021 17:05:05virsh 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.
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
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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
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
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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.
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 ...
Niveau sieht von unten oft wie Arroganz aus ...
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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...ralfi hat geschrieben:19.11.2021 10:57:28Die 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.
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
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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.
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 ...
Niveau sieht von unten oft wie Arroganz aus ...
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Sicherheitshalber würde ich einen Dump der DB über die üblichen Möglichkeiten extra machen. Wird ja dann ebenfalls mit gesichert.
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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:
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.
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
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
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
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.