libvirt - qcow2 Backup-Strategie | rsync / blockcommit

[slu]

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

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!

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.

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

[reox]

virsh restore mem.qcow2

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

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]

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!

[slu]

Ich beschäftige mich wieder etwas mit dem Thema.

@abi sehr schön das Du virtnbdbackup 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

[abi]

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.

[slu]

ich hatte bei aufnahme des Videos schon ein paar nbd Geräte aktiv und musste auf ein Gerät
ausweichen das noch frei war.

Ok das dachte ich mir, dann ist der Punkt verstanden, danke.

das RAM wird in dieser Sicherungsvariante nicht mitgesichert.

Das ist tatsächlich noch so ein Punkt an dem ich hänge, laufen ich damit nicht Gefahr das noch was im RAM steht (Datenbank,..) das noch nicht (vollständig) geschrieben wurde?

Was passiert zum Beispiel wenn ein Client eine 10GB Datei kopiert und dann das Backup (bei 5GB) los läuft?
(ist normal nicht der Fall weil man es ja in die Nacht oder was auch immer legen kann).

Die Backups mit virtnbdbackup machen es möglich eine VM nach einem Totalverlust (Storage,...) wieder auf einer neuen Hardware (virsh define vm.xml / virsh edit vm [path,..]) mit dem
Stand Zeit X weiterlaufen zu lassen/starten, richtig?

Edit: Formatierung korrigiert

[abi]

Das ist tatsächlich noch so ein Punkt an dem ich hänge, laufen ich damit nicht Gefahr das noch was im RAM steht (Datenbank,..) das noch nicht (vollständig) geschrieben wurde?

Was passiert zum Beispiel wenn ein Client eine 10GB Datei kopiert und dann das Backup (bei 5GB) los läuft?
(ist normal nicht der Fall weil man es ja in die Nacht oder was auch immer legen kann).

Es geht darum ein konsistentes *online* Backup der Dateisysteme der virtuellen Maschine zu erstellen ohne einen Agenten verwenden zu müssen (sprich: einen backup agenten in der VM der erst mühsam das Dateisystem nach geänderten Daten scannen muss)

Bei einem Online backup muss man auf Applikationsebene sicherstellen dass eben alles Passt.

Im Gegensatz dazu gibt es ein OFFLINE backup:

1) man fährt eine VM runter, macht ein backup: 100% konsistent, vom Dateisystem hin bis zur Applikationsebene.
2) man hält eine VM in ihrer Operation an: Semi-konsistent: Wenn die VM z.B. mit "virsh save" gesichert wird, muss ebenfalls sichergestellt werden dass wärend dieser "save" und ein Freeze des Kompletten VM rams durchgeführt wird, dies zu einem Zeitpunkt geschieht wo eben entsprechende Dienste in der VM in einem Konsistenten Zustand sind.

Beide Varianten haben das Problem dass die VM zum Zeitraum der sicherung nicht aktiv genutzt werden kann! Das ist aber in Umgebungen wo ich 100% Erreichbarkeit meiner Dienste sicherstellen muss nicht Praktikabel.

Bei einem Online backup hat man die möglichkeit die entsprechenden Dienste der VM über den Qemu Agent in einen Konsistenten Zustand zu versetzen:

1) backup startet, es wird ein Checkpoint angelegt und währendessen über den qemu guest Agent ein Dateisystem freeze (und entsprechender sync um die Daten im cache auf die Disk zu schreiben) für diesen Kurzen Moment durchgeführt: Der checkpoint enhält dann zummindest ein konsistentes Dateisystem und die Sicherung kann beginnen. Das anlegen des Checkpoints dauert in der regel nur den Bruchteil einer Sekunde.
2) Wenn ich weitere dienste wie eine Datenbank habe deren Konsistenz ich sicherstellen will muss ich eben den Qemu Guest Agent über scripte so erweiterten dass er bei der Freeze Operation eben auch verhindert dass meine Datenbank in einem Inkonsistenten Zustand ist, hier muss ich dann auch die Applikationen die ich sichere beim Freeze mit berücksichtigen und diese für den kurzen Moment stillegen.

virtnbdbackup versucht genau dies: wenn beim Backup ein checkpoint angelegt wird, wird vesucht über den qemu guest agent zummindest die Dateisysteme für diesen kurzen Moment anzuhalten. Inwieweit du das Treiben willst, musst du selbst entscheiden in dem du die Qemu Guest Agent scripts entsprechend erweiterst, dass neben dem default freeze auch applikationen gestoppt und kurz danach wieder gestartet werden.

