Linux ZFS Boot-Mirror kaputt: 4 Rescue-Wege

Ein ZFS-Root-Mirror gilt als eine der robustesten Boot-Konfigurationen fuer Linux-Server. In der Praxis erleben wir dennoch regelmaessig Faelle, in denen Proxmox- oder Ubuntu-Systeme nach einem Stromausfall, einem Firmware-Update oder dem Ausfall einer Mirror-Haelfte nicht mehr starten. Der Bildschirm bleibt schwarz, GRUB haengt in der Rescue-Shell oder das Initramfs meldet lakonisch cannot import 'rpool': no such pool available.

Dieser Artikel beschreibt vier bewaehrte Wege, mit denen wir bei Kunden einen kaputten ZFS-Bootpool wieder ans Laufen bringen. Die Reihenfolge ist nach Aufwand und Risiko sortiert: von der einfachen Chroot-Reparatur bis zum vollstaendigen Reimport aus einem Snapshot. Die Kommandos sind bewusst konservativ formuliert und wurden auf Proxmox VE 8/9 und Ubuntu 22.04/24.04 verifiziert.

Warum ZFS-Bootpools ueberhaupt sterben

Ein rpool besteht aus mehreren Schichten, die alle zusammenspielen muessen: die EFI-System-Partition (ESP) mit dem Bootloader, die ZFS-Partition mit dem Poolmembership-Label und schliesslich der Kernel plus Initramfs im Dataset. Faellt eine dieser Schichten aus, sieht das Symptom identisch aus, die Ursache liegt aber ganz woanders.

Typische Ursachen, die wir sehen:

Symptom	Wahrscheinliche Ursache	Erste Diagnose
GRUB Rescue-Shell, kein Menue	ESP nicht gefunden oder GRUB-Modul defekt	Bootreihenfolge im BIOS/UEFI pruefen
Initramfs-Prompt, no pool available	ZFS-Label korrupt oder Cache falsch	zpool import von Live-ISO
Kernel-Panic beim Mount	Falsche Kernel/Initramfs-Version	zfs list -t snapshot
Nur eine Platte bootet	Zweiter Mirror-Member fehlt in ESP-Kette	efibootmgr -v bzw. grub-install
Boot haengt bei Loading initial ramdisk	Initramfs enthaelt keinen ZFS-Modul	update-initramfs -u -k all

Wichtig: Ein ZFS-Mirror schuetzt gegen Datenverlust auf Blockebene, nicht gegen einen kaputten Bootloader. Wer nach einem Disk-Wechsel grub-install nur auf die erste Platte laufen laesst, hat effektiv keinen Boot-Mirror mehr, auch wenn zpool status sauber ONLINE meldet.

Methode 1: Chroot aus der Live-ISO

Der Standardweg fuer die meisten Faelle. Sie booten eine passende Live-ISO, importieren den Pool schreibbar und wechseln per chroot in das installierte System. Ab da laufen alle Standard-Tools wie in einer normalen Session.

Voraussetzung ist eine Live-Umgebung mit passendem ZFS-Modul. Bei Proxmox empfiehlt sich die Proxmox-VE-ISO im Debug-Modus, bei Ubuntu ein aktuelles Live-Server-Image mit nachinstalliertem zfsutils-linux.

# 1. Pool suchen und mit alternativem Mountpoint importieren
zpool import
zpool import -f -R /mnt rpool

# 2. Kernel-Pseudo-Filesysteme einbinden
mount --rbind /dev  /mnt/dev
mount --rbind /proc /mnt/proc
mount --rbind /sys  /mnt/sys

# 3. EFI-Partition mounten (Pfad je nach Layout anpassen)
mount /dev/nvme0n1p2 /mnt/boot/efi

# 4. Ins System wechseln
chroot /mnt /bin/bash

Im Chroot haben Sie das volle System zur Verfuegung: apt, dpkg, grub-install, update-initramfs, zpool status. Der -R /mnt beim Import ist entscheidend, sonst versucht ZFS auf / zu mounten und zerlegt Ihnen die Live-Session.

