[SOLVED] VM wärend Backup oder Snapshot nicht zu gebrauchen

[mabox]

Hallo Zusammen,
mir fällt schon länger folgendes auf und dachte jetzt frag ich doch mal nach.
Also wären meine Backups laufen über den Proxmox Backup Server oder auch wären der Zeit wo ich einen Snapshots erstelle, ist die VM kaum zu gebrauchen und verhält sich ganz zäh, langsam quasi. Die VM ist dann mit einem "Schloßsymbol" ausgegraut. Ist das normal oder irgendeine Einstellungssache?
Grüße
mabox

 

[dakralex]

Hi!

Wie schaut denn die Config dieser VM aus (qm config <vmid>) und könntest du einen Log von dem Backup Job posten? Welche Hardware ist bei den PVE und PBS Installationen im Einsatz?

Wenn die VM während dem Backup weiterhin viele Schreiboperationen ausführt -- besonders wenn diese relativ unstrukturiert sind -- müssen diese solange warten, bis der vorherige Zustand der Disk an diesem Speicherort gespeichert wurde. Eine Möglichkeit wäre es Backup Fleecing [0] zu aktivieren, wenn dies noch nicht gemacht wurde. Damit werden die alten Daten bereits gecached, um an das PBS gesendet zu werden.

[0] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_vm_backup_fleecing

 

[mabox]

Hi!

Wie schaut denn die Config dieser VM aus (qm config <vmid>) und könntest du einen Log von dem Backup Job posten? Welche Hardware ist bei den PVE und PBS Installationen im Einsatz?

Wenn die VM während dem Backup weiterhin viele Schreiboperationen ausführt -- besonders wenn diese relativ unstrukturiert sind -- müssen diese solange warten, bis der vorherige Zustand der Disk an diesem Speicherort gespeichert wurde. Eine Möglichkeit wäre es Backup Fleecing [0] zu aktivieren, wenn dies noch nicht gemacht wurde. Damit werden die alten Daten bereits gecached, um an das PBS gesendet zu werden.

[0] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_vm_backup_fleecing

Hi,
also hier wäre die config:

[root@pve ~]# qm config 101
bios: ovmf
boot: order=scsi0;ide2;net0
cores: 4
cpu: host
efidisk0: svm:101/vm-101-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
ide2: none,media=cdrom
memory: 32768
meta: creation-qemu=6.1.0,ctime=1651402166
name: cloud
net0: virtio=BC:24:11:4E:78:36,bridge=vmbr0,firewall=1
numa: 0
onboot: 1
ostype: l26
parent: snap
scsi0: svm:101/vm-101-disk-1.qcow2,iothread=1,size=200G,ssd=1
scsi2: svm:101/vm-101-disk-2.qcow2,iothread=1,size=1550G,ssd=1
scsi3: svm:101/vm-101-disk-3.qcow2,iothread=1,size=1550G,ssd=1
scsi4: svm:101/vm-101-disk-4.qcow2,iothread=1,size=1550G,ssd=1
scsi5: svm:101/vm-101-disk-5.qcow2,iothread=1,size=1550G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=aeec748c-0d2a-4c41-b7f9-15a0ed3131e1
sockets: 1
tags: Prod
usb0: host=2-1
vga: std,memory=256
vmgenid: cdc0f268-cb77-4c30-876d-a3b9eb96aa4b

Hier das log vom Backupjob. Was mir hier auffällt, initial hat der Backup Job auch sehr lange gedauert, dann lange Zeit lief er nur ein paar Minuten erfolgreich durch, jetzt schon eine ganze Weile läuft er wieder Stundenlang.......

Header
Proxmox
Virtual Environment 8.2.7
Virtual Machine 101 (cloud) on node 'pve'
Prod
Status
 
running
HA State
 
none
Node
 
pve
CPU usage
 
11.40% of 4 CPU(s)
Memory usage
 
66.09% (21.15 GiB of 32.00 GiB)
Bootdisk size
 
