libvirt - qcow2 Backup-Strategie | rsync / blockcommit

[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

[slu]

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

Genau das ist mir nicht 100% klar, wenn ich das nicht mache scheitert nur mein Backup, aber meine VM (qcow2) ist völlig in Ordnung?
Was passiert wenn ich bei einem Problem nur die .qcow2 auf einen neuen Host lege, also die checkpoints verloren sind?

Hintergrund, wir kopieren die VMs zusätzlich mit der snapshot Funktion (virsh snapshot-create-as), ich fragen mich nun ob die Images in Ordnung sind wenn parallel (nicht gleichzeitig) ein Backup
mit virtnbdbackup durchgeführt wird und damit checkpoints erzeugt werden.

[abi]

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

Genau das ist mir nicht 100% klar, wenn ich das nicht mache scheitert nur mein Backup, aber meine VM (qcow2) ist völlig in Ordnung?
Was passiert wenn ich bei einem Problem nur die .qcow2 auf einen neuen Host lege, also die checkpoints verloren sind?

Hintergrund, wir kopieren die VMs zusätzlich mit der snapshot Funktion (virsh snapshot-create-as), ich fragen mich nun ob die Images in Ordnung sind wenn parallel (nicht gleichzeitig) ein Backup
mit virtnbdbackup durchgeführt wird und damit checkpoints erzeugt werden.

1) virtnbdbackup sollte *nie* etwas tun das qcow file beschädigt
2) wenn die libivrt relevanten dateien *nicht* kopiert werden, ist die dirty bitmap in der qcow2 datei verzeichnet, der libvirt daemon weis davon aber nichts: weitere backups werden dann fehlschlagen weil virtnbdbackup versuchen wird einen checkpoint anzulegen der zwar in der qcow2 steht, von dem ihm libvirt nichts sagt.

Ich würde empfehlen:

1) wenn die Virtuellen maschinen regelmässig zwischen den hosts wandern wie im README beschrieben das checkpoint folder zentral verwalten
2) wenn nicht, bei kopieren der Virtuellen maschinen ebenfalls die Checkpoint informationen aus /etc/ mitkopieren und auf dem ziel libvirt einspielen.
3) Als alternative vor dem kopieren der vm alle checkpoints libvirt seite (virsh checkpoint-remove) löschen, die VM kopieren und auf dem zielsystem mit ienem neuen vollbackup beginnen.

[slu]

2) wenn die libivrt relevanten dateien *nicht* kopiert werden, ist die dirty bitmap in der qcow2 datei verzeichnet, der libvirt daemon weis davon aber nichts: weitere backups werden dann fehlschlagen weil virtnbdbackup versuchen wird einen checkpoint anzulegen der zwar in der qcow2 steht, von dem ihm libvirt nichts sagt.

Das wäre meine Frage, wie bekomme ich wieder eine ordentliche qcow2?
Einfach mit einem neuen full Backup?

[abi]

2) wenn die libivrt relevanten dateien *nicht* kopiert werden, ist die dirty bitmap in der qcow2 datei verzeichnet, der libvirt daemon weis davon aber nichts: weitere backups werden dann fehlschlagen weil virtnbdbackup versuchen wird einen checkpoint anzulegen der zwar in der qcow2 steht, von dem ihm libvirt nichts sagt.

Das wäre meine Frage, wie bekomme ich wieder eine ordentliche qcow2?
Einfach mit einem neuen full Backup?

nein, ein full backup wird im zweifelsfalle schon schiefgehen weil der checkpoint der bei backup
gelöscht werden soll nicht existiert. Kommt es zu dieser situation:

Unable to execute QEMU command 'transaction': Bitmap already exists [..]

muss man die definierten dirty bitmaps in der qcow datei mittels qemu-img löschen.

[slu]

muss man die definierten dirty bitmaps in der qcow datei mittels qemu-img löschen.

Ich möchte das noch einmal zusammenfassen, wenn man nur die .qcow2 hat und die VM neu anlegt (anderer Host) sind noch die bitmaps in der .qcow2
gespeichert was ein Backup blockiert, die VM ist jedoch völlig in Ordnung.

Das ganze bekommt man dann so gefixed:

Code: Alles auswählen

virsh shutdown VM
qemu-img info vmdisk.qcow2

qemu-img bitmap --remove vmdisk.qcow2 virtnbdbackup.0
qemu-img bitmap --remove vmdisk.qcow2 virtnbdbackup.1
[...]

Abschließend mit qemu-img info vmdisk.qcow2 überprüfen ob alle entfernt wurden.

Sollte ich hier was falsches schreiben bitte ich um eine Rückmeldung.
Mir geht es hier um Worst Case Situationen bei dem man z.B. nur noch eine Office Sicherung der .qcow2 Datei hat...