libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
slu
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

libvirt - qcow2 Backup-Strategie | rsync / blockcommit

Beitrag von slu » 10.05.2019 14:05:40

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 :wink:

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

TomL

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

Beitrag von TomL » 10.05.2019 14:34:43

slu hat geschrieben: ↑ zum Beitrag ↑
10.05.2019 14:05:40
Wie macht ihr das?
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.

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

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

Beitrag von slu » 10.05.2019 18:08:57

TomL hat geschrieben: ↑ zum Beitrag ↑
10.05.2019 14:34:43
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...
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.
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

Benutzeravatar
bluestar
Beiträge: 2334
Registriert: 26.10.2004 11:16:34
Wohnort: Rhein-Main-Gebiet

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

Beitrag von bluestar » 11.05.2019 13:10:51

slu hat geschrieben: ↑ zum Beitrag ↑
10.05.2019 14:05:40
Wie macht ihr das?
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.

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 » 13.05.2019 13:57:08

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

badphoenix
Beiträge: 10
Registriert: 16.06.2005 20:23:39

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

Beitrag von badphoenix » 08.07.2019 21:32:07

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.

Code: Alles auswählen

rsync -avP --sparse

Die Größe Vergleiche ich mit

Code: Alles auswählen

du -sh
oder

Code: Alles auswählen

qemu-img info
Hat jemand eine Idee, woran das liegen kann?

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 » 18.07.2019 15:04:18

Hallo

lies mal den Link aus meinen Vorposting: https://gergap.wordpress.com/2013/08/1 ... rse-files/

Dort ist alles erklärt

LG Michael

jonb
Beiträge: 3
Registriert: 19.07.2019 09:09:49

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

Beitrag von jonb » 19.07.2019 09:28:30

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.

badphoenix
Beiträge: 10
Registriert: 16.06.2005 20:23:39

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

Beitrag von badphoenix » 25.07.2019 12:41:16

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 :(

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 » 25.07.2019 15:58:47

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

badphoenix
Beiträge: 10
Registriert: 16.06.2005 20:23:39

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

Beitrag von badphoenix » 25.07.2019 17:56:33

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.

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 » 25.07.2019 18:20:34

Hallo

Die einzig mögliche Antwort ist
Zitat man rsync
-S, --sparse turn sequences of nulls into sparse blocks
dh dein Quellfile hat schon mehrer blöcke nulls, zb Dateien die du in deiner VM angelegt hast und wieder gelöscht hast.
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

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

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

Beitrag von weshalb » 27.07.2019 11:55:43

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

Benutzeravatar
ThorstenS
Beiträge: 2875
Registriert: 24.04.2004 15:33:31

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

Beitrag von ThorstenS » 27.07.2019 21:35:05

OffTopic: vor einem qemu-img Aufruf oder clonezilla-Backuplauf lasse ich Debianzerofree 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.

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 » 29.07.2019 09:07:08

Hallo
Wenn die md5-Summen übereinstimmen, dann muß es an dem Dateisystem liegen. Punkt.
Naja slu hat wahrscheinlich nie die Quelldisk bereinigt.
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

badphoenix
Beiträge: 10
Registriert: 16.06.2005 20:23:39

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

Beitrag von badphoenix » 30.07.2019 10:38:08

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

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

Beitrag von slu » 25.06.2021 17:30:47

Ich bin über diesen Blogeintrag [1] auf virt-sparsify aus Debianlibguestfs-tools aufmerksam geworden, funktioniert ausgezeichnet.
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

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 » 04.11.2021 22:28:39

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

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

Beitrag von slu » 06.11.2021 13:12:46

abi hat geschrieben: ↑ zum Beitrag ↑
04.11.2021 22:28:39
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
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 » 06.11.2021 20:16:37

slu hat geschrieben: ↑ zum Beitrag ↑
06.11.2021 13:12:46
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
Beiträge: 2136
Registriert: 23.02.2005 23:58:47

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

Beitrag von slu » 08.11.2021 17:52:00

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?
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 » 08.11.2021 18:46:53

slu hat geschrieben: ↑ zum Beitrag ↑
08.11.2021 17:52:00


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

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

Beitrag von slu » 12.11.2021 14:53:49

abi hat geschrieben: ↑ zum Beitrag ↑
08.11.2021 18:46:53
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 :facepalm:
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 » 15.11.2021 12:27:46

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

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

Beitrag von slu » 16.11.2021 16:00:04

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

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

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

Antworten