200.00 GiB
IPs
No Guest Agent configured
Logs
()
INFO: starting new backup job: vzdump 105 101 102 --mailto x --fleecing 0 --notes-template '{{guestname}}' --quiet 1 --storage pbs-nas1 --mode snapshot --mailnotification failure
INFO: Starting Backup of VM 101 (qemu)
INFO: Backup started at 2024-11-14 01:00:01
INFO: status = running
INFO: VM Name: cloud
INFO: include disk 'scsi0' 'svm:101/vm-101-disk-1.qcow2' 200G
INFO: include disk 'scsi2' 'svm:101/vm-101-disk-2.qcow2' 1550G
INFO: include disk 'scsi3' 'svm:101/vm-101-disk-3.qcow2' 1550G
INFO: include disk 'scsi4' 'svm:101/vm-101-disk-4.qcow2' 1550G
INFO: include disk 'scsi5' 'svm:101/vm-101-disk-5.qcow2' 1550G
INFO: include disk 'efidisk0' 'svm:101/vm-101-disk-0.qcow2' 528K
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating Proxmox Backup Server archive 'vm/101/2024-11-14T00:00:01Z'
INFO: started backup task 'df416184-7525-4f85-a0b7-cf7439e8637d'
INFO: resuming VM again
INFO: efidisk0: dirty-bitmap status: OK (drive clean)
INFO: scsi0: dirty-bitmap status: existing bitmap was invalid and has been cleared
INFO: scsi2: dirty-bitmap status: existing bitmap was invalid and has been cleared
INFO: scsi3: dirty-bitmap status: existing bitmap was invalid and has been cleared
INFO: scsi4: dirty-bitmap status: existing bitmap was invalid and has been cleared
INFO: scsi5: dirty-bitmap status: existing bitmap was invalid and has been cleared
INFO: using fast incremental mode (dirty-bitmap), 6.2 TiB dirty of 6.3 TiB total
INFO:   0% (96.0 MiB of 6.2 TiB) in 3s, read: 32.0 MiB/s, write: 28.0 MiB/s
INFO:   1% (64.0 GiB of 6.2 TiB) in 1h 14m 9s, read: 14.7 MiB/s, write: 11.3 MiB/s
INFO:   2% (128.1 GiB of 6.2 TiB) in 1h 58m 11s, read: 24.8 MiB/s, write: 12.4 MiB/s
INFO:   3% (192.0 GiB of 6.2 TiB) in 2h 2m 14s, read: 269.3 MiB/s, write: 9.9 MiB/s
INFO:   4% (257.2 GiB of 6.2 TiB) in 2h 4m 47s, read: 436.3 MiB/s, write: 2.6 MiB/s
INFO:   5% (321.9 GiB of 6.2 TiB) in 2h 6m 37s, read: 602.2 MiB/s, write: 4.1 MiB/s
INFO:   6% (384.4 GiB of 6.2 TiB) in 2h 9m 51s, read: 330.0 MiB/s, write: 7.1 MiB/s
INFO:   7% (448.3 GiB of 6.2 TiB) in 2h 11m 33s, read: 641.7 MiB/s, write: 11.4 MiB/s
INFO:   8% (512.1 GiB of 6.2 TiB) in 2h 13m 36s, read: 531.0 MiB/s, write: 4.4 MiB/s
INFO:   9% (576.2 GiB of 6.2 TiB) in 2h 16m 24s, read: 390.5 MiB/s, write: 4.9 MiB/s
INFO:  10% (640.1 GiB of 6.2 TiB) in 2h 18m 54s, read: 436.5 MiB/s, write: 2.8 MiB/s
INFO:  11% (704.1 GiB of 6.2 TiB) in 2h 21m 54s, read: 364.1 MiB/s, write: 5.6 MiB/s
INFO:  12% (768.5 GiB of 6.2 TiB) in 2h 24m 31s, read: 419.7 MiB/s, write: 3.4 MiB/s
INFO:  13% (833.3 GiB of 6.2 TiB) in 2h 26m 39s, read: 518.4 MiB/s, write: 7.2 MiB/s
INFO:  14% (908.7 GiB of 6.2 TiB) in 2h 26m 44s, read: 15.1 GiB/s, write: 0 B/s
INFO:  15% (970.2 GiB of 6.2 TiB) in 2h 26m 48s, read: 15.4 GiB/s, write: 0 B/s
INFO:  16% (1.0 TiB of 6.2 TiB) in 2h 26m 52s, read: 15.4 GiB/s, write: 0 B/s
INFO:  17% (1.1 TiB of 6.2 TiB) in 2h 26m 56s, read: 15.5 GiB/s, write: 0 B/s
INFO:  18% (1.1 TiB of 6.2 TiB) in 2h 27m, read: 15.5 GiB/s, write: 0 B/s
INFO:  19% (1.2 TiB of 6.2 TiB) in 2h 27m 4s, read: 15.5 GiB/s, write: 0 B/s
INFO:  20% (1.3 TiB of 6.2 TiB) in 2h 27m 9s, read: 13.9 GiB/s, write: 0 B/s
INFO:  21% (1.3 TiB of 6.2 TiB) in 2h 27m 14s, read: 14.2 GiB/s, write: 0 B/s
INFO:  22% (1.4 TiB of 6.2 TiB) in 2h 27m 18s, read: 15.2 GiB/s, write: 0 B/s
INFO:  23% (1.4 TiB of 6.2 TiB) in 2h 27m 22s, read: 15.4 GiB/s, write: 0 B/s
INFO:  24% (1.5 TiB of 6.2 TiB) in 2h 27m 26s, read: 15.4 GiB/s, write: 0 B/s
INFO:  25% (1.6 TiB of 6.2 TiB) in 2h 27m 30s, read: 15.4 GiB/s, write: 0 B/s
INFO:  26% (1.6 TiB of 6.2 TiB) in 2h 29m 30s, read: 520.0 MiB/s, write: 2.8 MiB/s
INFO:  27% (1.7 TiB of 6.2 TiB) in 2h 32m 54s, read: 320.0 MiB/s, write: 9.0 MiB/s
INFO:  28% (1.8 TiB of 6.2 TiB) in 2h 35m 34s, read: 408.9 MiB/s, write: 2.7 MiB/s
INFO:  29% (1.8 TiB of 6.2 TiB) in 2h 37m 33s, read: 550.1 MiB/s, write: 3.8 MiB/s
INFO:  30% (1.9 TiB of 6.2 TiB) in 2h 40m 57s, read: 321.4 MiB/s, write: 6.7 MiB/s
INFO:  31% (1.9 TiB of 6.2 TiB) in 2h 42m 45s, read: 610.2 MiB/s, write: 9.9 MiB/s
INFO:  32% (2.0 TiB of 6.2 TiB) in 2h 44m 55s, read: 503.9 MiB/s, write: 4.1 MiB/s
INFO:  33% (2.1 TiB of 6.2 TiB) in 2h 47m 43s, read: 389.2 MiB/s, write: 4.5 MiB/s
INFO:  34% (2.1 TiB of 6.2 TiB) in 2h 50m 20s, read: 415.9 MiB/s, write: 4.0 MiB/s
INFO:  35% (2.2 TiB of 6.2 TiB) in 2h 53m 3s, read: 404.6 MiB/s, write: 4.9 MiB/s
INFO:  36% (2.3 TiB of 6.2 TiB) in 2h 55m 44s, read: 404.5 MiB/s, write: 4.9 MiB/s
INFO:  37% (2.3 TiB of 6.2 TiB) in 2h 57m 24s, read: 702.0 MiB/s, write: 6.5 MiB/s
INFO:  38% (2.4 TiB of 6.2 TiB) in 2h 57m 28s, read: 15.3 GiB/s, write: 0 B/s
INFO:  39% (2.5 TiB of 6.2 TiB) in 2h 57m 33s, read: 15.4 GiB/s, write: 0 B/s
INFO:  40% (2.5 TiB of 6.2 TiB) in 2h 57m 37s, read: 14.1 GiB/s, write: 0 B/s
INFO:  41% (2.6 TiB of 6.2 TiB) in 2h 57m 41s, read: 15.0 GiB/s, write: 0 B/s
INFO:  42% (2.6 TiB of 6.2 TiB) in 2h 57m 45s, read: 15.4 GiB/s, write: 0 B/s
INFO:  43% (2.7 TiB of 6.2 TiB) in 2h 57m 50s, read: 15.3 GiB/s, write: 0 B/s
INFO:  44% (2.8 TiB of 6.2 TiB) in 2h 57m 54s, read: 15.4 GiB/s, write: 0 B/s
INFO:  45% (2.8 TiB of 6.2 TiB) in 2h 57m 58s, read: 15.4 GiB/s, write: 0 B/s
INFO:  46% (2.9 TiB of 6.2 TiB) in 2h 58m 2s, read: 15.4 GiB/s, write: 0 B/s
INFO:  47% (2.9 TiB of 6.2 TiB) in 2h 58m 6s, read: 15.4 GiB/s, write: 0 B/s
INFO:  48% (3.0 TiB of 6.2 TiB) in 2h 58m 10s, read: 15.4 GiB/s, write: 0 B/s
INFO:  49% (3.1 TiB of 6.2 TiB) in 2h 58m 15s, read: 13.7 GiB/s, write: 5.6 MiB/s
INFO:  50% (3.1 TiB of 6.2 TiB) in 3h 25s, read: 461.6 MiB/s, write: 3.3 MiB/s
INFO:  51% (3.2 TiB of 6.2 TiB) in 3h 5m 10s, read: 229.7 MiB/s, write: 9.3 MiB/s
INFO:  52% (3.3 TiB of 6.2 TiB) in 3h 7m 21s, read: 500.8 MiB/s, write: 3.2 MiB/s
INFO:  53% (3.3 TiB of 6.2 TiB) in 3h 9m 5s, read: 627.0 MiB/s, write: 5.8 MiB/s
INFO:  54% (3.4 TiB of 6.2 TiB) in 3h 26m 55s, read: 61.2 MiB/s, write: 6.4 MiB/s
INFO:  55% (3.4 TiB of 6.2 TiB) in 3h 28m 23s, read: 744.9 MiB/s, write: 8.6 MiB/s
INFO:  56% (3.5 TiB of 6.2 TiB) in 3h 30m 12s, read: 602.4 MiB/s, write: 3.9 MiB/s
INFO:  57% (3.6 TiB of 6.2 TiB) in 3h 32m 18s, read: 521.3 MiB/s, write: 2.3 MiB/s
INFO:  58% (3.6 TiB of 6.2 TiB) in 3h 34m 28s, read: 503.3 MiB/s, write: 1.8 MiB/s
INFO:  59% (3.7 TiB of 6.2 TiB) in 3h 36m 46s, read: 475.1 MiB/s, write: 2.9 MiB/s
INFO:  60% (3.8 TiB of 6.2 TiB) in 3h 38m 52s, read: 518.7 MiB/s, write: 1.7 MiB/s
INFO:  61% (3.8 TiB of 6.2 TiB) in 3h 40m 16s, read: 868.2 MiB/s, write: 4.0 MiB/s
INFO:  62% (3.9 TiB of 6.2 TiB) in 3h 40m 20s, read: 14.8 GiB/s, write: 0 B/s
INFO:  63% (3.9 TiB of 6.2 TiB) in 3h 40m 25s, read: 14.6 GiB/s, write: 0 B/s
INFO:  64% (4.0 TiB of 6.2 TiB) in 3h 40m 29s, read: 14.7 GiB/s, write: 0 B/s
INFO:  65% (4.1 TiB of 6.2 TiB) in 3h 40m 33s, read: 15.4 GiB/s, write: 0 B/s
INFO:  66% (4.1 TiB of 6.2 TiB) in 3h 40m 37s, read: 15.4 GiB/s, write: 0 B/s
INFO:  67% (4.2 TiB of 6.2 TiB) in 3h 40m 42s, read: 15.1 GiB/s, write: 0 B/s
INFO:  68% (4.3 TiB of 6.2 TiB) in 3h 40m 46s, read: 15.3 GiB/s, write: 0 B/s
INFO:  69% (4.3 TiB of 6.2 TiB) in 3h 40m 50s, read: 15.2 GiB/s, write: 0 B/s
INFO:  70% (4.4 TiB of 6.2 TiB) in 3h 40m 54s, read: 14.7 GiB/s, write: 0 B/s
INFO:  71% (4.5 TiB of 6.2 TiB) in 3h 40m 59s, read: 15.1 GiB/s, write: 0 B/s
INFO:  72% (4.5 TiB of 6.2 TiB) in 3h 41m 3s, read: 14.8 GiB/s, write: 0 B/s
INFO:  73% (4.6 TiB of 6.2 TiB) in 3h 41m 7s, read: 15.1 GiB/s, write: 0 B/s
INFO:  74% (4.6 TiB of 6.2 TiB) in 3h 42m 59s, read: 546.4 MiB/s, write: 1.6 MiB/s
INFO:  75% (4.7 TiB of 6.2 TiB) in 3h 45m 32s, read: 428.1 MiB/s, write: 6.0 MiB/s
INFO:  76% (4.8 TiB of 6.2 TiB) in 3h 47m 36s, read: 576.5 MiB/s, write: 2.5 MiB/s
INFO:  77% (4.8 TiB of 6.2 TiB) in 3h 49m 7s, read: 663.6 MiB/s, write: 3.2 MiB/s
INFO:  78% (4.9 TiB of 6.2 TiB) in 3h 52m 4s, read: 374.0 MiB/s, write: 6.7 MiB/s
INFO:  79% (4.9 TiB of 6.2 TiB) in 3h 53m 42s, read: 657.4 MiB/s, write: 7.9 MiB/s
INFO:  80% (5.0 TiB of 6.2 TiB) in 3h 55m 34s, read: 584.7 MiB/s, write: 4.2 MiB/s
INFO:  81% (5.1 TiB of 6.2 TiB) in 3h 57m 38s, read: 528.1 MiB/s, write: 1.8 MiB/s
INFO:  82% (5.1 TiB of 6.2 TiB) in 3h 59m 47s, read: 507.3 MiB/s, write: 2.0 MiB/s
INFO:  83% (5.2 TiB of 6.2 TiB) in 4h 2m 4s, read: 479.0 MiB/s, write: 3.2 MiB/s
INFO:  84% (5.3 TiB of 6.2 TiB) in 4h 4m 18s, read: 488.5 MiB/s, write: 3.0 MiB/s
INFO:  85% (5.3 TiB of 6.2 TiB) in 4h 5m 8s, read: 1.4 GiB/s, write: 2.7 MiB/s
INFO:  86% (5.4 TiB of 6.2 TiB) in 4h 5m 12s, read: 15.3 GiB/s, write: 0 B/s
INFO:  87% (5.4 TiB of 6.2 TiB) in 4h 5m 16s, read: 15.5 GiB/s, write: 0 B/s
INFO:  88% (5.5 TiB of 6.2 TiB) in 4h 5m 20s, read: 15.5 GiB/s, write: 0 B/s
INFO:  89% (5.6 TiB of 6.2 TiB) in 4h 5m 25s, read: 15.4 GiB/s, write: 0 B/s
INFO:  90% (5.6 TiB of 6.2 TiB) in 4h 5m 29s, read: 15.4 GiB/s, write: 0 B/s
INFO:  91% (5.7 TiB of 6.2 TiB) in 4h 5m 33s, read: 15.5 GiB/s, write: 0 B/s
INFO:  92% (5.8 TiB of 6.2 TiB) in 4h 5m 37s, read: 15.5 GiB/s, write: 0 B/s
INFO:  93% (5.8 TiB of 6.2 TiB) in 4h 5m 41s, read: 15.6 GiB/s, write: 0 B/s
INFO:  94% (5.9 TiB of 6.2 TiB) in 4h 5m 45s, read: 15.6 GiB/s, write: 0 B/s
INFO:  95% (5.9 TiB of 6.2 TiB) in 4h 5m 49s, read: 15.3 GiB/s, write: 0 B/s
INFO:  96% (6.0 TiB of 6.2 TiB) in 4h 5m 53s, read: 15.4 GiB/s, write: 0 B/s
INFO:  97% (6.1 TiB of 6.2 TiB) in 4h 6m 6s, read: 5.0 GiB/s, write: 13.5 MiB/s
INFO:  98% (6.1 TiB of 6.2 TiB) in 4h 7m 22s, read: 887.9 MiB/s, write: 16.2 MiB/s
INFO:  99% (6.2 TiB of 6.2 TiB) in 4h 7m 58s, read: 1.7 GiB/s, write: 8.2 MiB/s
INFO: 100% (6.2 TiB of 6.2 TiB) in 4h 8m 22s, read: 2.6 GiB/s, write: 0 B/s
INFO: backup is sparse: 3.51 TiB (56%) total zero data
INFO: backup was done incrementally, reused 6.13 TiB (98%)
INFO: transferred 6.25 TiB in 14902 seconds (439.8 MiB/s)
INFO: adding notes to backup
INFO: Finished Backup of VM 101 (04:08:29)
INFO: Backup finished at 2024-11-14 05:08:30
INFO: Starting Backup of VM 102 (qemu)
INFO: Backup started at 2024-11-14 05:08:30
INFO: status = running
INFO: VM Name: homeassistant
INFO: include disk 'scsi0' 'local:102/vm-102-disk-1.qcow2' 32G
INFO: include disk 'efidisk0' 'local:102/vm-102-disk-0.qcow2' 528K
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating Proxmox Backup Server archive 'vm/102/2024-11-14T04:08:30Z'
INFO: issuing guest-agent 'fs-freeze' command
INFO: issuing guest-agent 'fs-thaw' command
INFO: started backup task 'da33aa74-4011-45dd-918e-0b4ef0a7a7b1'
INFO: resuming VM again
INFO: efidisk0: dirty-bitmap status: OK (drive clean)
INFO: scsi0: dirty-bitmap status: existing bitmap was invalid and has been cleared
INFO: using fast incremental mode (dirty-bitmap), 32.0 GiB dirty of 32.0 GiB total
INFO:   9% (3.1 GiB of 32.0 GiB) in 3s, read: 1.0 GiB/s, write: 62.7 MiB/s
INFO:  22% (7.3 GiB of 32.0 GiB) in 6s, read: 1.4 GiB/s, write: 25.3 MiB/s
INFO:  34% (11.0 GiB of 32.0 GiB) in 9s, read: 1.3 GiB/s, write: 36.0 MiB/s
INFO:  39% (12.7 GiB of 32.0 GiB) in 12s, read: 580.0 MiB/s, write: 20.0 MiB/s
INFO:  50% (16.2 GiB of 32.0 GiB) in 15s, read: 1.1 GiB/s, write: 17.3 MiB/s
INFO:  59% (19.1 GiB of 32.0 GiB) in 18s, read: 1009.3 MiB/s, write: 21.3 MiB/s
INFO:  75% (24.1 GiB of 32.0 GiB) in 21s, read: 1.7 GiB/s, write: 5.3 MiB/s
INFO:  92% (29.6 GiB of 32.0 GiB) in 24s, read: 1.8 GiB/s, write: 0 B/s
INFO: 100% (32.0 GiB of 32.0 GiB) in 26s, read: 1.2 GiB/s, write: 0 B/s
INFO: backup is sparse: 13.57 GiB (42%) total zero data
INFO: backup was done incrementally, reused 31.45 GiB (98%)
INFO: transferred 32.00 GiB in 26 seconds (1.2 GiB/s)
INFO: adding notes to backup
INFO: Finished Backup of VM 102 (00:00:35)
INFO: Backup finished at 2024-11-14 05:09:05
INFO: Starting Backup of VM 105 (lxc)
INFO: Backup started at 2024-11-14 05:09:05
INFO: status = running
INFO: CT Name: pihole
INFO: including mount point rootfs ('/') in backup
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
INFO: creating Proxmox Backup Server archive 'ct/105/2024-11-14T04:09:05Z'
INFO: set max number of entries in memory for file-based backups to 1048576
INFO: run: lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client backup --crypt-mode=none pct.conf:/var/tmp/vzdumptmp1651202_105/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 105 --backup-time 1731557345 --entries-max 1048576 --repository root@pam@192.168.1.80:nas
INFO: Starting backup: ct/105/2024-11-14T04:09:05Z
INFO: Client name: pve
INFO: Starting backup protocol: Thu Nov 14 05:09:09 2024
INFO: Downloading previous manifest (Wed Nov 13 04:55:23 2024)
INFO: Upload config file '/var/tmp/vzdumptmp1651202_105/etc/vzdump/pct.conf' to 'root@pam@192.168.1.80:8007:nas' as pct.conf.blob
INFO: Upload directory '/mnt/vzsnap0' to 'root@pam@192.168.1.80:8007:nas' as root.pxar.didx
INFO: root.pxar: had to backup 107.849 MiB of 1.752 GiB (compressed 20.754 MiB) in 8.12 s (average 13.277 MiB/s)
INFO: root.pxar: backup was done incrementally, reused 1.647 GiB (94.0%)
INFO: Uploaded backup catalog (621.828 KiB)
INFO: Duration: 8.35s
INFO: End Time: Thu Nov 14 05:09:18 2024
INFO: adding notes to backup
INFO: cleanup temporary 'vzdump' snapshot
INFO: Finished Backup of VM 105 (00:00:13)
INFO: Backup finished at 2024-11-14 05:09:18
INFO: Backup job finished successfully
TASK OK

 

