Backups sind wiederholt sehr gross

[drnicolas]

gerade läuft zum dritten Mal ein Backup-Job.
Ich hätte aber erwartet, daß die Backup-Grössen und Zeiten beim zweiten und dritten Durchlauf deutlich kleiner/kürzer sind, da nur Differenzen/Snapshots gesichert werden.
Es werden aber immer die ganzen Festplatten gesichert.
Wie kommt das ? Ich bin mir nicht sicher ob meine Festplatten raw oder qcow2 sind (wü würde das angezeigt - ich sehe nur den Namen)

 

[Dunuin]

Qcow2 hast du immer bei NFS/SMB/Directory Storage. Raw bei LVM/LVM-Thin/ZFS Storage.

Was hast du für einen Backup Mode eingestellt? Und sicherst du LXCs oder VMs?
LXCs nutzen generell kein Dirty-Bitmapping, so dass da alle Dateien/Ordner (aber nicht der leere Bereich der virtuellen Disk) immer komplett gelesen werden muss. Und bei VMs klappt das Dirty-Bitmapping nur so lange, wie du die VM nicht neustartest. Backups im "Stop"-Mode können also kein Dirty-Bitmapping nutzen, da für jedes Backup die VM runtergefahren wird und damit das Dirty-Bitmapping zurückgesetzt wird, die virtuelle Disk also immer zu 100% (inkl. leeren Bereichen) komplett neu eingelesen werden muss. Manuell die VM stoppen oder den Server rebooten darfst du natürlich auch nicht.

Platz auf dem PBS sollte es aber so oder so weniger brauchen, da je dedupliziert wird. Und die hochgeladenen Daten sollten auch kleiner sein, da wegen Deduplizierung nicht hochgeladen werden muss, was schon vorhanden ist.
Nach den Backupgrößen die im PBS WebUI angezeigt werden darfst du übrigens nicht gehen. Die zeigen nur die Rohgröße von vor dem Backup und haben nicht mit der tatsächlichen Größe des Backups zu tun. PBS weiß selbst nicht wie groß deine einzelnen Backups sind. Auf was du da achten solltest ist, wie groß dein Datastore vor dem Backup war und wie groß er nachdem Backup ist. Die Differenz ist dann, wie viel das Backups wirklich brauchte.
Zeig uns am besten mal ein Log eines Backups. Am Ende davon sollte stehen wie viele der Chunks schon vorhanden waren und daher nicht übertragen werden mussten. Und wieviel der virtuellen Disk unbenutzt war und nicht gesendet werden musste kann man auch sehen. Und ob Dirty-Bitmapping benutzt werden konnte oder nicht.

 

[drnicolas]

Danke für diese ausführliche Darstellung.
ich war i.d.T. über die aufegührten Grössen entsetzt.
Die Summation dieser Zahlen müsste ca. 2,5x die HDD-Grösse ergeben.

ich lasse das jetzt mal ein paar Tage laufen; mals sehen ob sich alles einpendetlt.

 

[schloegel-edv]

Hallo,

ich habe ebenfalls einen LXC mit einem Fileserver unter ZFS drauf. Das sind etwa 620GB reine Dateien drin. Es dauert jedes Mal etwa 3,5 Stunden, während alle anderen VMs relativ schnell gesichert werden. Anbei mal ein Auszug aus dem Logfile. Habe ich das gleiche Problem?

