libvirt - qcow2 Backup-Strategie | rsync / blockcommit
libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Wir haben einige VM's (Debian 9) auf einem Debian 9 VM-Host laufen.
Um ein komplettes Backup durchzuführen wurden die Maschinen heruntergefahren und die qcow2 Datei mit cp komplett kopiert.
Das geht bei den kleinen VM's mit ein paar GB ganz gut, aber die größeren mit 400 GB dauern dann doch einfach zu lange.
Soweit ich das sehe gibt es zwei Möglichkeiten:
1) virsh snapshot-create-as
2) shutdown und mit rsync nur die Änderungen kopieren
Beim ersten Fall könnte die VM weiter laufen, nach dem Backup muss aber unbedingt die diff.qcow2 mit der eigentlichen disk.qcow2 zusammengeführt werden.
Das erscheint mir Fehleranfällig, sollte zu diesem Zeitpunkt der VM-Host aus irgend einem Grund neu gestartet werden wird der Vorgang abgebrochen.
Oder liege ich da falsch und der snapshot-create-as läuft weiter?
Der zweite Fall wäre mir eigentlich lieber, die VM herunterfahren und mit rsync sichern. Es gibt die Optionen --sparse und --inplace welche das Kopieren beschleunigen sollten (am VM Guest ändern sich nur ca. 1GB am Tag). Blöde ist halt das dann die VM offline ist, so ein Online Backup wäre da irgendwie besser
Wie macht ihr das?
Hat evtl. schon jemand mit beiden Möglichkeiten Erfahrungen?
Um ein komplettes Backup durchzuführen wurden die Maschinen heruntergefahren und die qcow2 Datei mit cp komplett kopiert.
Das geht bei den kleinen VM's mit ein paar GB ganz gut, aber die größeren mit 400 GB dauern dann doch einfach zu lange.
Soweit ich das sehe gibt es zwei Möglichkeiten:
1) virsh snapshot-create-as
2) shutdown und mit rsync nur die Änderungen kopieren
Beim ersten Fall könnte die VM weiter laufen, nach dem Backup muss aber unbedingt die diff.qcow2 mit der eigentlichen disk.qcow2 zusammengeführt werden.
Das erscheint mir Fehleranfällig, sollte zu diesem Zeitpunkt der VM-Host aus irgend einem Grund neu gestartet werden wird der Vorgang abgebrochen.
Oder liege ich da falsch und der snapshot-create-as läuft weiter?
Der zweite Fall wäre mir eigentlich lieber, die VM herunterfahren und mit rsync sichern. Es gibt die Optionen --sparse und --inplace welche das Kopieren beschleunigen sollten (am VM Guest ändern sich nur ca. 1GB am Tag). Blöde ist halt das dann die VM offline ist, so ein Online Backup wäre da irgendwie besser
Wie macht ihr das?
Hat evtl. schon jemand mit beiden Möglichkeiten Erfahrungen?
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
Ich sichere nur die Konfigurationsdaten der Services und natürlich die Nutzerdaten. Alles andere ist m.M.n. mit dem Installer und "apt install" völlig problemlos wiederherzustellen... deswegen halte ich es nicht für sinnvoll, sowas zu sichern. Die Konfigurationsdaten eines Servers (egal ob VM oder reale Maschine) beanspruchen hier immer weniger als 1 MB, die Nutzerdaten werden täglich auf eine 2. Platte gesynct, was hier ebenfalls in ein paar Sekunden bis Minuten abgewickelt ist.
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Klar, die Nutzerdaten und auch /etc werden mit rsync ohnehin gesichert, aber im Worst Case soll die VM schnell wieder laufen und mit den Nutzerdaten befüllt werden.TomL hat geschrieben:10.05.2019 14:34:43Ich sichere nur die Konfigurationsdaten der Services und natürlich die Nutzerdaten. Alles andere ist m.M.n. mit dem Installer und "apt install" völlig problemlos wiederherzustellen...
Wir haben einige System die Software aus nicht apt Quellen haben...
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
Wir setzen nicht auf qcow2 Images, sondern auf zfs mit zvolumes und nutzen die ZFS Snapshot Funktion. Innerhalb der VM starten wir vor dem Snapshot fsfreeze.
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Hi
Nur als Info (hat mich ein paar Versuche gekostet)
Bei rsync kann man --inplace und --sparse nicht gleichzeitig verwenden, außer dieses Verhalten hat sich in letzten 2 Jahren geändert.
siehe auch https://gergap.wordpress.com/2013/08/10 ... rse-files/
Und wenn Du --inplace verwendest wird am Ziel aus einer sparse Datei eine "non sparse" Datei.
Ich verzichte daher auf sparse Files (da ich sowieso genügen Festplattenplatz habe)
Mein Script ist soetwas https://gist.github.com/migae21/f94f8f3 ... b5c51ce151 weiterentwickelt von https://gist.github.com/cabal95/e36c06e716d3328b512b
LG
Michael
Nur als Info (hat mich ein paar Versuche gekostet)
Bei rsync kann man --inplace und --sparse nicht gleichzeitig verwenden, außer dieses Verhalten hat sich in letzten 2 Jahren geändert.
siehe auch https://gergap.wordpress.com/2013/08/10 ... rse-files/
Und wenn Du --inplace verwendest wird am Ziel aus einer sparse Datei eine "non sparse" Datei.
Ich verzichte daher auf sparse Files (da ich sowieso genügen Festplattenplatz habe)
Mein Script ist soetwas https://gist.github.com/migae21/f94f8f3 ... b5c51ce151 weiterentwickelt von https://gist.github.com/cabal95/e36c06e716d3328b512b
LG
Michael
-
- Beiträge: 10
- Registriert: 16.06.2005 20:23:39
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Ich hab dazu eine Frage, wenn ich ein qcow2 File z.B.: mit rsync, wie folgt sichere, dann ist das File am Zielsystem deutlich kleiner als das original File.
Die Größe Vergleiche ich mit oder
Hat jemand eine Idee, woran das liegen kann?
Code: Alles auswählen
rsync -avP --sparse
Die Größe Vergleiche ich mit
Code: Alles auswählen
du -sh
Code: Alles auswählen
qemu-img info
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Hallo
lies mal den Link aus meinen Vorposting: https://gergap.wordpress.com/2013/08/1 ... rse-files/
Dort ist alles erklärt
LG Michael
lies mal den Link aus meinen Vorposting: https://gergap.wordpress.com/2013/08/1 ... rse-files/
Dort ist alles erklärt
LG Michael
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Ich kombiniere meine Backups mit Borgbackup, dadurch kann man mehrere Generationen von VM Images sichern, ohne viel mehr Platz zu verbrauchen. Es wird, dank Deduplication, immer nur die Differenz hinzugefügt.
-
- Beiträge: 10
- Registriert: 16.06.2005 20:23:39
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Danke für den Link.
Ds original qcow2 ist ein Sparse File mit 30 GB und zu 28 GB befüllt.
Wenn ich es nun mit rsync (auf einen anderen Server) oder cp (lokal) kopiere, dann ist das neue File nur mehr zu 26 GB befüllt Quelle Sparse - Ziele Sparse) und das versteh ich nicht ganz
Ds original qcow2 ist ein Sparse File mit 30 GB und zu 28 GB befüllt.
Wenn ich es nun mit rsync (auf einen anderen Server) oder cp (lokal) kopiere, dann ist das neue File nur mehr zu 26 GB befüllt Quelle Sparse - Ziele Sparse) und das versteh ich nicht ganz
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Hallo
Quelle und Ziel hat das gleiche Dateisystem? (also etx4, zfs, ...whatever)
ev eine md5sum von Quelle und Ziel machen?
Wenn die gleich ist, das Dateisystem auch gleich, dann bin ich auch gleich überfragt
LG
Michael
Quelle und Ziel hat das gleiche Dateisystem? (also etx4, zfs, ...whatever)
ev eine md5sum von Quelle und Ziel machen?
Wenn die gleich ist, das Dateisystem auch gleich, dann bin ich auch gleich überfragt
LG
Michael
-
- Beiträge: 10
- Registriert: 16.06.2005 20:23:39
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Ja, das Filesystem ist identisch (ext4) und lokal ist es sogar am gleichen Datenträger.
Die md5sum stimmt überein, aber es fehlten einige GB im Ziel.
Die md5sum stimmt überein, aber es fehlten einige GB im Ziel.
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Hallo
Die einzig mögliche Antwort ist
Zitat man rsync
Bin aber jetzt auch nicht der LowLevel Dateisystemexperte.
dann bewertet dies rsync halt neu und die Zieldatei ist kleiner
Wenn die checksum passt würde ich mir hier keine Sorgen machen
Lg
Michael
Die einzig mögliche Antwort ist
Zitat man rsync
dh dein Quellfile hat schon mehrer blöcke nulls, zb Dateien die du in deiner VM angelegt hast und wieder gelöscht hast.-S, --sparse turn sequences of nulls into sparse blocks
Bin aber jetzt auch nicht der LowLevel Dateisystemexperte.
dann bewertet dies rsync halt neu und die Zieldatei ist kleiner
Wenn die checksum passt würde ich mir hier keine Sorgen machen
Lg
Michael
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Ich mache immer wieder aus, dass die VM Datei mit der Zeit zu groß wird. Ich habe da mal einen Workaround in meinem Wiki, der ganz gut klappt.
Im Laufe der Zeit können die * .qcow2-Plattendateien eines Gastes größer werden als die tatsächlich darin gespeicherten Daten. Dies geschieht, weil das Gastbetriebssystem normalerweise nur eine gelöschte Datei als Null markiert, sie wird jedoch nicht wirklich gelöscht (Leistungsgründe), also der Grund Die qcow2-Datei kann nicht zwischen zugewiesenem und verwendetem und zugeordnetem, aber nicht verwendetem Speicher unterscheiden.
In der Linuxmaschine selbst:
fstrim -av
Auf dem Host, wo kvm läuft
mv image.qcow2 image.qcow2_backup
qemu-img convert -O qcow2 image.qcow2_backup image.qcow2
oder gepackt (VM läuft langsamer)
qemu-img convert -O qcow2 -c image.qcow2_backup image.qcow2
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
OffTopic: vor einem qemu-img Aufruf oder clonezilla-Backuplauf lasse ich zerofree laufen, das bringt auch einiges, wenn in der Maschine einige GBs bewegt wurden.
OnTopic:
Wenn die md5-Summen übereinstimmen, dann muß es an dem Dateisystem liegen. Punkt.
Vergleich mal den jeweiligen output von dumpe2fs /dev/$PARTITON.
OnTopic:
Wenn die md5-Summen übereinstimmen, dann muß es an dem Dateisystem liegen. Punkt.
Vergleich mal den jeweiligen output von dumpe2fs /dev/$PARTITON.
Re: libvirt - qcow2 Backup-Strategie | rsync / blockcommit
Hallo
Also kanns IMHO auch daran liegen.
Aber thx für zerofree hatte ich schon früher verwendet, ist mir echt entfallen
Müßt mal testen ob zerofree oder rsync --sparse einen Unterschied machen.
Aber grundsätzlich würde ich ja da qemu-img convert bevorzogen, in der Annahme das qemu schon weiß wie es eine virtuelle Disk organisiert.
(qemu-img würde ich immer nur auf eine Kopie des Originalfiles loslassen, wie von weshalb beschrieben)
LG
Michael
Naja slu hat wahrscheinlich nie die Quelldisk bereinigt.Wenn die md5-Summen übereinstimmen, dann muß es an dem Dateisystem liegen. Punkt.
Also kanns IMHO auch daran liegen.
Aber thx für zerofree hatte ich schon früher verwendet, ist mir echt entfallen
Müßt mal testen ob zerofree oder rsync --sparse einen Unterschied machen.
Aber grundsätzlich würde ich ja da qemu-img convert bevorzogen, in der Annahme das qemu schon weiß wie es eine virtuelle Disk organisiert.
(qemu-img würde ich immer nur auf eine Kopie des Originalfiles loslassen, wie von weshalb beschrieben)
LG
Michael
-
- 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