Backup über Stop dauert ewig, bis die Maschine wieder verfügbar ist

[ozz-project]

Guten Morgen
Aktuelle sichere ich meine Maschinen mit der internen Backup-Funktion über Nutzung von stop. Bisher bin ich davon ausgegangen dass die Maschine runterfährt, ein snapchat erstellt wird und die Maschine wieder startet. Die Sicherung erfolgt dann übern Nutzung des erstellten snapshots. Scheinbar ist das aber nicht der Fall da bei der Sicherung von den großen Maschinen der restart erst erfolgt nachdem das Backup komplett durch ist.
Das Volume ist dünn besetzt und unterstützt damit auch snapshots.
Ich habe das Forum schon gewälzt und noch die Doku aber so richtig schlau werde ich nicht daraus ob das nun eine Funktion von der internen Backup-Funktion ist oder ob ich dafür den Backup Server als solches benötige.

Daher meine Frage: kann ich über die interne Backup Funktion bei Nutzung von stop ein schnelles Backup erstellen bei dem die Maschine möglichst schnell wieder verfügbar ist und ich nicht warten muss bis das komplette Backup durch ist? Wenn nicht wie mache ich es dann?

 

[fabian]

hier fehlen ein bisschen Details..

koenntest du (zumindest):
- VM/CT config
- storage config
- pveversion -v
- backup task log

posten?

du musst erstmal grundsaetzlich zwischen VM und CT unterscheiden.

bei VMs funktioniert ein Stop Backup so:
- VM wird sauber heruntergefahren falls sie laeuft
- VM wird pausiert gestartet
- in QEMU wird intern ein "Snapshot" erstellt (das hat nichts mit Storage-Snapshots zu tun), ab diesem Zeitpunkt werden alle Writes aus der VM abgefangen und erst die Originaldaten gesichert bevor sie ueberschrieben werden
- das eigentliche Backup wird gestartet und faengt an, aktiv alle Daten der gesicherten Disks aufs Backupziel zu kopieren
- die VM wird "resumed" und booted (waehrend das Backup im Hintergrund laeuft), falls sie am Anfang des Backups gelaufen ist
- sobald das Backup fertig ist, wird die VM wieder gestoppt, falls sie nicht am Anfang des Backups gelaufen ist

bei Containern fehlt uns der Layer der das Wegkopieren im laufenden Betrieb ermoeglicht. hier ist ein Stop Backup wirklich ein Stop Backup:
- Container wird sauber runtergefahren falls er laeuft
- die Mountpoints des Containers werden am Host gemounted
- das Backup wird gemacht
- die Mountpoints werden wieder unmounted
- der Container wird wieder gestartet, falls er am Anfang gelaufen ist

bei Containern brauchst du zwingend Storage Support fuer Snapshots, damit die Downtime klein bleibt. dann geht der Snapshot Modus:
- Snapshot wird am Storage angelegt (ggf. kurzer Freeze des Containers aus Konsistenzgruenden)
- Snapshot wird gemounted
- Backup wird vom Snapshot gezogen
- Snapshot wird wieder unmounted
- Snapshot wird geloescht

 

[Falk R.]

Warum machst du denn nicht einfach Snapshot Backups?

 

[ozz-project]

Warum machst du denn nicht einfach Snapshot Backups?

Hallo Frank, mit Snapshots und Datenbank habe ich keinen guten Erfahrungen gemacht. Es passiert leider immer noch, das nicht alle geflushed werden und dann sind wenn man Glück hat nur einige Transaktionen weg. Bei Pech brauch ich dann ein Restore.

 

[ozz-project]

Hallo Fabian,
ja klar. Hier die Infos.

104.conf

arch: amd64
cores: 5
features: fuse=1,keyctl=1,nesting=1
hostname: butch
memory: 5000
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:49:66:78,ip=dhcp,type=veth
onboot: 1
ostype: ubuntu
rootfs: sddusbthin:vm-104-disk-0,size=94G
swap: 2500
unprivileged: 1

backup Log

