Backup auf PBS schlägt mit Fehler "job failed with err -61 - No data available" fehl

[djdonnerwolke]

Guten Morgen,

seit einer Woche schlägt das Backup genau einer VM fehl, während andere VMs und LXC Container weg gesichert werden.

Der Fehler sieht folgendermaßen aus:

Details
VMID     Name     Status     Time     Size     Filename
110     sv10-docker02     err     15s     0 B     null
Total running time: 15s
Total size: 0 B
Logs

vzdump 110 --node vhost04 --notification-mode auto --remove 0 --notes-template '{{guestname}}' --storage pbs_int-vm --mode suspend


110: 2025-03-12 08:07:51 INFO: Starting Backup of VM 110 (qemu)
110: 2025-03-12 08:07:51 INFO: status = running
110: 2025-03-12 08:07:51 INFO: backup mode: suspend
110: 2025-03-12 08:07:51 INFO: ionice priority: 7
110: 2025-03-12 08:07:51 INFO: VM Name: sv10-docker02
110: 2025-03-12 08:07:51 INFO: include disk 'scsi0' 'vmdata1:110/vm-110-disk-1.qcow2' 44544M
110: 2025-03-12 08:07:51 INFO: include disk 'scsi1' 'vmdata1:110/vm-110-disk-2.qcow2' 512G
110: 2025-03-12 08:07:51 INFO: include disk 'efidisk0' 'vmdata1:110/vm-110-disk-0.qcow2' 4M
110: 2025-03-12 08:07:51 INFO: suspending guest
110: 2025-03-12 08:07:52 INFO: creating Proxmox Backup Server archive 'vm/110/2025-03-12T07:07:51Z'
110: 2025-03-12 08:07:55 INFO: skipping guest-agent 'fs-freeze', agent configured but not running?
110: 2025-03-12 08:07:55 INFO: started backup task 'e4d95ab0-7e38-46eb-9cd5-d77c8bc2ba0c'
110: 2025-03-12 08:07:55 INFO: resuming VM again after 4 seconds
110: 2025-03-12 08:07:55 INFO: efidisk0: dirty-bitmap status: OK (drive clean)
110: 2025-03-12 08:07:55 INFO: scsi0: dirty-bitmap status: OK (9.3 GiB of 43.5 GiB dirty)
110: 2025-03-12 08:07:55 INFO: scsi1: dirty-bitmap status: existing bitmap was invalid and has been cleared
110: 2025-03-12 08:07:55 INFO: using fast incremental mode (dirty-bitmap), 521.3 GiB dirty of 555.5 GiB total
110: 2025-03-12 08:07:58 INFO:   0% (2.9 GiB of 521.3 GiB) in 3s, read: 989.3 MiB/s, write: 157.3 MiB/s
110: 2025-03-12 08:08:01 INFO:   1% (7.2 GiB of 521.3 GiB) in 6s, read: 1.4 GiB/s, write: 76.0 MiB/s
110: 2025-03-12 08:08:04 INFO:   2% (11.4 GiB of 521.3 GiB) in 9s, read: 1.4 GiB/s, write: 46.7 MiB/s
110: 2025-03-12 08:08:05 INFO:   2% (11.4 GiB of 521.3 GiB) in 10s, read: 4.0 MiB/s, write: 0 B/s
110: 2025-03-12 08:08:05 ERROR: job failed with err -61 - No data available
110: 2025-03-12 08:08:05 INFO: aborting backup job
110: 2025-03-12 08:08:05 INFO: resuming VM again
110: 2025-03-12 08:08:05 INFO: resume vm
110: 2025-03-12 08:08:06 ERROR: Backup of VM 110 failed - job failed with err -61 - No data available

Ich sichere meine VMs per ProxmoxBackupServer weg.
Der PBS läuft in der Version 3.3.3 und ist per SMB an einen Storage angebunden.