Die gleiche Problematik habe ich aber auch wenn ich über die alte Sicherungsvariante mit Blockcommit und Snapshots "sichere" (oder bei einem normalen Dateisystem backup mit rsync): wer sagt dir dass zum Zeitpunkt des Snapshots alles Konsistent war? Auch hier muss über den Qemu Guest Agent dann sichergstellt werden dass bei anlegen des Snapshots die Applikation entsprechend kosnistent ist. Nur habe ich bei der alten blockcommit variante nicht die möglichkeit incrementiell oder differentiell zu sicheren und mein SIcherungszeitfenster reicht bei grossen VM's uu nicht aus.

Die Backups mit virtnbdbackup machen es möglich eine VM nach einem Totalverlust (Storage,...) wieder auf einer neuen Hardware (virsh define vm.xml / virsh edit vm [path,..]) mit dem
Stand Zeit X weiterlaufen zu lassen/starten, richtig?

Das ist es absolut. Die VM wird aber einen normalen boot durchführen und nicht wie mit "virsh save" ab einen gewissen Zeitpunkt weiterlaufen.
Das will man auch gegebenenfalls nicht, denn wenn was wenn die entsprechende Operation die zum Datenverlust geführt hat nach Restore dann sofort wieder anläuft?

Diese ganzen Thematiken sind nicht auf libvirt beschränkt, die Sicherungsmethode für Online backups auf diese weise (Changed Block Tracking mit agent der Konsistenz sicherstellt) ist quasi defakto Standard im Backup bereich, veeam und konsorten machen das bei Vmare oder Hyperv nicht anders.

[slu]

Das ist es absolut. Die VM wird aber einen normalen boot durchführen und nicht wie mit "virsh save" ab einen gewissen Zeitpunkt weiterlaufen.

Wäre ich bei dem 7 Minuten Video nicht den ganzen morgen unterbrochen worden hätte ich das schon selber beantworten können, sorry.

Das will man auch gegebenenfalls nicht, denn wenn was wenn die entsprechende Operation die zum Datenverlust geführt hat nach Restore dann sofort wieder anläuft?

Sehr guter Punkt!

Diese ganzen Thematiken sind nicht auf libvirt beschränkt, die Sicherungsmethode für Online backups auf diese weise (Changed Block Tracking mit agent der Konsistenz sicherstellt) ist quasi defakto Standard im Backup bereich, veeam und konsorten machen das bei Vmare oder Hyperv nicht anders.

Damit wäre auch beantwortet wie die anderen Hersteller das machen, irgendwie habe ich oft den Eindruck das hier die Technik gar nicht
so richtig hinterfragt wird, "einfach veeam nehmen und abhaken".

Es ist aber doch sehr wichtig zu verstehen wie ein Backup funktioniert, nichts schlimmeres als ein Backup das später nicht geht...

[slu]

@abi,
ist es geplant das virtnbdbackup in die bookworm-backports kommt?

[abi]

@abi,
ist es geplant das virtnbdbackup in die bookworm-backports kommt?

habe ich schon darüber nachgedacht, bin mir aber noch unsicher. Das Paket aus Unstable sollte aber ohne weiteres auch auf bookworm funktionieren.

[slu]

habe ich schon darüber nachgedacht, bin mir aber noch unsicher.

Die Frage ist halt was passiert wenn man noch andere Sachen aus Backports installiert wie z.B. qemu, sind das deine Bedenken?

Anderseits, wenn es sicher funktioniert dann kann man die Version aus Debian 12 ja genau in der Kombination betreiben und sicher sein das die Backups ok sind.

[abi]

habe ich schon darüber nachgedacht, bin mir aber noch unsicher.

Die Frage ist halt was passiert wenn man noch andere Sachen aus Backports installiert wie z.B. qemu, sind das deine Bedenken?

Anderseits, wenn es sicher funktioniert dann kann man die Version aus Debian 12 ja genau in der Kombination betreiben und sicher sein das die Backups ok sind.

nein, ist einfach nur eine Zeitfrage im Moment. Neuere Qemu etc sollten nicht benötigt werden. Ggf der Version in bookworm hat die Version in unstable aber doch einige neue Features und Bugfixes die einen Backport sinnvoll erscheinen lassen.

[slu]

nein, ist einfach nur eine Zeitfrage im Moment.

Kann ich nur zu gut nachvollziehen...

[...] Bugfixes die einen Backport sinnvoll erscheinen lassen.

Vor allem um die geht es mir, die könnte man aber vermutlich auch mit einem Point Release durch Stable bringen?

[slu]

@abi,

ich hab nochmal eine Frage (sorry ):
Was passiert wenn ein Backup mitten drin abbricht, ist das für meine VM gefährlich?
Was passiert beim nächsten Backup Aufruf?

Der Vorteil von virtnbdbackup ist das man genau nicht mit overlay und blockcommit arbeitet, richtig?

[abi]

@abi,

ich hab nochmal eine Frage (sorry ):
Was passiert wenn ein Backup mitten drin abbricht, ist das für meine VM gefährlich?
Was passiert beim nächsten Backup Aufruf?