Nach getaner Arbeit sauber aussteigen:

exit
umount -R /mnt/boot/efi /mnt/sys /mnt/proc /mnt/dev
zpool export rpool
reboot

Der zpool export ist kein Kosmetik-Schritt. Ohne ihn bleibt das Poolmembership-Label auf “in use by another system” und der naechste Boot beschwert sich mit pool was previously in use from another system.

Methode 2: Bootloader neu bauen

Wenn der Pool sauber importiert, das System aber trotzdem nicht bootet, ist meist der Bootloader die Ursache. Typische Ausloeser: ein GRUB-Update, das die ESP-Kette zerlegt hat, ein disk replace ohne proxmox-boot-tool init, oder eine neue Kernelversion, deren Initramfs keinen ZFS-Support bekommen hat.

Im Chroot aus Methode 1 laufen dann folgende Schritte:

# Proxmox-Systeme (systemd-boot oder GRUB, seit PVE 7):
proxmox-boot-tool status
proxmox-boot-tool refresh

# Falls die ESP neu initialisiert werden muss:
proxmox-boot-tool format /dev/nvme0n1p2
proxmox-boot-tool init /dev/nvme0n1p2

# Ubuntu / klassisches GRUB:
grub-install --target=x86_64-efi \
             --efi-directory=/boot/efi \
             --bootloader-id=ubuntu --recheck
update-grub
update-initramfs -u -k all

Bei Mirror-Setups muss grub-install bzw. proxmox-boot-tool init fuer jede ESP-Partition einzeln laufen. Wir sehen regelmaessig Setups, in denen nur die erste Platte eine funktionierende ESP hat und der Ausfall der ersten SSD dann das gesamte System stilllegt, obwohl der ZFS-Mirror technisch sauber weiterlaeuft.

Als Kontrolle:

efibootmgr -v          # zeigt alle EFI-Boot-Eintraege
proxmox-boot-tool status
zpool status -v rpool

Alle drei Ausgaben muessen zusammenpassen: gleicher Kernel, gleiche ESP-UUID, gleiche Poolmember. Weichen sie ab, ist die Wahrscheinlichkeit hoch, dass das System nur solange bootet, wie die “richtige” Platte am “richtigen” Port haengt.

Methode 3: Notbetrieb mit nur einer Platte

Manchmal ist eine Mirror-Haelfte physisch tot, die zweite haengt aber am Controller. ZFS kann daraus problemlos booten, der Bootloader nicht immer. Ziel dieser Methode: das System schnell wieder produktiv bekommen, bevor Sie in Ruhe eine neue Platte einbauen.

Vorgehen im Chroot:

# 1. Fehlende Platte im Pool markieren
zpool status rpool
zpool detach rpool <fehlende-guid>

# 2. Sicherstellen, dass die verbliebene Platte bootfaehig ist
proxmox-boot-tool status                     # Proxmox
grub-install --target=x86_64-efi \
             --efi-directory=/boot/efi ...   # Ubuntu

# 3. Reboot und pruefen

Wichtig ist die Reihenfolge: erst detach, dann Bootloader neu schreiben. Ein zpool remove ist bei Mirror-Pools nicht das, was Sie wollen, das ist fuer log/cache-vdevs gedacht. Fuer Mirror-Members ist zpool detach das richtige Werkzeug.

Nach dem Reboot laeuft der Server wieder, hat aber keine Redundanz mehr. Sobald die Ersatzplatte da ist:

# Neue Platte partitionieren (identisches Layout wie Ueberlebende)
sgdisk --replicate=/dev/nvme1n1 /dev/nvme0n1
sgdisk --randomize-guids /dev/nvme1n1

# ZFS-Partition an bestehenden Mirror haengen
zpool attach rpool <ueberlebende-part> /dev/nvme1n1p3

# ESP der neuen Platte in den Boot-Kanon aufnehmen
proxmox-boot-tool format /dev/nvme1n1p2
proxmox-boot-tool init /dev/nvme1n1p2