()
INFO: starting new backup job: vzdump 104 --compress zstd --notification-mode auto --remove 0 --notes-template '{{guestname}}' --node proxmox --storage sweetums --mode stop
INFO: Starting Backup of VM 104 (lxc)
INFO: Backup started at 2025-04-26 06:56:15
INFO: status = running
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: CT Name: butch
INFO: including mount point rootfs ('/') in backup
INFO: stopping virtual guest
INFO: creating vzdump archive '/mnt/pve/sweetums/dump/vzdump-lxc-104-2025_04_26-06_56_15.tar.zst'
INFO: Total bytes written: 72507013120 (68GiB, 110MiB/s)
INFO: archive file size: 51.70GB
INFO: adding notes to backup
INFO: restarting vm
INFO: guest is online again after 677 seconds
INFO: Finished Backup of VM 104 (00:11:17)
INFO: Backup finished at 2025-04-26 07:07:32
INFO: Backup job finished successfully
INFO: notified via target `pushover`
TASK OK

ausgabe pve

pveversion -v
pve-kernel-5.13: 7.1-9
proxmox-kernel-6.8.12-10-pve-signed: 6.8.12-10
proxmox-kernel-6.8: 6.8.12-10
proxmox-kernel-6.8.12-9-pve-signed: 6.8.12-9
proxmox-kernel-6.8.12-8-pve-signed: 6.8.12-8
proxmox-kernel-6.5.13-6-pve-signed: 6.5.13-6
proxmox-kernel-6.5: 6.5.13-6
pve-kernel-5.13.19-6-pve: 5.13.19-15
pve-kernel-5.13.19-2-pve: 5.13.19-4
ceph-fuse: 17.2.8-pve2
corosync: 3.1.9-pve1
criu: 3.17.1-2+deb12u1
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx11
intel-microcode: 3.20250211.1~deb12u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libknet1: 1.30-pve2
libproxmox-acme-perl: 1.6.0
libproxmox-backup-qemu0: 1.5.1
libproxmox-rs-perl: 0.3.5
libpve-access-control: 8.2.2
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.1.0
libpve-cluster-perl: 8.1.0
libpve-common-perl: 8.3.1
libpve-guest-common-perl: 5.2.2
libpve-http-server-perl: 5.2.2
libpve-network-perl: 0.11.2
libpve-rs-perl: 0.9.4
libpve-storage-perl: 8.3.6
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.6.0-2
proxmox-backup-client: 3.4.1-1
proxmox-backup-file-restore: 3.4.1-1
proxmox-firewall: 0.7.1
proxmox-kernel-helper: 8.1.1
proxmox-mail-forward: 0.3.2
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.7
proxmox-widget-toolkit: 4.3.10
pve-cluster: 8.1.0
pve-container: 5.2.6
pve-docs: 8.4.0
pve-edk2-firmware: 4.2025.02-3
pve-esxi-import-tools: 0.7.3
pve-firewall: 5.1.1
pve-firmware: 3.15-3
pve-ha-manager: 4.0.7
pve-i18n: 3.4.2
pve-qemu-kvm: 9.2.0-5
pve-xtermjs: 5.5.0-2
qemu-server: 8.3.12
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.7-pve2

 

[Falk R.]

Hallo Frank, mit Snapshots und Datenbank habe ich keinen guten Erfahrungen gemacht. Es passiert leider immer noch, das nicht alle geflushed werden und dann sind wenn man Glück hat nur einige Transaktionen weg. Bei Pech brauch ich dann ein Restore.

Ich arbeite fast 20 Jahre mit Virtualisierung und das ist mir noch nie untergekommen. Wenn dir soetwas passiert ist, war garantiert etwas nicht richtig konfiguriert.
Bei Linux DB Servern muss man natürlich wissen was man tut, bei Windows ist das für Dumme gemacht und der VSS Dienst übernimmt alles für dich.
Eventuell mal die Ursache beseitigen, statt Phänomene.

 

[ozz-project]