Andere VMs werden regulär weg gesichert, weshalb ich verwirrt darüber bin, dass es eben bei dieser einen VM nicht funktioniert.
Ich würde behaupten, dass diese VM mit der ID 110 mit eine der größten VMs ist, die ich habe.
Ich habe letzte Woche eine Partition auf dieser VM um noch mal 16 GB erhöht (was ich schon oft gemacht habe, also nichts ungewöhnliches).

Ansonsten fällt mir erst mal nichts ein.
Auf dieser VM laufen nur Docker Container.
Hat jemand eine Idee?

Vielen Dank, Patrick

 

[dakralex]

Hi!

Könntest du einen Auszug von dem Syslog (dmesg/journalctl --system) posten während das Backup dieser VM fehlschlägt? Eine Vermutung wäre, dass es zu Lesefehlern an der Quelle gekommen ist, aber der Syslog würde mehr Information geben.

 

[ByteArchitect]

Guten Morgen,

seit einer Woche schlägt das Backup genau einer VM fehl, während andere VMs und LXC Container weg gesichert werden.

Der Fehler sieht folgendermaßen aus:

Details
VMID     Name     Status     Time     Size     Filename
110     sv10-docker02     err     15s     0 B     null
Total running time: 15s
Total size: 0 B
Logs

vzdump 110 --node vhost04 --notification-mode auto --remove 0 --notes-template '{{guestname}}' --storage pbs_int-vm --mode suspend


110: 2025-03-12 08:07:51 INFO: Starting Backup of VM 110 (qemu)
110: 2025-03-12 08:07:51 INFO: status = running
110: 2025-03-12 08:07:51 INFO: backup mode: suspend
110: 2025-03-12 08:07:51 INFO: ionice priority: 7
110: 2025-03-12 08:07:51 INFO: VM Name: sv10-docker02
110: 2025-03-12 08:07:51 INFO: include disk 'scsi0' 'vmdata1:110/vm-110-disk-1.qcow2' 44544M
110: 2025-03-12 08:07:51 INFO: include disk 'scsi1' 'vmdata1:110/vm-110-disk-2.qcow2' 512G
110: 2025-03-12 08:07:51 INFO: include disk 'efidisk0' 'vmdata1:110/vm-110-disk-0.qcow2' 4M
110: 2025-03-12 08:07:51 INFO: suspending guest
110: 2025-03-12 08:07:52 INFO: creating Proxmox Backup Server archive 'vm/110/2025-03-12T07:07:51Z'
110: 2025-03-12 08:07:55 INFO: skipping guest-agent 'fs-freeze', agent configured but not running?
110: 2025-03-12 08:07:55 INFO: started backup task 'e4d95ab0-7e38-46eb-9cd5-d77c8bc2ba0c'
110: 2025-03-12 08:07:55 INFO: resuming VM again after 4 seconds
110: 2025-03-12 08:07:55 INFO: efidisk0: dirty-bitmap status: OK (drive clean)
110: 2025-03-12 08:07:55 INFO: scsi0: dirty-bitmap status: OK (9.3 GiB of 43.5 GiB dirty)
110: 2025-03-12 08:07:55 INFO: scsi1: dirty-bitmap status: existing bitmap was invalid and has been cleared
110: 2025-03-12 08:07:55 INFO: using fast incremental mode (dirty-bitmap), 521.3 GiB dirty of 555.5 GiB total
110: 2025-03-12 08:07:58 INFO:   0% (2.9 GiB of 521.3 GiB) in 3s, read: 989.3 MiB/s, write: 157.3 MiB/s
110: 2025-03-12 08:08:01 INFO:   1% (7.2 GiB of 521.3 GiB) in 6s, read: 1.4 GiB/s, write: 76.0 MiB/s
110: 2025-03-12 08:08:04 INFO:   2% (11.4 GiB of 521.3 GiB) in 9s, read: 1.4 GiB/s, write: 46.7 MiB/s
110: 2025-03-12 08:08:05 INFO:   2% (11.4 GiB of 521.3 GiB) in 10s, read: 4.0 MiB/s, write: 0 B/s
110: 2025-03-12 08:08:05 ERROR: job failed with err -61 - No data available
110: 2025-03-12 08:08:05 INFO: aborting backup job
110: 2025-03-12 08:08:05 INFO: resuming VM again
110: 2025-03-12 08:08:05 INFO: resume vm
110: 2025-03-12 08:08:06 ERROR: Backup of VM 110 failed - job failed with err -61 - No data available