INFO: starting new backup job: vzdump --quiet 1 --mailnotification always --mode snapshot --storage PBS --compress zstd --notes-template '{{guestname}}' --all 1 --mailto kontakt@schloegel-edv.de
INFO: Starting Backup of VM 100 (lxc)
INFO: Backup started at 2022-10-16 17:00:03
INFO: status = running
INFO: CT Name: zamba
INFO: including mount point rootfs ('/') in backup
INFO: including mount point mp0 ('/tank') in backup
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: suspend vm to make snapshot
INFO: create storage snapshot 'vzdump'
INFO: resume vm
INFO: guest is online again after 2 seconds
INFO: creating Proxmox Backup Server archive 'ct/100/2022-10-16T15:00:03Z'
INFO: run: /usr/bin/proxmox-backup-client backup --crypt-mode=none pct.conf:/var/tmp/vzdumptmp3869066_100/etc/vzdump/pct.conf root.pxar:/mnt/vzsnap0 --include-dev /mnt/vzsnap0/./ --include-dev /mnt/vzsnap0/./tank --skip-lost-and-found --exclude=/tmp/?* --exclude=/var/tmp/?* --exclude=/var/run/?*.pid --backup-type ct --backup-id 100 --backup-time 1665932403 --repository root@pam@192.168.2.129:BACKUP
INFO: Starting backup: ct/100/2022-10-16T15:00:03Z
INFO: Client name: pve-mig
INFO: Starting backup protocol: Sun Oct 16 17:00:05 2022
INFO: Downloading previous manifest (Sun Oct 16 12:00:01 2022)
INFO: Upload config file '/var/tmp/vzdumptmp3869066_100/etc/vzdump/pct.conf' to 'root@pam@192.168.2.129:8007:BACKUP' as pct.conf.blob
INFO: Upload directory '/mnt/vzsnap0' to 'root@pam@192.168.2.129:8007:BACKUP' as root.pxar.didx
INFO: root.pxar: had to backup 62.859 MiB of 619.747 GiB (compressed 4.831 MiB) in 12074.79s
INFO: root.pxar: average backup speed: 5.33 KiB/s
INFO: root.pxar: backup was done incrementally, reused 619.686 GiB (100.0%)
INFO: Uploaded backup catalog (21.476 MiB)
INFO: Duration: 12075.27s
INFO: End Time: Sun Oct 16 20:21:20 2022
INFO: adding notes to backup
INFO: cleanup temporary 'vzdump' snapshot
INFO: Finished Backup of VM 100 (03:21:21)
INFO: Backup finished at 2022-10-16 20:21:24

 

[schloegel-edv]

wobei ich zufügen muss - bei einem anderen PVE nach PBS geht es deutlich schneller, es sind zwar nur etwas 100GB reservierter Speicher, aber hier ist es so:

INFO: Starting Backup of VM 110 (lxc)
INFO: Backup started at 2022-10-17 10:55:45
INFO: status = running
INFO: CT Name: fileserver
INFO: including mount point rootfs ('/') in backup
INFO: excluding volume mount point mp0 ('/tank') from backup (disabled)
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
INFO: creating Proxmox Backup Server archive 'ct/110/2022-10-17T08:55:45Z'
INFO: run: /usr/bin/proxmox-backup-client backup --crypt-mode=none pct.conf:/var/tmp/vzdumptmp1020990_110/etc/vzdump/pct.conf root.pxar:/mnt/vzsnap0 --include-dev /mnt/vzsnap0/./ --skip-lost-and-found --exclude=/tmp/?* --exclude=/var/tmp/?* --exclude=/var/run/?*.pid --backup-type ct --backup-id 110 --backup-time 1665996945 --repository root@pam@144.76.56.126:DATA
INFO: Starting backup: ct/110/2022-10-17T08:55:45Z
INFO: Client name: pve
INFO: Starting backup protocol: Mon Oct 17 10:55:45 2022
INFO: Downloading previous manifest (Sun Oct 16 17:42:49 2022)
INFO: Upload config file '/var/tmp/vzdumptmp1020990_110/etc/vzdump/pct.conf' to 'root@pam@144.76.56.126:8007:DATA' as pct.conf.blob
INFO: Upload directory '/mnt/vzsnap0' to 'root@pam@144.76.56.126:8007:DATA' as root.pxar.didx
INFO: root.pxar: had to backup 161.169 MiB of 1.509 GiB (compressed 15.992 MiB) in 9.73s
INFO: root.pxar: average backup speed: 16.57 MiB/s
INFO: root.pxar: backup was done incrementally, reused 1.351 GiB (89.6%)
INFO: Uploaded backup catalog (680.452 KiB)
INFO: Duration: 10.18s
INFO: End Time: Mon Oct 17 10:55:55 2022
INFO: cleanup temporary 'vzdump' snapshot
INFO: Finished Backup of VM 110 (00:00:10)