[dakralex]

Zusätzlich zu meiner obigen Frage bezüglich Hardware und Backup Fleecing (obwohl hier relativ viel zusätzlicher Speicher benötigt werden würde, da die Disk images relativ groß sind), wie wurde der Proxmox Backup Server aufgesetzt (VM, eigene Node)? Wie sind das PVE und das PVE verbunden?

 

[mabox]

Oh sorry, vergessen
Also der Backup Server läuft halt "nur" im Moment als VM auf einer Synology NAS DS920+ (Intel Celeron CPU, 20GB RAM).
Die Daten von meiner PVE Hardware:
CPU 12 x AMD Ryzen 5 5600G
RAM 64GB
SSD 7TB Kingston DC600M (wo die VM drauf ist), PVE selbst ist auf einer eigenen 500 TB SSD

Verbunden sind die beiden über LAN.

 

[Falk R.]

Dann muss es ja langsam laufen. Der PBS ist durch sein Design (Dedup) optimalerweise mit SSDs zu bestücken. Geht auch mit HDDs, aber dann mit Delay bei den VMs während des Backups und Jobs wie Verify laufen sehr lang. Restoreperformance ist dann auch nicht so doll. Als VM auf einem NAS läuft der PBS noch langsamer. Auch wenn der PBS nicht extrem CPU hungrig ist, braucht Disk I/O auch etwas CPU Performance. Wenn du eine so große VM hast und den PBS maximal langsam, dann ist das nicht verwunderlich.
Was mich auch wundert, du hast da mehrere 1,5TB qcow Disks in der VM. Liegen die Disks zufällig auch auf einem NAS oder warum nutzt du qcow? Hoffentlich hast du in der VM kein RAID oder ZFS über die Disks gebaut, dann wäre auch das Phänomen beim Snapshot völlig normal.

 