Ich sichere meine VMs per ProxmoxBackupServer weg.
Der PBS läuft in der Version 3.3.3 und ist per SMB an einen Storage angebunden.

View attachment 83569

View attachment 83568

Andere VMs werden regulär weg gesichert, weshalb ich verwirrt darüber bin, dass es eben bei dieser einen VM nicht funktioniert.
Ich würde behaupten, dass diese VM mit der ID 110 mit eine der größten VMs ist, die ich habe.
Ich habe letzte Woche eine Partition auf dieser VM um noch mal 16 GB erhöht (was ich schon oft gemacht habe, also nichts ungewöhnliches).

Ansonsten fällt mir erst mal nichts ein.
Auf dieser VM laufen nur Docker Container.
Hat jemand eine Idee?

Vielen Dank, Patrick

Nur aus Interesse: Ich vermute, du betreibst deinen PBS auf deinem Proxmox Cluster und hast, wie du bereits gesagt hast, den Storage via SMB angebunden. Läuft das ohne Probleme, oder gibt es etwas zu beachten?
Ich plane, in den nächsten Tagen ebenfalls eine VM auf meinem HA-Cluster dafür zu erstellen und ein Backup auf ein SMB Share zu speichern. Mich wundert allerdings, dass 2 Kerne und 2 GB RAM ausreichen, ist der PBS wirklich so ressourcensparend?

 

[djdonnerwolke]

Könntest du einen Auszug von dem Syslog (dmesg/journalctl --system) posten während das Backup dieser VM fehlschlägt?

Vielen Dank für deine Rückmeldung!

Folgendes Log kann ich dir anbieten:

Mär 12 11:37:07 vhost04 pvedaemon[1245]: <root@pam> starting task UPID:vhost04:0000587E:0002452F:67D163D3:vzdump:110:root@pam:
Mär 12 11:37:07 vhost04 pvedaemon[22654]: INFO: starting new backup job: vzdump 110 --remove 0 --mode suspend --notes-template '{{guestname}}' --notification-mode auto --node vhost04 --storage pbs_int-vm
Mär 12 11:37:07 vhost04 pvedaemon[22654]: INFO: Starting Backup of VM 110 (qemu)
Mär 12 11:37:08 vhost04 qm[22674]: <root@pam> starting task UPID:vhost04:00005893:00024583:67D163D4:qmpause:110:root@pam:
Mär 12 11:37:08 vhost04 qm[22675]: suspend VM 110: UPID:vhost04:00005893:00024583:67D163D4:qmpause:110:root@pam:
Mär 12 11:37:08 vhost04 qm[22674]: <root@pam> end task UPID:vhost04:00005893:00024583:67D163D4:qmpause:110:root@pam: OK
Mär 12 11:37:11 vhost04 pvedaemon[22654]: VM 110 qmp command failed - VM 110 qmp command 'guest-ping' failed - got timeout
Mär 12 11:37:21 vhost04 kernel: nvme0n1: I/O Cmd(0x2) @ LBA 587811424, 256 blocks, I/O Error (sct 0x2 / sc 0x81) MORE
Mär 12 11:37:21 vhost04 kernel: critical medium error, dev nvme0n1, sector 587811424 op 0x0:(READ) flags 0x4000 phys_seg 16 prio class 0
Mär 12 11:37:22 vhost04 qm[22964]: <root@pam> starting task UPID:vhost04:000059BD:00024B0C:67D163E2:qmresume:110:root@pam:
Mär 12 11:37:22 vhost04 qm[22973]: resume VM 110: UPID:vhost04:000059BD:00024B0C:67D163E2:qmresume:110:root@pam:
Mär 12 11:37:22 vhost04 qm[22964]: <root@pam> end task UPID:vhost04:000059BD:00024B0C:67D163E2:qmresume:110:root@pam: OK
Mär 12 11:37:22 vhost04 pvedaemon[22654]: ERROR: Backup of VM 110 failed - job failed with err -61 - No data available
Mär 12 11:37:22 vhost04 pvedaemon[22654]: INFO: Backup job finished with errors
Mär 12 11:37:22 vhost04 perl[22654]: notified via target `mail-to-root`
Mär 12 11:37:22 vhost04 pvedaemon[22654]: job errors
Mär 12 11:37:22 vhost04 postfix/pickup[1076]: CDAE520ED5: uid=0 from=<noreply@techniverse.net>
Mär 12 11:37:22 vhost04 pvedaemon[1245]: <root@pam> end task UPID:vhost04:0000587E:0002452F:67D163D3:vzdump:110:root@pam: job errors

