Backups Scheitern an Buffer I/O

D

DonMoritz

New Member
Jan 14, 2025
9
0
1
Hallo Leute,
in letzter Zeit scheitern meine Backups ständig von einer VM. Beim Auslesen des Syslogs kommt folgende Fehlermeldung:

Feb 14 19:42:41 pve kernel: Buffer I/O error on dev zd0, logical block 3361844, async page read
Feb 14 19:42:41 pve kernel: Buffer I/O error on dev zd0, logical block 3361844, async page read
Feb 14 19:42:41 pve kernel: Buffer I/O error on dev zd0, logical block 3361844, async page read
Feb 14 19:42:41 pve zed[1053897]: eid=23 class=data pool='rpool' priority=0 err=52 flags=0x8081 bookmark=17486:1:0:840461
Feb 14 19:42:41 pve zed[1053896]: eid=24 class=checksum pool='rpool' vdev=nvme-CT1000P3SSD8_241047711AF4-part3 algorithm=fletcher4 size=16384 offset=283848323072 priority=0 err=52 flags=0x180080 delay=15ms bookmark=17486:1:0:840461
Feb 14 19:42:41 pve zed[1053895]: eid=25 class=data pool='rpool' priority=0 err=52 flags=0x8081 bookmark=17486:1:0:840461
Feb 14 19:42:41 pve zed[1053898]: eid=26 class=data pool='rpool' priority=0 err=52 flags=0x8081 bookmark=17486:1:0:840461
Feb 14 19:42:41 pve pvedaemon[1043183]: ERROR: Backup of VM 100 failed - job failed with err -5 - Input/output error
Feb 14 19:42:41 pve pvedaemon[1043183]: INFO: Backup job finished with errors

Hat einer eine Idee, woran das scheitern liegen kann?

Beste Grüße
 
Input/output putput error mit zfs on root ..., was sagt zpool status und lsblk welche Platten du wie verbaut hast ?
 
Also Zpool Status sagt:

pool: Raiddrives
state: ONLINE
scan: scrub repaired 20K in 01:13:03 with 0 errors on Sun Feb 9 01:37:04 2025
config:

NAME STATE READ WRITE CKSUM
Raiddrives ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WD40EFAX-68JH4N0_WD-WX42D100JRYC ONLINE 0 0 0
wwn-0x5000c500f7759975 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
ata-WDC_WD40EFAX-68JH4N0_WD-WX22D10F16ET ONLINE 0 0 0
ata-ST4000NE001-2MA101_WS256RLA ONLINE 0 0 0

errors: No known data errors

pool: rpool
state: DEGRADED
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
scan: scrub repaired 0B in 00:00:56 with 1 errors on Mon Dec 9 00:17:53 2024
config:

NAME STATE READ WRITE CKSUM
rpool DEGRADED 0 0 0
nvme-CT1000P3SSD8_241047711AF4-part3 DEGRADED 0 0 24 too many errors

LBSK:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 3.6T 0 disk
├─sda1 8:1 0 3.6T 0 part
└─sda9 8:9 0 8M 0 part
sdb 8:16 0 3.6T 0 disk
├─sdb1 8:17 0 3.6T 0 part
└─sdb9 8:25 0 8M 0 part
sdc 8:32 0 3.6T 0 disk
├─sdc1 8:33 0 3.6T 0 part
└─sdc9 8:41 0 8M 0 part
sdd 8:48 0 3.6T 0 disk
├─sdd1 8:49 0 3.6T 0 part
└─sdd9 8:57 0 8M 0 part
zd0 230:0 0 200G 0 disk
├─zd0p1 230:1 0 100M 0 part
├─zd0p2 230:2 0 16M 0 part
├─zd0p3 230:3 0 199.3G 0 part
└─zd0p4 230:4 0 572M 0 part
zd16 230:16 0 4M 0 disk
zd32 230:32 0 1M 0 disk
zd48 230:48 0 3T 0 disk
├─zd48p1 230:49 0 16M 0 part
└─zd48p2 230:50 0 2.9T 0 part
zd64 230:64 0 1M 0 disk
zd80 230:80 0 500G 0 disk
├─zd80p1 230:81 0 1M 0 part
├─zd80p2 230:82 0 2G 0 part
└─zd80p3 230:83 0 498G 0 part
zd96 230:96 0 200G 0 disk
├─zd96p1 230:97 0 100M 0 part
├─zd96p2 230:98 0 16M 0 part
├─zd96p3 230:99 0 199.3G 0 part
└─zd96p4 230:100 0 572M 0 part
zd112 230:112 0 500G 0 disk
├─zd112p1 230:113 0 16M 0 part
└─zd112p2 230:114 0 500G 0 part
nvme0n1 259:0 0 931.5G 0 disk
├─nvme0n1p1 259:1 0 1007K 0 part
├─nvme0n1p2 259:2 0 1G 0 part
└─nvme0n1p3 259:3 0 930.5G 0 part