[mabox]

@dakralex , @Falk R. Danke für Eure Infos!
Also wenn das ganze Erklärbar ist ist es völlig ok für mich und ich weiß ja dann was ich ändern müsste. Mit der Situation wie jetzt kann ich auch leben, ist alles nicht so dramatisch wichtig bei mir aber reizen tut es mich dann schon es irgendwann zu verbessern.

- Also in der VM selbst habe ich kein ZFS oder RAID, das ist einfach ein Standard Ubuntu drin.
- Wegen dem qcow Format bin ich verwirrt. Ich dachte das wäre nach meinen Recherchen damals das Richtige für meinen Einsatz und ich meine im raw Format war es nicht möglich einen Snapshot zu machen. Das war damals ausgegraut, daher bin ich auf qcow2 gewechselt.
- Die Disks von der VM liegen auf einer SSD 7TB Kingston DC600M.
- Es sind 4* 1,5TB Disks da ich in der VM mit LVM eine gestripte LV darüber gelegt habe. Dachte das bringt ein klein wenig mehr Performance.


EDIT: Kaum schreib ich hier hat das inkrementielle Backup heute Nacht "nur" 38 Minuten gedauert . Die letzten Wochen waren es immer 4-5h.

 

[Falk R.]

Wie hast du deine SSD eingebunden? Mit Standard LVM-Thin Pool gehen auch Snapshots. Wenn du qcow2 nutzt, musst du ein Dateisystem nutzen statt einem Diskpool (Blockdevice) mit dem zusätzlichen Dateisystem hast du natürlich noch overhead. Das Stripe in der VM ist quasi ein Raid0, was bei HDDs tödlich wäre in der Konstellation.

 