Was ich da lese, gefällt mir absolut garnicht. Meine Nvme? Das ist die Nvme, auf der u.a. meine VMs liegen.

sudo smartctl -a /dev/nvme0n1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-8-pve] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       TEAM TM8FP6002T
Serial Number:                      TPBF2310170070600482
Firmware Version:                   APF1M3R1
PCI Vendor/Subsystem ID:            0x1ed0
IEEE OUI Identifier:                0x2c3ebf
Total NVM Capacity:                 2.048.408.248.320 [2,04 TB]
Unallocated NVM Capacity:           0
Controller ID:                      1
NVMe Version:                       1.3
Number of Namespaces:               1
Namespace 1 Size/Capacity:          2.048.408.248.320 [2,04 TB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            2c3ebf fff00001e2
Local Time is:                      Wed Mar 12 11:42:42 2025 CET
Firmware Updates (0x12):            1 Slot, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x0056):     Wr_Unc DS_Mngmt Sav/Sel_Feat Timestmp
Log Page Attributes (0x0a):         Cmd_Eff_Lg Telmtry_Lg
Maximum Data Transfer Size:         256 Pages
Warning  Comp. Temp. Threshold:     80 Celsius
Critical Comp. Temp. Threshold:     85 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     3.50W       -        -    0  0  0  0        0       0
 1 +     1.90W       -        -    1  1  1  1        0       0
 2 +     1.50W       -        -    2  2  2  2        0       0
 3 -   0.0700W       -        -    3  3  3  3     1000    1000
 4 -   0.0050W       -        -    4  4  4  4     5000   45000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         1
 1 -    4096       0         0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        47 Celsius
Available Spare:                    100%
Available Spare Threshold:          5%
Percentage Used:                    5%
Data Units Read:                    158.795.647 [81,3 TB]
Data Units Written:                 113.391.773 [58,0 TB]
Host Read Commands:                 974.673.698
Host Write Commands:                3.154.583.639
Controller Busy Time:               16.033
Power Cycles:                       29
Power On Hours:                     6.497
Unsafe Shutdowns:                   17
Media and Data Integrity Errors:    59
Error Information Log Entries:      59
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               68 Celsius
Thermal Temp. 1 Transition Count:   3
Thermal Temp. 1 Total Time:         1629

