Backup auf Synology - Job bricht ab

J

jhecht

New Member
Oct 2, 2024
5
1
3
Hallo,
vielleicht kann mir da jemand weiterhelfen. Ich habe keinen ANsatz wie ich auf das Problem kommen könnte.

Ich erste aus meiner PVE (9.0.3) ein Bachup auf meine eingebundene Synology. Das passiert auch nicht immer bei der gleichen VM. Mal die und mal eine andere. Das ist das entsprechende Log von heute Nacht.


INFO: starting new backup job: vzdump 102 --notification-mode notification-system --storage Synology-Backup --notes-template '{{guestname}}' --fleecing 0 --compress zstd --prune-backups 'keep-last=1' --mode snapshot --quiet 1
INFO: Starting Backup of VM 102 (qemu)
INFO: Backup started at 2025-10-30 00:00:12
INFO: status = running
INFO: VM Name: DC2
INFO: include disk 'scsi0' 'ssd1_0_1:102/vm-102-disk-1.qcow2' 150G
INFO: include disk 'scsi1' 'ssd1_0_1:102/vm-102-disk-2.qcow2' 700G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating vzdump archive '/mnt/pve/Synology-Backup/dump/vzdump-qemu-102-2025_10_30-00_00_12.vma.zst'
INFO: started backup task '7e6ad44a-ca2d-4b5a-8420-3fdadd83839f'
INFO: resuming VM again
INFO: 0% (837.4 MiB of 850.0 GiB) in 3s, read: 279.1 MiB/s, write: 255.0 MiB/s
INFO: 1% (8.6 GiB of 850.0 GiB) in 44s, read: 195.6 MiB/s, write: 195.1 MiB/s
INFO: 2% (17.1 GiB of 850.0 GiB) in 1m 30s, read: 187.5 MiB/s, write: 187.5 MiB/s

....
....

INFO: 92% (782.1 GiB of 850.0 GiB) in 47m 40s, read: 93.2 MiB/s, write: 93.2 MiB/s
INFO: 93% (790.5 GiB of 850.0 GiB) in 49m 10s, read: 96.0 MiB/s, write: 95.9 MiB/s
zstd: error 70 : Write error : cannot write block : Bad address
INFO: 93% (798.7 GiB of 850.0 GiB) in 50m 34s, read: 100.3 MiB/s, write: 100.3 MiB/s
ERROR: vma_queue_write: write error - Broken pipe
INFO: aborting backup job
INFO: resuming VM again
ERROR: Backup of VM 102 failed - vma_queue_write: write error - Broken pipe
INFO: Failed at 2025-10-30 00:50:49
INFO: Backup job finished with errors
INFO: notified via target `mail-to-root`
TASK ERROR: job errors


Wie kann ich das Problem den angehen?

Vielen Dank für eure Hilfe
 
jhecht said:
zstd: error 70 : Write error : cannot write block : Bad address
...
ERROR: vma_queue_write: write error - Broken pipe
Click to expand...
Defekter Speicher? Zu wenig freier Platz? Obwohl da eher "no space left on device" als Fehler auftauchen sollte.
 
also den bad adress error von zstd beobachte ich auch gelegetlich, aber defekter speicher ist da eher sehr unwahrscheinlich, da ich es in unserem 3er cluster jetzt im juni auf allen 3 nodes hatte. ziel ist ein debian backupsystem mit zfs und samba, anbindung über 10gbit.
keine errors im kernel log
 
Das zstd: error 70 : Bad address + Broken pipe bei Backups auf SMB-Shares seh ich immer wieder, besonders bei großen VMs die lange durchschreiben. Bei dir sind das 850 GB, da schreibt vzdump fast eine Stunde am Stück auf den SMB-Mount. Irgendwann bricht die Verbindung weg.

SMB ist für vzdump-Backups generell eher wackelig. Würde mich @Stubennerd anschließen: bind die Synology mal testweise per NFS ein. Das ist für PVE-Backup-Storage robuster. Auf der Synology musst du dafür unter Systemsteuerung → Dateidienste → NFS aktivieren und dann beim Shared Folder die NFS-Berechtigung für den PVE-Host freigeben. In PVE dann als Storage-Typ "NFS" statt "CIFS" hinzufügen.

Falls du aus irgendeinem Grund bei SMB bleiben willst/musst: check mal welche SMB-Version gemountet wird (mount | grep Synology) und ob in den Mount-Optionen was wie vers=3.0 oder vers=3.1.1 steht. Manchmal hilft auch ein größerer rsize/wsize oder ein explizites vers=3.0 falls 3.1.1 Probleme macht. Aber ehrlich gesagt ist NFS hier der bessere Weg.
 
also dafür das samba/cifs ständig als enterprise ready ablöse für nfs gehandelt und kommuniziert wird find ich das jetzt auch etwas enttäschend, wenn das tatsächlich an samba liegt. aber seit dem letzten kernel update hab ich auch immer wieder errors im dmesg die auf cifs und timeout probleme hindeuten.

ich mag aber irgendwie nicht wieder zurück auf nfs. schon allein weil es nicht ordentlich containerisierbar ist'

ich versuchs jetzt erstmal mit protokoll downgrade auf 3.0
 
Die dmesg-Meldungen wären mal interessant, kannst du die posten? Wenn da CIFS-Timeouts drinstehen, probier neben dem Downgrade auf 3.0 auch mal echo_interval=10 als Mount-Option. Das schickt häufiger Keepalives, die Connection bleibt bei langen Writes stabiler. Default ist 60 Sekunden, das ist bei 800+ GB Backups die da ne Stunde durchschreiben manchmal zu wenig.