Der Resilver-Vorgang laeuft im Hintergrund. zpool status rpool zeigt Fortschritt und geschaetzte Restzeit.

Methode 4: Vollstaendiger Reimport aus Snapshot

Der letzte Ausweg, wenn der Pool sich nicht mehr sauber importieren laesst oder Sie versehentlich zpool destroy ausgefuehrt haben. Voraussetzung: Sie haben zfs send-Snapshots auf einem separaten Ziel, idealerweise auf einem TrueNAS-Backup-Target oder einem zweiten Standort.

Grober Ablauf:

1. Frische Installation auf neuen Platten, gleiche ZFS-Version wie das Ursprungssystem.
2. Neuer rpool wird angelegt, System bootet leer hoch.
3. Live-ISO booten, alten rpool (falls noch teilweise vorhanden) mit zpool import -F -R /mnt rpool_alt versuchen zu importieren. -F erlaubt Rollback auf die letzte konsistente Transaktionsgruppe, was bei plotzlichem Stromausfall oft ausreicht.
4. Wenn das nicht klappt, Snapshots vom Backup zurueckholen:

zfs receive -F rpool/ROOT/pve-1 < /mnt/backup/rpool_root_2026-07-29.zfs
zfs receive -F rpool/data       < /mnt/backup/rpool_data_2026-07-29.zfs

5. Bootloader mit den Schritten aus Methode 2 neu bauen.
6. zfs set mountpoint=/ rpool/ROOT/pve-1 und zfs set bootfs=rpool/ROOT/pve-1 rpool pruefen.

Dieser Weg dauert je nach Datenmenge Stunden bis Tage. Er ist nichts, was man improvisiert, sondern etwas, das man einmal jaehrlich als Restore-Test durchspielt.

UEFI vs. BIOS: die haeufigsten Stolperfallen

Ein grosser Teil der Rescue-Faelle bei uns geht auf UEFI/BIOS-Verwechslungen zurueck. Ein System, das im UEFI-Modus installiert wurde und dann versehentlich im Legacy-Modus bootet, findet den Pool nicht, obwohl technisch alles heil ist.

Checkliste, wenn nichts passt:

• [ -d /sys/firmware/efi ] in der Live-ISO pruefen: liegt UEFI vor?
• Secure Boot im UEFI: bei aelteren ZFS-Modulen ohne Signatur bleibt der Bildschirm schwarz.
• CSM/Legacy im UEFI ausgeschaltet, wenn UEFI-Install vorliegt.
• Bei Proxmox: proxmox-boot-tool status zeigt, ob systemd-boot oder GRUB aktiv ist. Beide gleichzeitig zu benutzen fuehrt regelmaessig zu Chaos.
• Bei Ubuntu: /boot/efi und /boot sind unterschiedliche Partitionen, bitte nicht verwechseln.

Wer sich unsicher ist, protokolliert vor jedem groesseren Eingriff einmal lsblk -f, efibootmgr -v und zpool status -v in eine Datei auf einem USB-Stick. Das erspart im Ernstfall viel Sucherei.

Fazit

Ein ZFS-Bootpool ist robust, aber nicht magisch. Die vier beschriebenen Wege decken den Grossteil der Faelle ab, die wir in Kundensystemen sehen. Wichtig ist, den richtigen Weg zu waehlen: nicht jedes Boot-Problem ist ein Pool-Problem, und nicht jeder Pool-Fehler laesst sich mit grub-install beheben. Wer regelmaessig zfs send-Snapshots ausserhalb des Systems ablegt und einmal jaehrlich einen Restore-Test macht, kommt auch mit Totalausfaellen souveraen zurecht.

DATAZONE unterstuetzt Sie bei der Absicherung Ihrer Linux- und Proxmox-Server mit ZFS-Root-Mirror, Backup-Strategie auf TrueNAS und Notfallwiederherstellung. Fuer Konzeption, Rescue-Einsatz oder ein Backup-Konzept, das nicht nur auf dem Papier funktioniert, sprechen Sie uns an: Kontakt aufnehmen oder direkt einen Termin fuer die Linux-Beratung vereinbaren.