[mabox]

In Summe habe ich 4 Disk verbaut, alle als ZFS:

[root@pve ~]# zpool status
  pool: hpool
 state: ONLINE
  scan: scrub repaired 0B in 07:19:35 with 0 errors on Sun Nov 10 07:43:36 2024
config:

    NAME                                 STATE     READ WRITE CKSUM
    hpool                                ONLINE       0     0     0
      ata-ST12000VN0008-2YS101_ZV70G6CG  ONLINE       0     0     0

errors: No known data errors

  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:02:40 with 0 errors on Sun Nov 10 00:26:42 2024
config:

    NAME                                                  STATE     READ WRITE CKSUM
    rpool                                                 ONLINE       0     0     0
      mirror-0                                            ONLINE       0     0     0
        ata-KINGSTON_SEDC600M480G_50026B728339A643-part3  ONLINE       0     0     0
        ata-KINGSTON_SEDC600M480G_50026B728339A640-part3  ONLINE       0     0     0

errors: No known data errors

  pool: spool
 state: ONLINE
  scan: scrub repaired 0B in 01:57:10 with 0 errors on Sun Nov 10 02:21:13 2024
config:

    NAME                                           STATE     READ WRITE CKSUM
    spool                                          ONLINE       0     0     0
      ata-KINGSTON_SEDC600M7680G_50026B7686AF94B5  ONLINE       0     0     0

