Linux ZFS Boot-Mirror kaputt: 4 Rescue-Wege

Ein ZFS-Root-Mirror gilt als eine der robustesten Boot-Konfigurationen für Linux-Server. In der Praxis erleben wir dennoch regelmäßig Fälle, in denen Proxmox- oder Ubuntu-Systeme nach einem Stromausfall, einem Firmware-Update oder dem Ausfall einer Mirror-Hälfte nicht mehr starten. Der Bildschirm bleibt schwarz, GRUB hängt in der Rescue-Shell oder das Initramfs meldet lakonisch cannot import 'rpool': no such pool available.

Dieser Artikel beschreibt vier bewährte 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 vollständigen 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 überhaupt sterben

Ein rpool besteht aus mehreren Schichten, die alle zusammenspielen müssen: die EFI-System-Partition (ESP) mit dem Bootloader, die ZFS-Partition mit dem Poolmembership-Label und schließlich der Kernel plus Initramfs im Dataset. Fällt 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 Menü	ESP nicht gefunden oder GRUB-Modul defekt	Bootreihenfolge im BIOS/UEFI prüfen
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 hängt bei Loading initial ramdisk	Initramfs enthält keinen ZFS-Modul	update-initramfs -u -k all

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

Methode 1: Chroot aus der Live-ISO

Der Standardweg für die meisten Fälle. 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 Verfügung: 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 nächste 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 Auslöser: 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 für jede ESP-Partition einzeln laufen. Wir sehen regelmäßig 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 weiterläuft.

Als Kontrolle:

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

Alle drei Ausgaben müssen 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 hängt.

Methode 3: Notbetrieb mit nur einer Platte

Manchmal ist eine Mirror-Hälfte physisch tot, die zweite hängt 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 für log/cache-vdevs gedacht. Für Mirror-Members ist zpool detach das richtige Werkzeug.

Nach dem Reboot läuft 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 läuft im Hintergrund. zpool status rpool zeigt Fortschritt und geschätzte Restzeit.

Methode 4: Vollständiger Reimport aus Snapshot

Der letzte Ausweg, wenn der Pool sich nicht mehr sauber importieren lässt oder Sie versehentlich zpool destroy ausgeführt 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 plötzlichem Stromausfall oft ausreicht.
4. Wenn das nicht klappt, Snapshots vom Backup zurückholen:

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 prüfen.

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

UEFI vs. BIOS: die häufigsten Stolperfallen

Ein großer Teil der Rescue-Fälle bei uns geht auf UEFI/BIOS-Verwechslungen zurück. 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 prüfen: liegt UEFI vor?
• Secure Boot im UEFI: bei älteren 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 führt regelmäßig zu Chaos.
• Bei Ubuntu: /boot/efi und /boot sind unterschiedliche Partitionen, bitte nicht verwechseln.

Wer sich unsicher ist, protokolliert vor jedem größeren 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 Großteil der Fälle ab, die wir in Kundensystemen sehen. Wichtig ist, den richtigen Weg zu wählen: nicht jedes Boot-Problem ist ein Pool-Problem, und nicht jeder Pool-Fehler lässt sich mit grub-install beheben. Wer regelmäßig zfs send-Snapshots außerhalb des Systems ablegt und einmal jährlich einen Restore-Test macht, kommt auch mit Totalausfällen souverän zurecht.

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