Der Vorteil von virtnbdbackup ist das man genau nicht mit overlay und blockcommit arbeitet, richtig?

ein backup abbruch ist nicht gefährlich und was beim nächsten backup passiert hängt davon ab an welcher
stelle die sicherung abgebrochen ist.

Der vorteil ist dass das utility die neue backup api verwendet, nicht die alte auf overlay/blockcommit basierte und somit echtes incremental backup / differencial backup auf blockebene sowie die anfertigung von thin provisioned backups unterstützt: https://libvirt.org/kbase/live_full_disk_backup.html

[slu]

@abi,

heute konnte ich endlich virtnbdbackup testen und habe weitere Fragen:

1)
Wenn ich ein Backup gemäße dem Beispiel starte:
virtnbdbackup -d vm1 -l full -o /tmp/backupset
habe ich im Ziel unter anderem die Disk Datei:
vda.full.data

Wenn ich das richtig verstehe würde jetzt ein weiteres Backup z.B. von vm2 die Disk überschreiben und ich hätte defekte Backups?
Es ist daher zwingend erforderlich für alle VMs ein eigenes Ziel bzw. Ordner zu verwenden, richtig?

2)
[2024-02-16 15:31:36] INFO root virtnbdbackup - main [MainThread]: Local NDB Endpoint socket: [/var/tmp/virtnbdbackup.347927]
[2024-02-16 15:31:36] INFO root virtnbdbackup - main [MainThread]: Temporary scratch file target directory: [/var/tmp]

Der Endpoint schreibt keine Daten (in /var/tmp/virtnbdbackup.x) sondern dient nur zum durchreichen, oder?

3)
Kann es sein das die verify Funktion in Debian 12 nicht enthalten ist?
Anstatt einem verify wird das Backup mit diesem Befehl..
virtnbdrestore -i /tmp/backup -o verify
..in den Ordner verify geschrieben.

virtnbdbackup 1.9.15-1 all Backup utility for libvirt

[abi]

Wenn ich ein Backup gemäße dem Beispiel starte:
virtnbdbackup -d vm1 -l full -o /tmp/backupset
habe ich im Ziel unter anderem die Disk Datei:
vda.full.data

Wenn ich das richtig verstehe würde jetzt ein weiteres Backup z.B. von vm2 die Disk überschreiben und ich hätte defekte Backups?
Es ist daher zwingend erforderlich für alle VMs ein eigenes Ziel bzw. Ordner zu verwenden, richtig?

das backup in diesem verzeichnis ist dann ein VOLL-backup. Weitere SIcherungen in dieses Verzeichnis im Modus voll
oder copy sind dann NICHT möglich, wohl aber weitere sicherungen im modus INC oder DIFF: die Daten werden dann
zusätzlich gespeichert, nichts wird überschrieben. Wenn eine andere VM in dieses gleiche Verzeichnis gesichert
werden sollte wird das utility das erkennen und abbrechen.

Pro VM sicherung ist ein eigenes Zielverzeichnis zu verwenden.

Ein Zielverzeichnis ist immer als komplettes "backup set" zu sehen: man fertigt eine voll sicherung einer VM an und darauf
basierende incrementielle oder differentielle sicherungen in dieses Verzeichnis an. Will ich ein neues backup-set
anlegen verwende ich einfach ein neues, leeres verzeichnis.

Bei einem VOLL backup muss das verzeichnis rotiert werden. Inwieweit ist die README hier unklar? Wird eigentlich
alles entsprechend Beschrieben.

In kombination mit dem backup modus "auto" kann man dann z.B. wöchentlich
oder Monatlich rotierende Backup-Sets erzeugen (Sonntag eine Voll sicherung in ein leeres verzeichnis,
Montag - Samstag dann incrementielle Sicherungen, am nächsten Sonntag rotation des Verzeichnisses und somit
beginn einer neuen Sicherungskette):

https://github.com/abbbi/virtnbdbackup? ... ng-backups

2)
[2024-02-16 15:31:36] INFO root virtnbdbackup - main [MainThread]: Local NDB Endpoint socket: [/var/tmp/virtnbdbackup.347927]
[2024-02-16 15:31:36] INFO root virtnbdbackup - main [MainThread]: Temporary scratch file target directory: [/var/tmp]

Der Endpoint schreibt keine Daten (in /var/tmp/virtnbdbackup.x) sondern dient nur zum durchreichen, oder?

es handelt sich hierbei lediglich um ein temporäre socket datei um den NBD endpunkt zu erreichen.

3)
Kann es sein das die verify Funktion in Debian 12 nicht enthalten ist?

die version in debian12 hat diese funktion noch nicht.

[slu]

Bei einem VOLL backup muss das verzeichnis rotiert werden. Inwieweit ist die README hier unklar? Wird eigentlich
alles entsprechend Beschrieben.