errors: No known data errors

Hoffe das passt so, hatte ich eigentlich vor einiger Zeit auch hier so im Forum "besprochen".

Ich habe nur 2 VMs und 1 Containter die 24/7 laufen, alle anderen VMs sind nur zum "rumpspielen" manchmal an.
- "hpool" (HDD) sind die ganzen unwichtigen VMs zum rumspielen sowie ein paar sonstige Daten auf die ich z.B. per NFS zugreife.
- "spool" (SSD) Ist meine ganz wichtig VM, sollte immer funktionieren
- "rpool" (SSD) Ist PVE installiert und es läuft dort aktuell eine ganz kleine VM in "local (pve)" und ein Containter "local zfs (pve)"
Wobei ich im Moment nicht mehr zusammen bekomm was der Unterschied zwischen "local (pve)" und "local zfs (pve)" war.

Vermutlich ist es aber nicht optimal das auf den PVE SSDs auch eine VM und ein Containter mit drauf sind oder? Die müsste ich verschieben auf die HDD oder die andere SSD?

Meine "spool" VM ist ein Ubuntu mit EXT4 und eben den gestripten LVM. Das LVM wollte ich halt gerne um nicht gleich den ganzen Platz in der VM zu vergeben sondern wenn eine LV volläuft ich noch was in der VG habe und vergrößern könnte.

 