Ich habe insgesamt eine NVME SSD verbaut, als auch 4 Festplatten die ich im Raid zusammengefasst habe. Auf der NVME läuft Proxmox und die VMs werden drauf gehostet.

Die Fehler auf der NVME sind folgende:

errors: Permanent errors have been detected in the following files:

rpool/data/vm-100-disk-1@__base__:<0x1>
rpool/data/vm-100-disk-1:<0x1>
/var/lib/vz/dump/vzdump-qemu-100-2024_12_08-23_28_21.vma.zst

Dazu ist zu ergänzen, dass ich vor kurzem eine fehlerhafte Festplatte im Raid hatte und diese ausgetauscht habe. Die Backups haben dann aber gut funktioniert, so dass ich meine ausschließen zu können, dass es daran liegt..
 
Zpool list:
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
Raiddrives 7.25T 677G 6.59T - - 0% 9% 1.00x ONLINE -
rpool 928G 85.9G 842G - - 9% 9% 1.00x DEGRADED -

zfs list:
NAME USED AVAIL REFER MOUNTPOINT
Raiddrives 4.83T 2.30T 96K /Raiddrives
Raiddrives/Data01 532G 2.30T 532G /raiddrivesdata
Raiddrives/vm-100-disk-0 3.12T 5.37T 46.5G -
Raiddrives/vm-100-disk-1 508G 2.75T 45.9G -
Raiddrives/vm-101-disk-0 508G 2.74T 51.9G -
Raiddrives/vm-102-disk-0 3M 2.30T 104K -
Raiddrives/vm-102-disk-1 203G 2.49T 385M -
rpool 85.9G 813G 104K /rpool
rpool/ROOT 5.04G 813G 96K /rpool/ROOT
rpool/ROOT/pve-1 5.04G 813G 5.04G /
rpool/data 36.6G 813G 96K /rpool/data
rpool/data/vm-100-disk-0 272K 813G 168K -
rpool/data/vm-100-disk-1 36.6G 813G 24.9G -
rpool/data/vm-100-disk-2 156K 813G 80K -
rpool/var-lib-vz 44.1G 813G 44.1G /var/lib/vz

cat /dev/nvme0n1 >/dev/null hat irgendwie weder ein Fehler noch ein anderes Ergebnis herausgegeben.

Übrigens, vielen Dank nochmal, dass du dir dafür die Zeit am Freitag Abend nimmst!
 
Hier nach dem Scrub:

pool: Raiddrives
state: ONLINE
scan: scrub repaired 20K in 01:13:03 with 0 errors on Sun Feb 9 01:37:04 2025
config:

NAME STATE READ WRITE CKSUM
Raiddrives ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WD40EFAX-68JH4N0_WD-WX42D100JRYC ONLINE 0 0 0
wwn-0x5000c500f7759975 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
ata-WDC_WD40EFAX-68JH4N0_WD-WX22D10F16ET ONLINE 0 0 0
ata-ST4000NE001-2MA101_WS256RLA ONLINE 0 0 0

errors: No known data errors

pool: rpool
state: DEGRADED
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
scan: scrub repaired 0B in 00:01:11 with 1 errors on Fri Feb 14 22:52:25 2025
config:

NAME STATE READ WRITE CKSUM
rpool DEGRADED 0 0 0
nvme-CT1000P3SSD8_241047711AF4-part3 DEGRADED 0 0 26 too many errors
 
Das ist ein ganz böser Fehler !!
NICHT booten oder ausschlten - weil das geht womöglich nicht mehr, weil du ein single disk rpool hast !!!
Alles aktuell gebackupt ? Wenn nicht machen !!
Ich würde alle vm/lxc anhalten ; zfs create Raiddrives/os-nvme ; da alles rein.
Identifizieren der defekten Dateien ist eine Sache, lassen sich aber wahrscheinlich aber NICHT löschen, weil inkonsistent ...
Neuen nvme Ersatz beschaffen, booten, dann kommt pve wieder hoch oder eben nicht mehr.
Wenn nicht, auf neue disk neu installieren, Raiddrives importieren und alles recovern ...
Viel Glück und Erfolg.
 
Last edited:
  • Like
Reactions: DonMoritz
Noch ein ist sehr wichtiger Hinweis: Die WD Festplatten: WD40EFAX
sind nicht für ZFS Betrieb geeignet und es wird direkt von WD davon abgeraten!
Sie haben ein Aufnahmeverfahren dass sich SMR nennt und immer mehr als einen Sektor beschreiben muss. Das führt zur großen Abnutzung und bei mir sind so schon zwei der 4 Terabyte Festplatten gestorben, sie waren wirklich mechanisch kaputt.