Kann den Frust mit SMB verstehen, btw. Containerisierbarkeit ist halt ein Argument. Aber vzdump schreibt eine einzelne riesige Datei sequentiell weg, das ist genau das Szenario wo CIFS am ehesten zickt.
 
i'm getting messages like these:

Code: 
[  494.893538] INFO: task zstd:6375 blocked for more than 122 seconds.
[  494.893812]       Tainted: P S         O        7.0.6-2-pve #1
[  494.894008] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  494.894250] task:zstd            state:D stack:0     pid:6375  tgid:6375  ppid:6342   task_flags:0x400000 flags:0x00080000
[  494.896403] Call Trace:
[  494.896803]  <TASK>
[  494.897122]  __schedule+0x495/0x1760
[  494.897478]  ? mod_memcg_lruvec_state+0xd7/0x1f0
[  494.897857]  schedule+0x27/0xf0
[  494.898184]  schedule_preempt_disabled+0x15/0x30
[  494.898533]  __mutex_lock.constprop.0+0x54c/0xaf0
[  494.898929]  ? __xa_set_mark+0x66/0x90
[  494.899260]  __mutex_lock_slowpath+0x13/0x20
[  494.899679]  mutex_lock+0x3b/0x50
[  494.900090]  netfs_writepages+0x96/0x420 [netfs]
[  494.900515]  do_writepages+0xc4/0x180
[  494.900940]  filemap_writeback+0xd1/0x100
[  494.901315]  filemap_write_and_wait_range+0x5e/0x140
[  494.901645]  cifs_flush+0x91/0x140 [cifs]
[  494.902206]  filp_flush+0x3f/0xb0
[  494.902527]  __x64_sys_close+0x33/0x90
[  494.902864]  x64_sys_call+0x1718/0x2390
[  494.903198]  do_syscall_64+0x10b/0x14e0
[  494.903554]  ? rw_verify_area+0x57/0x190
[  494.903883]  ? vfs_write+0x274/0x490
[  494.904264]  ? ksys_write+0xd9/0xf0
[  494.904583]  ? __x64_sys_write+0x19/0x30
[  494.904934]  ? x64_sys_call+0x22f/0x2390
[  494.905253]  ? do_syscall_64+0x148/0x14e0
[  494.905621]  ? __x64_sys_clock_gettime+0xa4/0xe0
[  494.905981]  ? x64_sys_call+0x121b/0x2390
[  494.906329]  ? do_syscall_64+0x148/0x14e0
[  494.906617]  ? do_syscall_64+0x300/0x14e0
[  494.907004]  ? do_syscall_64+0x300/0x14e0
[  494.907309]  ? do_syscall_64+0x148/0x14e0
[  494.907596]  ? x64_sys_call+0x198e/0x2390
[  494.907931]  ? do_syscall_64+0x148/0x14e0
[  494.908252]  ? do_syscall_64+0x148/0x14e0
[  494.908535]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  494.908877] RIP: 0033:0x7ce13d3f5987
[  494.909189] RSP: 002b:00007ffc10a6a478 EFLAGS: 00000297 ORIG_RAX: 0000000000000003
[  494.909427] RAX: ffffffffffffffda RBX: 00007ce13d4d75c0 RCX: 00007ce13d3f5987
[  494.909730] RDX: 00007ce13d4d4ee0 RSI: 0000000000000000 RDI: 0000000000000001
[  494.910076] RBP: 00007ce13d4d5030 R08: 0000000000000000 R09: 0000000000000000
[  494.910368] R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000
[  494.910699] R13: 0000000000000000 R14: 0000000580f3c600 R15: 000063d85c7ef018
[  494.911040]  </TASK>


i have set the following options for cifs


options soft,noserverino,x-systemd.device-timeout=10,echo_interval=10,cache=strict,vers=3.0
 
Last edited:
OK das bestätigt's. Der zstd-Prozess hängt 122+ Sekunden in netfs_writepages → cifs_flush, also beim Rausschreiben der gecachten Daten auf den CIFS-Mount. Das ist eine Blockade im Writeback-Pfad.

Dein cache=strict ist hier vermutlich ein großer Teil des Problems. Bei vzdump schreibst du hunderte GB sequentiell, die landen erstmal im Page Cache und werden dann in großen Batches zum Server geflusht. Wenn der Flush nicht schnell genug durchkommt, stauen sich die Dirty Pages und der Kernel blockt den schreibenden Prozess. Probier mal cache=none statt cache=strict, dann gehen die Writes direkt zum Server ohne den Page-Cache-Umweg. Für vzdump (eine große Datei, rein sequentiell) ist das eh sinnvoller.

Der Kernel 7.0.6-2-pve nutzt das neuere netfs-Subsystem für CIFS-Writeback, da gabs in den letzten Versionen immer wieder Probleme mit genau solchen Mutex-Hangs bei großen Writes. Kann gut sein dass da mit einem zukünftigen Kernel-Update was besser wird, aber cache=none sollte den Codepfad erstmal umgehen.
 
danke @Bu66as , superguter tip.

da cache=none die schreib performance sehr stark negativ beeinflussen dürfte möchte ich jetzt zuerst mal sehen, ob runtersetzen von zfs_dirty_data_max um faktor 10 auf dem backupserver was bringt , könnte mir vorstellen daß das damit ggf. auch zu tun hat https://github.com/openzfs/zfs/issues/10110

erklärt aber auch noch nicht wirklich, warum es früher nie aufgetreten ist, aber der backup-server hatte letztens auch ein update, so wie die proxmox server....

ich glaube aber auch, daß das mit den netfs changes zu tun hat, da war ich auch schon drauf gestossen.
 
You must log in or register to reply here.
Top Bottom
Back