[UdoB]

"spool" (SSD) Ist meine ganz wichtig VM, sollte immer funktionieren

Dann würde ich sie auf den rpool legen, denn nur der ist momentan redundant ausgelegt. Auf eine einzelne SSD gehört meiner Meinung nach nur unwichtiges Zeug.

(( Je nachdem, welches Fehlerbild beim Sterben einer einzelnen SSD als am wahrscheinlichsten eingeschätzt wird, kann man mit "copies=2" dafür sorgen, dass jeweils eine Kopie auf demselben Datenträger abgelegt wird. Wenn nur der erste Block nicht mehr lesbar ist, hilft dies. Wenn die SSD aber komplett stirbt, hilft das natürlich nicht. Und aus Anwendungssicht halbieren sich natürlich die IOPS während sich der Stress für die SSD verdoppelt. Dies ist keine Empfehlung, nur eine weitere Option für Sonderfälle. ))

Vermutlich ist es aber nicht optimal das auf den PVE SSDs auch eine VM und ein Containter mit drauf sind oder?

Einerseits: ja, "best practice" trennt das Betriebssystem von Daten. Dann kann man beispielsweise das System neu installieren, ohne dass die Daten beschädigt werden. Bei kleinen Mini-PCs darf man aber meiner Meinung nach flexibel sein, weil es oft einfach nicht genug Anschlüsse gibt.

 

[Falk R.]

Hoffe das passt so, hatte ich eigentlich vor einiger Zeit auch hier so im Forum "besprochen".

Ich habe nur 2 VMs und 1 Containter die 24/7 laufen, alle anderen VMs sind nur zum "rumpspielen" manchmal an.
- "hpool" (HDD) sind die ganzen unwichtigen VMs zum rumspielen sowie ein paar sonstige Daten auf die ich z.B. per NFS zugreife.
- "spool" (SSD) Ist meine ganz wichtig VM, sollte immer funktionieren
- "rpool" (SSD) Ist PVE installiert und es läuft dort aktuell eine ganz kleine VM in "local (pve)" und ein Containter "local zfs (pve)"
Wobei ich im Moment nicht mehr zusammen bekomm was der Unterschied zwischen "local (pve)" und "local zfs (pve)" war.

Vermutlich ist es aber nicht optimal das auf den PVE SSDs auch eine VM und ein Containter mit drauf sind oder? Die müsste ich verschieben auf die HDD oder die andere SSD?

Meine "spool" VM ist ein Ubuntu mit EXT4 und eben den gestripten LVM. Das LVM wollte ich halt gerne um nicht gleich den ganzen Platz in der VM zu vergeben sondern wenn eine LV volläuft ich noch was in der VG habe und vergrößern könnte.

Da hat dir aber bestimmt keiner geraten auf dem ZFS Pool ein Dataset anzulegen und da die VM Disks als qcow2 drauf zu legen.
Wenn dann legt man die VM Disks direkt in den Pool ohne Dataset und dann sparst du dir das Dateisystem dazwischen. Der ZFS Pool supportet natürlich Snapshots. Wenn du RAW Dateien auf ein Dataset legst, kannst du natürlich nur das Dataset snapshoten.
WEnn du ZFS nutzt und machst in den VM Disks ein Stripeset, dann erhöhst du auch die Menge an Metadaten, welche im ZFSPoll aktualisiert werden müssen, was zu schlechterer Performance führt.
Wenn die VM so wichtig ist, wie schon von Udo erwähnt, auf einen mirrored Pool legen und dann direkt in den Pool ohne Dataset.

 

[mabox]