So ist das Beispiel ausgezeichnet beschrieben, vielen Dank.
https://github.com/abbbi/virtnbdbackup/ ... be7ac790e0

In kombination mit dem backup modus "auto" kann man dann z.B. wöchentlich
oder Monatlich rotierende Backup-Sets erzeugen (Sonntag eine Voll sicherung in ein leeres verzeichnis,
Montag - Samstag dann incrementielle Sicherungen, am nächsten Sonntag rotation des Verzeichnisses und somit
beginn einer neuen Sicherungskette):

https://github.com/abbbi/virtnbdbackup? ... ng-backups

Das ist genial gelöst

3)
Kann es sein das die verify Funktion in Debian 12 nicht enthalten ist?

die version in debian12 hat diese funktion noch nicht.

Ok dann habe ich das doch richtig verstanden.
Ich konnte die aktuelle Version aus Trixie in Bookworm installieren, nur eine Python Abhängigkeit musste noch nachinstalliert werden, diese war aber in Bookworm vorhanden.

Muss mal überlegen wie ich das zukünftig mache oder ob ich bei der Bookworm Version bleibe.

[slu]

@abi, vielen Dank für Version 2

root@sandbox:/tmp# dpkg -l | grep virtnb
ii virtnbdbackup 2.0-1 all Backup utility for libvirt

root@sandbox:/tmp# cat /etc/debian_version
12.5

[slu]

Kann ich mich weiterhin an virtnbdbackup Updates aus Trixie für Bookworm bedienen?
dpkg sollte die Installation verhindern wenn Abhängigkeiten nicht vorhanden sind?

[abi]

Kann ich mich weiterhin an virtnbdbackup Updates aus Trixie für Bookworm bedienen?
dpkg sollte die Installation verhindern wenn Abhängigkeiten nicht vorhanden sind?

ja, dass sollte nachwievor passen.

[slu]

Kannst du mir sagen wie die TB Information (7.31TB) bei der kleinen VM < 100GB zustande kommt?
Was genau sagt mir die Zahl die da hoch läuft?

Code: Alles auswählen

[...]
[2024-03-18 23:14:52] Info root disk - backup [sda]: Creating thin provisioned stream backup image
saving disk sda: 7.31TB [00:42, 419GB/s]

Das fertige Backup hat gerade mal 61GB:

Code: Alles auswählen

-rw-r--r-- 1 root root  61G 18. Mär 23:16 sda.copy.data
-rw-r--r-- 1 root root   10 18. Mär 23:16 sda.copy.data.chksum
-rw-r--r-- 1 root root 1,2K 18. Mär 23:16 sda.copy.qcow.json

[abi]

Kannst du mir sagen wie die TB Information (7.31TB) bei der kleinen VM < 100GB zustande kommt?
Was genau sagt mir die Zahl die da hoch läuft?

das habe ich so noch nicht gesehen. Die Menge der zu sichernden Blöcke wird anhand der vom NBD Server
gemeldeten Extents bemessen:

https://github.com/abbbi/virtnbdbackup/ ... sk.py#L102

das Thema bitte über github als issue einlasten wenn es reproduzierbar ist, liegt entweder an der Berechnung,
der Daten vom NBD Server oder die library die die Progressbar anzeigt hat hier ein Problem. Ausserdem
benötige ich das ganze log am besten mit -v.

[slu]

Wenn ich mit virtnbdbackup Backups erstelle werden auch checkpoints angelegt, sind die in der .qcow2 gespeichert?
virsh checkpoint-list VM --tree

Mich irritiert das hier, Zitat:

Code: Alles auswählen

The record of which portions of the disk changed since the checkpoint are merged into the parent checkpoint (if any).

https://libvirt.org/manpages/virsh.html ... int-delete

Die Frage ist ob ich die VM herunterfahren und auf einen anderen KVM Host verschieben (.qcow2) kann und erneut starten ohne
das es ein Datenverlust gibt...

[abi]

Wenn ich mit virtnbdbackup Backups erstelle werden auch checkpoints angelegt, sind die in der .qcow2 gespeichert?
virsh checkpoint-list VM --tree

Mich irritiert das hier, Zitat:

Code: Alles auswählen

The record of which portions of the disk changed since the checkpoint are merged into the parent checkpoint (if any).

https://libvirt.org/manpages/virsh.html ... int-delete

Die Frage ist ob ich die VM herunterfahren und auf einen anderen KVM Host verschieben (.qcow2) kann und erneut starten ohne
das es ein Datenverlust gibt...

ja, und ja.
beim verschieben müssen aber auch die jeweiligen checkpoint informationen aus /etc/libvirt mit kopiert werden.
Ansonsten gilt das was in der README beschrieben ist:

https://github.com/abbbi/virtnbdbackup? ... ersistency