Ich arbeite fast 20 Jahre mit Virtualisierung und das ist mir noch nie untergekommen. Wenn dir soetwas passiert ist, war garantiert etwas nicht richtig konfiguriert.
Bei Linux DB Servern muss man natürlich wissen was man tut, bei Windows ist das für Dumme gemacht und der VSS Dienst übernimmt alles für dich.
Eventuell mal die Ursache beseitigen, statt Phänomene.

Hallo Falk,
ich weiß nicht in welchen Bereich du mit Virtualisierung arbeitest. Bei Datenbanken ist das definitiv nicht so ungewöhnlich, besonders bei intensiver Nutzung. Schön wäre, wenn das VSS und Windows wirklich für "Dumme" ist. Leider ist das nicht so. Die Applikation muss für den VSS Dienst (bei Datenbanken besonders) einen tauglichen Agent mitbringen. SQL Server bringt einen mit mit. MySQl aber nicht. Und mit denen haben ich immer viel Spaß.
Aber ich lerne gerne dazu.

 

[Falk R.]

Naja, im Enterprise Umfeld hat man eher mit MS SQL, Oracle oder PostgreSQL zu tun, die bringen natürlich einen VSS Provider und Writer mit. MySQL sehe ich eher auf Linux VMs und da kann man das auch ganz einfach über den qemu guest Agent sauber steuern.

 

[fabian]

um zurueck zum urspruenglichen problem zu kommen - du hast einen container, da gibts quasi 3 level and downtime vs konsistenz:

- snapshot: braucht storage support, keine konsistenz auf applikationsebene, geringste downtime
- suspend: braucht temporaeren speicherplatz, keine konsistenz auf applikationsebene, downtime haengt davon ab wieviel seit start des backups geschrieben worden ist
- stop: braucht weder storage support noch temporaeren speicherplatz, konsistenz auf applikationsebene durch shutdown, downtime = komplette dauer des backups

pick your poison

 

[UdoB]

pick your poison

Ich wähle "VM statt Container". Durchaus aus mehreren Gründen, aber "bessere" Backups sind einer davon.

 

[fabian]

klar - wie in meiner vorherigen antwort beschrieben, VMs haben hier klar den vorteil dass dank QEMU ein layer zwischen storage und gast OS liegt der den I/O pfad komplett kontrolliert, und daher auch konsistente backups erzeugen kann

 

[GMBauer]

Hallo TE,

nur damit ich das verstehen kann: Du nutzt ein externes USB-Laufwerk für eine 94 GByte große Ubuntu-Maschine mit 74 GByte Daten mit einer Datenbank drauf und sicherst ohne Dirty Bitmap (wohin eigentlich, auf das externe QNAP?) und es gefällt dir nicht, dass das so lange dauert?

 

[ozz-project]

Hallo GMBauer,
um es kurz zu machen ja. Deinen Vorschlag mit dem Dirty bitmap ist oben schon diskutiert. und sind in dem Setup keine Option. Daher auch meine initiale Frage zu der Funktionweise mit Backup über Stop, weil applikations Konsistenz gebraucht wird, aber nur in der Methode zur Verfügung steht. Fabian hat das oben gut erklärt, wo die Snapshots erstellt werden. in der VM oder im Dateisystem mit Speicher oder ohne.

Mein Frage war : kann ich bei Stop nicht die Maschine runterfahren, ein applikations Konsistenz bekommen. einen FS Snapshot ziehen, die Maschine neu starten und im Hintergrund vom Snapshot backupen. Reduziert die Downtime und man hat konsiztente Backup. So muss auf der Komplette Backup warten. und das dauert zu lange.

 

[GMBauer]

Ich versuche seit ein paar Tagen, zu verstehen, warum du dieses Setup so gewählt hast wie du es getan hast. Bzw warum du es nicht schneller machst. Gelingt mir aber nicht.

Mit einem besseren Setup wird das ganze deutlich schneller, aber das willst / kannst du ja nicht. Ich fürchte, dass es für dich keine wirklich tolle Lösung gibt.