KVM Backup Abbruch und Buffer I/O error - reproduzierbar

Oliver_T

Active Member
May 9, 2017
10
0
41
Hallo,

wir haben seit dem Upgrade bzw. der Nutzung von Proxmox VE 7 ein etwas unschönes Problem. Wenn ein laufendes Backup abbricht, sei es durch einen Fehler auf der NFS Storage oder bei unserem anschließenden Test mit dem Abschiessen des Backupvorganges, wird die VM unnutzbar, remountet read-only und muss mit einem Filecheck zum Leben erweckt werden.

Dieses Problem hatte wir bis Proxmox VE 6 in der Form nicht, gibt es da bereits Lösungansätze bzw. wurde das gemeldet ?

Fehler die dann auf der VM auftreten:
print_req_error: I/O error, dev vda, sector xxxxx
Buffer I/O error on device vda1, logical block xxxxx
Aborting journal on device vda1-8
Remounting filesystem read-only
EXT4-fs error (device vda1): ext4_journal_check_start

Wochenendliche Grüße,
Oliver


Nachtrag 17.10.2021
Gerade habe ich ein System migriert, Plesk Migrator auf ein Ubuntu 20.04 Template auf einem Proxmox VE 7 Host.
Nach Abschluss aller Arbeiten habe ich präventiv einen fsck.ext4 -y /dev/vda3 durchgeführt, da wurde berichtet das keine Fehler aufgetreten sind.
Also zur Sicherheit ein manuelles Backup angestoßen das bei 11% abbrach:

INFO: 11% (55.2 GiB of 500.0 GiB) in 4m 28s, read: 485.0 MiB/s, write: 454.3 MiB/s
lzop: Input/output error: <stdout>
INFO: 11% (59.5 GiB of 500.0 GiB) in 7m 23s, read: 25.1 MiB/s, write: 23.6 MiB/s
Warning: unable to close filehandle GEN6339 properly: Input/output error at /usr/share/perl5/PVE/VZDump/QemuServer.pm line 764.
ERROR: vma_queue_write: write error - Broken pipe
INFO: aborting backup job
INFO: resuming VM again
ERROR: Backup of VM 101 failed - vma_queue_write: write error - Broken pipe
INFO: Failed at 2021-10-17 12:48:25
INFO: Backup job finished with errors
TASK ERROR: job errors

Vielleicht hilft das bei der Nachvollziehbarkeit weiter.
 
Last edited:
Hi,
Dieses Problem hatte wir bis Proxmox VE 6 in der Form nicht, gibt es da bereits Lösungansätze bzw. wurde das gemeldet ?
Nein, das hören wir das erste Mal, also dass es mit PVE 6.x geklappt hat und in PVE 7.x diese Regression gibt.

Fehler die dann auf der VM auftreten:
Ist im Journal am Host zu dem Zeitpunkt auch was zu sehen.

Also zur Sicherheit ein manuelles Backup angestoßen das bei 11% abbrach:
Also, brach es diesmal von selbst ab oder wurde wieder probiert den Job manuell abzubrechen?

Obiges Log scheint so als ob der Kompressor nicht mehr schreiben kann, ist genügen speicher am Backup Zielspeicher verfügbar? Netzwerk stabil?

Vielleicht hilft das bei der Nachvollziehbarkeit weiter.
Bitte auch die VM config posten (qm config VMID), wo liegen die Disken der VMs, am selben NFS wie die Backups?
 
Guten Morgen,

vielen Dank für die schnelle Rückmeldung. Hier etwas detaillierter:

Proxmox VE 7 Hostsystem:
Supermicro Server mit Intel Xeon E5-2620v4, 128 GB DDR4 ECC Ram, Supermicro Raidcontroller mit Broadcom 2108 und 4 x Intel D3-S4510 1920 GB SSD´s im Raid 10. Es gibt 2 Netzwerke, einmal extern und einmal intern komplett voneinander abgeschottet, die Backups laufen auf ein größeres FreeNAS System das zwar momentan etwas ausgelastet ist, aber ca. 90% der Backups laufen problemlos durch.

Dieses System wurde frisch installiert vor ca. 1 Woche. Dann haben wir auf einem anderen System ein Template angelegt mit Ubuntu 20.04 und Plesk, davon ein Image gezogen und das nutzen wir für die Systeme in dem wir eine neue VM damit anlegen.

Wie geschrieben am Wochenende ein Plesksystem migriert, danach fsck keine Fehler, dann ein manuelles Backup mit LZO und Snapshot, das brach mit der oben genannten Meldung ab (es brach von alleine ab, ohne Zutun meinerseits). Dann kamen die Dateisystemfehler in der Konsole und der manuelle fsck behob alles.

Die VM´s laufen auf local-lvm, da sind gerade 7,92% belegt. Die VM config:
Code:
boot: cdn
bootdisk: virtio0
cores: 4
cpu: host
ide2: none,media=cdrom
memory: 8192
name: server2
net0: virtio=1E:C0:AD:891:16,bridge=vmbr0,firewall=1
net1: virtio=96:38C:9B:C0:B5,bridge=vmbr1,firewall=1
numa: 0
onboot: 1
ostype: l26
scsihw: virtio-scsi-pci
smbios1: uuid=df4799b1-a019-4cc9-933d-90081ab7f3ed
sockets: 1
virtio0: local-lvm:vm-101-disk-0,cache=writeback,size=500G
vmgenid: d7ae04b6-8d61-425b-ba12-ea4a324e85d7

Auf dem Hostsystem selbst sind keine Dateisystemfehler aufgetreten, nur auf der VM.

Was mich wundert ist das es auch bei aktualisierten Systemen auftritt, also Proxmox 5 mit Debian 9 System was seit 2 Jahren z.B. läuft mit wöchentlichen Backups, dann aktualisieren wir auf Proxmox 7 und Debian 10 und beim nächsten automatischen Backup tritt der Fehler auf das wir einen fsck durchführen müssen.

Wenn ich mit weiteren Informationen helfen kann gerne Bescheid sagen.
 
Last edited by a moderator:
Hallo,

das habe ich nicht ausprobiert, ich kann aber nochmal einen identischen Ablauf nachspielen in den kommenden Tagen:
- neuen Container mit Template erstellen
- Plesk Migration durchführen
- Backup lokal statt NFS

Mal schauen ob dann auch die Fehler auftreten. Auf diese Testmöglichkeit bin ich noch nicht gekommen, Danke für den Anstoß, ich melde mich sobald ich es getestet habe.
 
Kleiner Tip aus 20 Jahren Troubleshooting:
- immer nur eine Sache auf einmal ändern
- jede Komponente auch wen unwahrscheinlich in betracht ziehen
- KISS Prizip (Keep it Simple & Solid) also beim Backup mal das Netzwerk außenvor lassen. ;)
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!