Proxmox VE: ZFS-Platte defekt tauschen – Schritt für Schritt

Ein ZFS-Mirror verzeiht den Ausfall einer Platte – aber nur einmal. Wer die Meldung DEGRADED ignoriert, arbeitet ohne Redundanz weiter, bis die zweite Platte ausfällt. Die gute Nachricht: In Proxmox VE lässt sich ein defektes Laufwerk meist im laufenden Betrieb tauschen, ohne den Host neu zu installieren. Diese Anleitung zeigt Diagnose, Austausch und die Besonderheiten beim Boot-Pool rpool.

Proxmox VE: ZFS-Platte defekt tauschen – Schritt für Schritt

Was „DEGRADED“ bedeutet

ZFS meldet den Pool weiterhin als ONLINE, solange mindestens eine Kopie der Daten lesbar ist. Ein Gerät im Zustand DEGRADED ist ausgefallen oder liefert Lesefehler, der Pool läuft aber ohne Redundanz weiter. FAULTED oder UNAVAIL bedeutet, dass ZFS das Gerät gar nicht mehr anspricht.

Häufigste Ursachen sind sterbende Festplatten mit wiederzugewiesenen Sektoren, lockere SATA- oder SAS-Kabel, defekte Backplanes und Stromprobleme. Vor der Bestellung neuer Hardware lohnt ein Blick auf Kabel und Steckverbinder – ein Wackelkontakt erzeugt dasselbe Fehlerbild wie eine defekte Platte.

Diagnose: Welche Platte ist betroffen?

Der erste Blick gilt dem Pool-Status. Die Option -v zeigt zusätzlich Dateien mit dauerhaften Fehlern:

zpool status -v
zpool list -v
lsblk -o NAME,SIZE,MODEL,SERIAL
smartctl -a /dev/sdX
dmesg -T | grep -Ei 'ata|sd |zfs|i/o error'

In der Ausgabe von zpool status zählen die Spalten READ, WRITE und CKSUM: Steigende CKSUM-Werte bei intaktem Kabel deuten auf die Platte hin. Erscheinen unter zpool status -v Dateinamen mit „permanent errors“, sind Daten bereits verloren – dann hilft nur das letzte Backup. Für das Monitoring genügt zpool status -x: Es meldet „all pools are healthy“ oder benennt das Problem.

Datenpool tauschen – im laufenden Betrieb

Platten werden über ihre stabile by-id-Kennung adressiert, nie über /dev/sdb, denn die Buchstaben können sich nach einem Neustart ändern. Zuerst das defekte Gerät offline nehmen, dann physisch tauschen (Hot-Swap nur, wenn Backplane und Controller das unterstützen):

zpool offline tank /dev/disk/by-id/ata-WDC_WD40EFRX-AAAA
ls -l /dev/disk/by-id/ | grep -i ata-WDC_WD40EFRX-BBBB
zpool replace tank /dev/disk/by-id/ata-WDC_WD40EFRX-AAAA /dev/disk/by-id/ata-WDC_WD40EFRX-BBBB
zpool status -v

Der Resilver startet automatisch. Je nach Füllstand und Plattenanzahl dauert er Minuten bis Stunden; in dieser Zeit nicht neu starten und keine weiteren Änderungen am Pool erzwingen. Anschließend einmal scrubben, damit ZFS alle Blöcke gegen die Prüfsummen verifiziert:

zpool scrub tank
zpool status -x

autoreplace=on hilft nur, wenn sich der Gerätename nicht ändert. Da by-id-Namen die Seriennummer enthalten, ist der manuelle zpool replace der sichere Weg.

Sonderfall Boot-Pool rpool

Beim System-Mirror müssen Partitionstabelle und EFI-Partition mitgezogen werden. sgdisk -R kopiert die Partitionierung der intakten Platte, -G vergibt neue GUIDs, damit beide Datenträger eindeutig bleiben:

sgdisk /dev/sda -R /dev/sdb
sgdisk -G /dev/sdb
zpool replace -f rpool /dev/sda3 /dev/sdb3
proxmox-boot-tool format /dev/sdb2 --force
proxmox-boot-tool init /dev/sdb2 --force
proxmox-boot-tool refresh
proxmox-boot-tool status

Partition 2 ist die ESP, Partition 3 gehört zu ZFS. Auf Systemen mit BIOS und GRUB lautet der Aufruf proxmox-boot-tool init /dev/sdb2 --grub. proxmox-boot-tool status muss danach beide ESPs mit identischer Version auflisten; erst dann ist der Host wieder bootfähig, falls die verbleibende Platte ausfällt.

Vorbeugen statt improvisieren

Ein Mirror ist kein Backup: Ransomware, versehentliches Löschen und Fehler im Dateisystem erreichen beide Platten gleichzeitig. Das BSI fordert im Baustein CON.3 ein Datensicherungskonzept mit räumlich getrennten Kopien – für Proxmox heißt das vzdump oder Proxmox Backup Server auf ein anderes Ziel.

Für den laufenden Betrieb reichen wenige Routinen: SMART-Werte regelmäßig prüfen, zpool status -x in die Überwachung aufnehmen und den monatlichen Scrub kontrollieren (systemctl list-timers 'zfs*'). Eine baugleiche Ersatzplatte im Schrank verkürzt die Zeit ohne Redundanz erheblich.

Fazit

Ein degradierter ZFS-Pool ist ein Warnsignal, kein Notfall – solange rechtzeitig gehandelt wird. Wer die Platte über by-id identifiziert, offline nimmt und per zpool replace tauscht, bleibt im Betrieb. Beim Boot-Pool entscheidet die sauber nachgezogene ESP darüber, ob der Server nach dem nächsten Ausfall noch startet.

Quellen

• Proxmox VE Wiki: ZFS on Linux – Abschnitt „Changing a failed bootable device“, abgerufen am 4. November 2026.
• OpenZFS: zpool-replace(8) – Syntax und Optionen von zpool replace, abgerufen am 4. November 2026.
• Thomas-Krenn-Wiki: Boot-Device Replacement – Change of Proxmox ZFS Mirror Disk, abgerufen am 4. November 2026.
• BSI: IT-Grundschutz-Kompendium, Baustein CON.3 Datensicherungskonzept, abgerufen am 4. November 2026.

Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.