Zur information da gibt es das Kommando: zpool status -x
Es zeigt die defekten Dateien direkt an, die kann man dann auch direkt mit RM löschen.

Ich hatte bei Seagate vier Terabyte Festplatten diesen Fehler, über drei Jahre, auch schon zweimalig.
Der ZFS Raidz1 Pool mit zwei VDEVs und ZFS special device auf SSDs werden für Größe Backup Strukturen verwendet, und durch Entfernen der defekten Dateien und zurückspielen aus dem Backup war das Problem bei mir behoben.
 
Last edited:
  • Like
Reactions: waltar and UdoB
Noch ein weiterer Tipp, man kann den Zfs Pool rpool natürlich duplizieren, ein ZFS VDEV mirror neu anlegen, BIOS und EFI Partition anlegen, und so das System im laufenden Betrieb auf eine weiter SSDs migrieren.
Das geht mit den schon installierten Hausmitteln des Debian / Proxmox VE systems.

Hat man einen USB Adapter mit z.B. ein Terabyte SSD dazu kann, man vorläufig auch eine MX500 1 TB verwenden, sie ist relativ leicht zu beschaffen und hat eine Power lost protection verbaut.
Das mit den Hausmitteln im laufenden Betrieb, ohne den Rechner abschalten zu müssen, möglich, da der USB 3 -- SATA Adapter im laufenden Betrieb erkannt wird. Das kann man nicht bei allen SATA Schnittstellen am Mainboard erwarten.

Aber wichtig, was jetzt als defekte Dateien gekennzeichnet wurde muss wirklich vorher gelöscht werden!
 
Last edited:
  • Like
Reactions: waltar
Vielen Dank erstmal. Ich habe eben die ganzen Sicherungen gemacht. Ich habe heute mal die Logs durchgesehen und festgestellt, dass der Fehler schon etwas länger zurückliegt... und ich habe währenddessen schon oft das System neugestartet. Glück gehabt?

Danke auch an dich News - Welche Festplatten kannst du denn empfehlen? Ich habe die Festplatten einfach aus einem NAS von mir genommen, in der Erwartung, dass das schon passt.

Bei zpool status -x wird mir zunächst nichts angezeigt, was mir irgendwie den Rückschluss auf die fehlerhaften Dateien anzeigt. Wenn ich aber zpool status -v eingebe erscheint folgendes:

errors: Permanent errors have been detected in the following files:

rpool/data/vm-100-disk-1@__base__:<0x1>
rpool/data/vm-100-disk-1:<0x1>
/var/lib/vz/dump/vzdump-qemu-100-2024_12_08-23_28_21.vma.zst

Die Disk-1 ist - wenn ich mich richtig erinnere - aber auf dem Festplattenraid? Kann es sein, dass ich den Fehler verursacht habe, als ich eine fehlerhafte Platte im Raid ausgetauscht habe?
 
Was viel naheliegender als die Consumer-Festplatten in dem Raiddrive Pool ist, ist dass die NVME CT1000P3SSD8 im rpool eine Crucial P3 ist, also ein Consumer-Laufwerk mit QLC NVRAM. Da frisst sich ZFS durch wie durch Butter, was den Fehler auch sehr gut erklärt - der Fehler ist ja dort, nicht auf den Festplatten!

Ich würde die dringend austauschen. Du kannst mit "smartctl -a /dev/nvme0" nachsehen, wieviel Lebensdauer da schon verbraucht ist - der Hersteller gibt an, dass die Platte nur 220 Mal überschrieben werden kann. Ich würde drauf wetten, dass die fertig ist - Kunststück, wenn sie schon echte Fehler zeigt...

Man sollte da unbedingt NVMEs mit mindestens 2000 TBW nutzen, vorzugsweise mit RAM Cache, auf keinen Fall QLC.
 
Ja wenn Du noch mal IronWolf Pro NAS 4 TB, CMR, ST4000NE001 kaufen kannst, dann schau mal bei Alternate.de.

In meinem Proxmox BS nutze ich auch zwei ZFS Pools mit folgenden Setups:
1) 2x IronWolf Pro NAS 4 TB, CMR, ST4000NE001
2) 2x Crucial MX500 1TB, CT1000MX500SSD1

I) ZFS Pool "rpool" mit VDEV Mirror (SSD Part 3.1/3.2 465GB)
a) SSD Part 1.1/2.1 ist Bios Bootpartition
b) SSD Part 1.2/2.2 ist EFI Bootpartition

II) ZFS Pool "dpool" mit VDEV Mirror mit
1) 2x IronWolf Pro NAS 4 TB, CMR, ST4000NE001