Oh je, dann befürchte ich das ich immer noch nicht alles verstanden habe mit Dataset usw. Mist :-(
Also wäre das Ziel eigentlich "raw" disk direkt in einem zfs pool und ich kann dann immer noch Snapshots über die Proxmox GUIs machen?

Denke irgendwo hab ich dann Konfigurationsfehler.
Wenn ich zu meiner VM eine Disk hinzufügen möchte kann ich als Storage nur "local-zfs" als "zfspool" auswählen.



Datasets sind dann vermutlich diese Type "dir"?
"hvm" ist meine HDD dahinter und bei "svm" meine SSD mit meiner wichtigsten VM. Also wenn ich es richtig verstehe brauch ich hier für svm auch die Auswahl "zfspool" um darin raw Disks abzulegen?

Wegen dem mirrored Pool für meine wichtige VM, ja da wollte ich im Moment noch ein wenig warten bis die SSD wieder wenigstens etwas günstiger wird. Bis dahin riskiere ich eben einige Zeit eine Downtime und stelle dann wieder über Restore her nachdem ich eine neue SSD beschafft habe :-(


EDIT:
Ok ich glaub ich habs wieder halbwegs kapiert, einfach schon wieder eine Weile her gewesen
Gerne würde ich es ja richtig machen bzw. was halt auch Sinn macht.
Die Frage ist jetzt wie.... Ich lege einfach in den "Datacenter" - "Storage" einen neuen ZFS Storage an der auf meiner SSD liegt und migriere später die Disks von meiner VM dorthin richtig? Ganz am Ende lösche ich den "Type" Directory wo jetzt "svm" heißt und migriere die qcow2 disks noch ins raw Format. Mehr dürfte es glaub nicht sein oder was denkt ihr?

 

[Falk R.]

EDIT:
Ok ich glaub ich habs wieder halbwegs kapiert, einfach schon wieder eine Weile her gewesen
Gerne würde ich es ja richtig machen bzw. was halt auch Sinn macht.
Die Frage ist jetzt wie.... Ich lege einfach in den "Datacenter" - "Storage" einen neuen ZFS Storage an der auf meiner SSD liegt und migriere später die Disks von meiner VM dorthin richtig? Ganz am Ende lösche ich den "Type" Directory wo jetzt "svm" heißt und migriere die qcow2 disks noch ins raw Format. Mehr dürfte es glaub nicht sein oder was denkt ihr?

Du brauchst nix neu anlegen, wenn du ein Dataset angelegt hast was du als Directory eingebunden hast, dann hast du ja schon einen Pool.
Binde den ZFS pool, wo das Dataset drin liegt, per ZFS Pool ein und migriere die VM Disk einfach.

Normal hast du das so: /ZFSPool/Dataset
Derzeit hast du das Dataset per Directory eingebunden.
Wenn du unter Datacenter > Storage > add einfach deinen ZFS Pool auswählst, einen Namen geben und am besten direkt Thin privisioning aktivieren.

 

[mabox]

In Ordnung und später wenn alles migriert ist dann noch die Disks in raw Format konvertieren und dann passt es soweit oder?
Eigentlich noch innerhalb meiner VM dann noch auf das LVM bzw. das Stripping verzichten wenn ich es richtig verstanden habe...

 

[Falk R.]

In Ordnung und später wenn alles migriert ist dann noch die Disks in raw Format konvertieren und dann passt es soweit oder?

Wenn du in der GUI migrierst, kannst du im ZFS pool nur RAW nutzen. Dann ist alles so wie gewünscht.

Eigentlich noch innerhalb meiner VM dann noch auf das LVM bzw. das Stripping verzichten wenn ich es richtig verstanden habe...

Das wäre noch besser, aber merk dir das für die nächste VM.

 

[waltar]

Der zfs Experte JIm Salter zieht qcow den zvols vor, weil https://jrs-s.net/2018/03/13/zvol-vs-qcow2-with-kvm/

 

[mabox]

Oh je, das hiese also widerum meine jetzige Konfiguration wäre in Ordnung lt. Jim Salter?

@Falk R. Mich hätte noch interessiert wegen LVM.... ist das LVM ansich blöd oder "nur" das Stripping was die Performance angeht? Was denkst Du den was es so ungefähr an Performance ausmacht in Zahlen ob .qcow2 mit Datastet (und LVM in der VM) vs raw in zfs pool?

 

[Falk R.]

Der zfs Experte JIm Salter zieht qcow den zvols vor, weil https://jrs-s.net/2018/03/13/zvol-vs-qcow2-with-kvm/

Der Benchmark ist schon ganz schön alt und ist immer mit Cache. Ich denke der Cache hat da geholfen.
Ich habe zwar noch nie das Setup mit qcow auf ZFS genutzt, da man dann die Replikation einbüßt, aber die Performance war immer Top mit NVMe Disks. Trotz ZFS bin ich fast auf Herstellerangaben bei Benchmarks gekommen.

 

[Falk R.]

Das LVM ist kein Problem sondern das Striping macht auch aus jedem I/O, 100% Random.
Striping bringt nur etwas wenn man echte getrennte Datenträger hat.

 

[mabox]

Ich habe zwar noch nie das Setup mit qcow auf ZFS genutzt, da man dann die Replikation einbüßt, aber die Performance war immer Top mit NVMe Disks.

Nur zur Sicherheit, hier meinst Du die Performance in einem ZFS Pool mit raw disks ja?
Kann ich den irgendwie prüfen wie aktuell meine Performance im Moment ist um irgendwie einen Anhaltspunkt zu bekommen wie gut oder schlecht sie ist?