und wieso ist die "average backup speed" sooo unterschiedlich?

 

[dcsapak]

wie bereits erwähnt, müssen bei container backups immer die ganzen source files gelesen werden. raufgeladen werden dann aber nur jene chunks die neu sind bzw sich geändert haben
zb die zeilen

INFO: root.pxar: had to backup 62.859 MiB of 619.747 GiB (compressed 4.831 MiB) in 12074.79s
INFO: root.pxar: average backup speed: 5.33 KiB/s
INFO: root.pxar: backup was done incrementally, reused 619.686 GiB (100.0%)

sagen dass nur ~63 MiB von 620 GiB raufgeladen werden mussten (das ist auch die größe die bei der 'speed' berechnung genommen wird, da ja tatsächlich nur diese menge an daten raufgeladen wurde)

 

[Dunuin]

wie bereits erwähnt, müssen bei container backups immer die ganzen source files gelesen werden. raufgeladen werden dann aber nur jene chunks die neu sind bzw sich geändert haben
zb die zeilen


sagen dass nur ~63 MiB von 620 GiB raufgeladen werden mussten (das ist auch die größe die bei der 'speed' berechnung genommen wird, da ja tatsächlich nur diese menge an daten raufgeladen wurde)

Da wäre es wirklich eine Überlegung wert den Fileserver LXC auf eine Fileserver VM umzustellen. Wenn sich dann nur 63MB geändert haben, dann müssen auch echt nur die groben 63 MB gelesen werden anstatt immer die kompletten 620GB. Da wäre das Backup auch in 1-2 Minuten durch nicht nicht erst in 3,5 Stunden.

 

[schloegel-edv]

Danke Euch.

 

[ITT]

Genau deshalb lasse ich (wenn möglich) die Finger weg von LXC.

 

[RolandK]

>wie bereits erwähnt, müssen bei container backups immer die ganzen source files gelesen werden

warum ist das so? kann nicht der last modify timestamp ausgewertet werden? rsync oder borg-backup packen zu sichernde dateien doch auch nur an , wenn sie sich geändert haben seit dem letzten backup/transfer.

 

[fabian]

>wie bereits erwähnt, müssen bei container backups immer die ganzen source files gelesen werden

warum ist das so? kann nicht der last modify timestamp ausgewertet werden? rsync oder borg-backup packen zu sichernde dateien doch auch nur an , wenn sie sich geändert haben seit dem letzten backup/transfer.

rsync erlaubt je nach genauigkeit der "hat sich geaendert" checks unterschiedliches verhalten - wenn nur auf die zeit oder die groesse geschaut wird reicht ein stat (metadaten lesen), ansonsten (checksumme) muss auch das ganze file gelesen und gehasht werden (nur das ist wirklich korrekt!).

borg verwendet einen metadaten cache, wenn sich die metadaten nicht geaendert haben wird auch das file als unveraendert betrachtet. der cache braucht aber natuerlich platz - borg macht generell andere tradeoffs als PBS (kein multi-user pro repository z.b., was sehr viele konsequenzen hat).

es gibt einen bugzilla entry wo einige aspekte des ganzen diskutiert werden:

https://bugzilla.proxmox.com/show_bug.cgi?id=3174

mit dem bestehenden pxar archiv format laesst sich so ein cache nicht vernuenftig integrieren - es wird vermutlich eine art "pxar v2" + metadaten cache brauchen, aber das ist kein bereich wo schnellschuesse sinvoll sind (so ein neues archiv format muss ja ueber jahre/jahrzehnte unterstuetzt werden, darf keine konsistenzprobleme/fundamentale bugs haben, etc.!)

 

[RolandK]

danke!