Error Information (NVMe Log 0x01, 16 of 16 entries)
Num   ErrCount  SQId   CmdId  Status  PELoc          LBA  NSID    VS
  0         59     6  0x91a9  0x4502      -    587811656     1     -
  1         58     6  0x81a9  0x4502      -    587811656     1     -
  2         57     6  0x71a9  0x4502      -    587811656     1     -
  3         56     6  0x61a9  0x4502      -    587811656     1     -
  4         55     6  0x51a9  0x4502      -    587811656     1     -
  5         54     6  0x41a9  0x4502      -    587811656     1     -
  6         53     1  0x43bc  0x4502      -    587811656     1     -
  7         52     1  0x33bc  0x4502      -    587811656     1     -
  8         51     1  0x23bc  0x4502      -    587811656     1     -
  9         50     1  0x13bc  0x4502      -    587811656     1     -
 10         49     1  0x03bc  0x4503      -    587811656     1     -
 11         48     1  0xf3bc  0x4503      -    587811656     1     -
 12         47     4  0xc2d3  0x4503      -    587811656     1     -
 13         46     4  0xb2d3  0x4503      -    587811656     1     -
 14         45     4  0xa2d3  0x4503      -    587811656     1     -
 15         44     4  0x92d3  0x4503      -    587811656     1     -

Nichts desto trotz wird mir die Nvme als "Passed" im System angezeigt.



Was hat das zu bedeuten?

Grüße und Danke.

 

[djdonnerwolke]

Nur aus Interesse: Ich vermute, du betreibst deinen PBS auf deinem Proxmox Cluster und hast, wie du bereits gesagt hast, den Storage via SMB angebunden. Läuft das ohne Probleme, oder gibt es etwas zu beachten?
Ich plane, in den nächsten Tagen ebenfalls eine VM auf meinem HA-Cluster dafür zu erstellen und ein Backup auf ein SMB Share zu speichern. Mich wundert allerdings, dass 2 Kerne und 2 GB RAM ausreichen, ist der PBS wirklich so ressourcensparend?

Hallo,

Ja, ich betreibe den PBS auf einem Proxmos-Host.
Für mich bisher war das völlig ausreichend. Meine Infra ist aber auch nicht so riesig, wie du vielleicht sehen kannst.





Ich denke der Flaschenhals wird das SMB sein. Da ich aber ohnehin nur eine Gigabit Umgebung habe und meine Maschinen aktuell nicht mehr hergeben, ist das für mich ausreichend. Wenn du die Möglichkeit hast, geh auf NFS.

 

[dakralex]

Nichts desto trotz wird mir die Nvme als "Passed" im System angezeigt.

Das tut mir leid zu hören, jedoch muss der Fehler nicht zwingend fatal sein.

Wenn SMART "PASSED" meldet, bedeutet dass das das NVMe insgesamt in einem guten Zustand ist. Das kann aber trotzdem bedeuten, dass es einen Bad Block [0] auf dem Speichermedium geben kann, was aber relativ normal ist (z.B. bei einem Stromausfall, oder SSD Wear). Normalerweise wird bei einem Bad Block ein neuer Block alloziert. In diesem Fall konnte aber der Block kein einziges Mal gelesen werden und deswegen hält sich die Firmware des NVMe quasi offen, dass zu einem späteren Zeitpunkt dieser Block noch gelesen werden kann und dann in einen neuen Block geschrieben wird [1].

Wie der verlinkte Artikel auch beschreibt, kann das Allozierien eines neuen Blocks jedoch auch erzwungen werden, siehe [2].

[0] Ich schreibe hier Block (Filesystem-Ebene), aber SMART arbeitet auf Sektorebene (Speicherebene).
[1] https://www.smartmontools.org/wiki/...estsbutSMARThealthstatusisPASSED.Whatsgoingon
[2] https://www.smartmontools.org/wiki/BadBlockHowto

 

[djdonnerwolke]

Wie der verlinkte Artikel auch beschreibt, kann das Allozierien eines neuen Blocks jedoch auch erzwungen werden, siehe [2].

Ich werde heute Abend meinen alten vhost einschalten und dort die Backups wiederherstellen.
Zum Glück ist es nur eine VM, bei der es aktuell Problematisch ist und ich denke auch, dass dort die defekten Sektoren liegen.
Blöd nur, dass das meine größte VM ist und dort viele meiner Services laufen (inkl. Matrix Synapse)

Anschließend werde ich mich deinen verlinkten Seiten annehmen und mal anschauen, was das Problem ist.

Ich melde mich final noch mal hier im Forum.