2) 2x Crucial MX500 1TB, CT1000MX500SSD1 3 Partitionen:
a) ZFS VDEV Special Device Mirror (SSD Part 4.1/4.2 250GB)
b) ZFS VDEV logs Mirror (SSD Part 5.1/5.2 16GB)
c) inaktiv ! ZFS VDEV cache (SSD Part 6.2) stripe (SSD Part 6.2)
 
Last edited:
Die MX500 ist leider auch ungeeignet, 360 TBW, kein RAM-Cache. Consumer-Laufwerke bedeuten bei Proxmox mit ZFS, auf einen Unfall zu warten, speziell, wenn man VMs drauftut, womöglich noch mit Auto-Snapshots.
 
Last edited:
Last edited:
Hast Du mal mit smartctl die Parameter ausgelesen? Bei SATA SSDs wird allerdings meist nicht die Lebensdauer angezeigt. Man sieht aber meist, wie viele Daten schon geschrieben wurden (Parameter 241) und die Reallocated Sectors (5) und manchmal auch den Wear Leveling Count (177).

TLC-Cache ersetzt keinen RAM-Cache. Das ist lediglich ein Bereich, in dem der TLC-Flash so behandelt wird, als habe er nur zwei Zustände und dient dazu, Schreiben zu beschleunigen.

RAM-Cache hilft dagegen bei kleineren Schreibzugriffen, wie sie z.B. mit ASHIFT=12 (4096 Bytes) entstehen, weil die physische Erase Block Size des Flashspeichers viel größer ist (heute oft 1-2 MByte). Deswegen muss man den selben Block oft mehrmals beschreiben, was die Abnutzung weiter befördert. Wenn man dagegen einen RAM-Cache hat, kann man die Daten alle auf einmal in den selben Block schreiben, was insgesamt weniger Schreiboperationen auf dem Flash zur Folge hat.

Insofern ist TLC-Cache sogar kontraproduktiv für die Abnutzung, weil im Hintergrund asynchron Daten aus dem SLC-Bereich in den TLC-Speicher umgelagert werden, was wiederum Schreiboperationen bewirkt.
 
Last edited:
@meyergru deine Argumentation ist für andere, als die CT1000MX500SSD1, evtl. richtig.
Ich sehe dies auch so, nur die CT1000MX500SSD1 erfüllt nicht die von Dir angesprochenen Bedingungen, somit ist Dir Folgerung nicht richtig.

Und ja ich überwache alle Smartdaten aller HDDs, SSDs und NVMe PCIe mit einem eigenen Script.

Ein anderes Setup läuft als Proxmox VE, Fileserver mit ZFS Poll dpool Seagate IronWolf 4TB (ST4000VN006) und ZFS Poll rpool 2x Crucial MX500 500GB (CT500MX500SSD1) seit 22.06.2024.
Und die beiden Crucial MX500 500GB wurden sei dem mit ca. 0,777 TB beschrieben.

CT500MX500SSD1, Blocksize: 512 Byte, TWB 180 TByte
a) Blöcke SSD1: 1669094587
==> TBW: 1669094587 * 512 Byte / 1024⁴ = 0,777232734 TByte

b) Blöcke SSD2: 1668544948
==> TBW: 1668544948 * 512 Byte / 1024⁴ = 0,776976788 TByte

Ich weiß schon, was ich tue; der Rechner läuft auch nur bei Bedarf, wenn Daten zu sichern sind.
 
Last edited:
Ich habe gesagt und begründet, dass (und warum) Consumer-SSDs für den Betrieb mit ZFS, speziell mit kleinen (d.h. default) Blockgrößen und für virtuelle Images (speziell mit Snapshots) ungeeignet sind. Ferner habe ich gesagt, was die Bedingungen sind, die einer Abnutzung der SSDs entgegenwirken, nämlich:

- kein QLC
- hoher TBW-Wert >= 2000 mal Überschreiben
- RAM-Cache

Ich habe auch gesagt, dass die Platte des OPs diese Bedingungen nicht erfüllt und vermutlich deswegen gestorben ist. Du hattest geschrieben, dass die Festplatten des OPs ungeeignet seien. Das mag sein, aber da liegt sein Fehler nicht. Er fragte nach Empfehlungen und Du hast Deine Konfiguration genannt.

Ich halte die Aussage aufrecht, dass das für die von Dir genannte MX500 diese Bedingungen auch nicht erfüllt, so sagt es zumindest der Hersteller Crucial selbst hier unter Specifications: https://www.crucial.de/ssd/mx500/ct1000mx500ssd1

Reviews und Hinweise auf vorhandenen TLC-Cache widerlegen meine Aussagen nicht.
 
You must log in or register to reply here.
Top Bottom