⚡ HomelabVergleich

Dateisysteme im Homelab: ZFS, Btrfs, ext4 oder Ceph – was wann passt

Du hast plötzlich drei Festplatten mehr, willst sie sinnvoll zusammenfassen und starrst auf die Auswahl an Dateisystemen: ZFS, Btrfs, ext4, Ceph – die Namen klingeln dir vielleicht schon aus Foren und YouTube-Empfehlungen. Die Frage ist keine reine Hardware-Frage. Sie ist eine Infrastruktur-Entscheidung, die sich auf Wartung, Wiederherstellungszeit und Datenrisiko über die ganze Nutzungsdauer auswirkt.

Dieser Artikel geht es systematisch an: Eine Entscheidungsmatrix, dann tief in die vier Kandidaten, dann konkrete Empfehlungen nach Einsatzzweck, ein Kapitel über häufige Fehler und abschließend ein kleines CLI-Kapitel mit Befehlen, die du direkt anpassen kannst.

> Hinweis: Dieser Artikel behandelt das Dateisystem im Ganzen – Features, Kompromisse, Betrieb. Der Artikel Speicherhardware im Homelab: NAS, Mini-PC oder echter Server deckt die Hardware-Seite ab (Platten, ECC, NAS-Geräte, Server). Beide Artikel ergänzen sich, aber sie sind getrennt – hier geht es nicht um ECC-RAM-Pflicht oder RAID-Gehäuse, sondern um das Dateisystem und sein Betrieb.

Die Entscheidungsmatrix: Kriterien im Überblick

Bevor wir in die Details gehen, hier die Matrix. Alle Kandidaten sind ehrlich eingeschätzt – nicht beworben.

|| Kriterium | ZFS | Btrfs | ext4 | Ceph |

||---|---|---|---|---|

|| Datenintegrität & Scrubbing | Ja – Prüfsummen auf allen Blöcken und Metadaten; zpool scrub aktiv nach Korruption suchen | Ja – Prüfsummen auf Daten und Metadaten; btrfs scrub verfügbar, aber nicht so tief wie ZFS | Nein – keine Datenprüfsummen; Fehler werden nicht erkannt, nur das unterliegende Hardware-RAID | Ja – OSD-ebene mit Prüfsummen; Ceph prüft Integrität auf Object-Ebene |

|| Snapshots & Rollback | Ja – eingebaut, atomar, praktisch instantan; zfs snapshot, zfs rollback | Ja – eingebaut, Copy-on-Write; btrfs subvolume snapshot | Nein – ext4 hat keine Snapshots; LVM oder Dateisystem-Tools müssen herhalten | Ja – 객체 스냅샷 auf OSD-Ebene; rbd snap für RBD-Volumes |

|| RAID-Z gegen klassisches RAID | RAID-Z1/2/3 ist Paritäts-Variante ohne Mirror, ähnlich RAID-5/6 aber mit verteiltem Parity-Block | RAID-5/6 in Btrfs war jahrelang problematisch; heute noch mit Warnhinweis; Btrfs-Mirror ist stabiler | ext4 kennt kein RAID; mdadm oder Hardware-RAID vorgeschaltet | Kein klassisches RAID-Konzept; Replikation auf OSD-Ebene (3x oft minimal) |

|| Deduplizierung | Optional, RAM-intensiv (ARC für Dedupe); oft nicht empfohlen für Homelab mit wenig RAM | Nein – Btrfs hat keine integrierte Daten-Deduplizierung | Nein | Nein (bzw. über Filestore/BlueStore ohne dedup – Gluster hat keine integrierte Dedupe) |

|| Kompression | Ja – LZ4 (Standard), Zstd, gzip; transparente Kompression auf Dataset-Ebene | Ja – zlib, zstd, LZO, kein Kompression; auch transparent | Nein – kein integriertes Feature; nur über Fremd-Tools (z.B. e2compr, nicht im Mainline) | Nein (BlueStore kann etwas komprimieren, aber nicht im Sinne einer Dateisystem-Option) |

|| RAM-Overhead | Hoch – ARC nutzt freien RAM als Lese-Cache (typisch 1 GB ARC pro 1 TB Daten, kann bis zu 50% des verfügbaren RAMs beanspruchen); Deduplizierung viel mehr | Mittel – Caches und Subvolumes weniger RAM-fressend als ZFS; ohne Dedupe moderat | Gering – Standard-Linux-Dateisystem, RAM-Verbrauch vor allem durch Page Cache (kernel), keine spezielle FS-RAM-Schraube | Very high – Ceph-Daemonen (OSD, Monitor, Manager) belegen signifikant RAM; ein Node kann 4-8 GB RAM für Ceph allein brauchen |

|| Speicherbedarf (Minimum) | Zwei Geräte für Mirror, drei für RAID-Z1; empfohlen mindestens 8 GB RAM für sinnvolle Betriebsgröße | Mindestens ein Gerät; Subvolumes und Snapshots laufen auf einem einzelnen Gerät; kein Minimum für RAID | Ein einzelnes Gerät; jedes Linux-System hat ext4 | Mindestens drei OSD-Node für definierte Verfügbarkeit (1 OSD = 1 Node empfohlen); empfohlen 3x Replikation für Produktionssicherheit |

|| Ausfallsicherheit | Mirror: zwei Kopien, sofort verfügbar nach Ausfall einer Platte; RAID-Z: Parität, Rebuild nach Ausfall möglich; Pool-Integrität geprüft durch Scrub | Mirror (Btrfs-Mirror): zwei Kopien, ähnlich ZFS-Mirror; RAID-5/6 nicht empfohlen; einzelnes Gerät = kein Schutz vor Ausfall | Keine Ausfallsicherheit auf Dateisystemebene; muss durch mdadm, LVM-Mirror oder Hardware-RAID ergänzt werden | Abhängig von Replikationsfaktor; mit 3x Replikation auf drei verschiedenen OSDs übersteht ein OSD-Ausfall; ohne ausreichende Replikation ist Ceph nicht resilient |

|| Restore-Zeit nach Katastrophe | Schnell bei Mirror (andere Kopie sofort verfügbar); bei RAID-Z und Pool-Totalverlust Forensik nötig; Send/Receive könnte Stunden bis Tage dauern für große Datenmengen | Schnell bei Mirror; bei einzelnem Gerät mit Snapshots schnell; bei komplettem Ausfall mit nur einer Kopie kein automatischer Restore | Keine eingebaute Schnellwiederherstellung; Restore aus Backup (andere Platte, anderes System) notwendig, Dauer abhängig von Backup-Größe und Netzwerk | Abhängig von Datengröße und Replikation; Ceph kann nach OSD-Ausfall automatisch neu haben, aber Katastrophe (mehrere OSDs) braucht Forensik |

Kurz zusammengefasst: ZFS ist die stärkste Überall-Lösung, wenn RAM und ECC da sind. Btrfs ist die Linux-natürliche Wahl, wenn man keine zusätzliche Installation will und Dinge wie Subvolumes und Snapshots ohne Overhead braucht. ext4 ist der Minimalist – es tut, was es soll, wenn man kein Copy-on-Write braucht. Ceph ist für Cluster, nicht für ein oder zwei Geräte.

ZFS: Was es wirklich kostet

ZFS hat einen guten Ruf, und er ist nicht unbegründet. Es ist ein Copy-on-Write-Dateisystem mit integriertem Volume-Management, das Prüfsummen auf alles legt, was es schreibt, Snapshots als Kernfeature hat und RAID-Z als Paritäts-Variante im Pool anbietet. Für Daten, die dont googeln kannst, wenn sie weg sind, ist ZFS oft die richtige Antwort.

Aber es gibt eine Lernkurve und einen konkreten Kostenfaktor, den viele übersehen: RAM.

RAM-ARC: Warum ZFS RAM will

ZFS nutzt freien RAM als ARC (Adaptive Replacement Cache) für Lesezugriffe. Das ist kein Speicherleck oder Bug – es ist Design. Wenn du auf dieselben Daten häufig zugreifst, hält ZFS sie im RAM und liefert Lesezugriffe im Millisekundenbereich statt auf Platte.

Die Faustregel: ARC kann bis zu 50% des verfügbaren RAMs belegen, wenn es voll ist. Für einen Pool mit 10 TB sind das typisch 2-5 GB ARC. Das klingt harmlos – bis du 8 GB RAM im System hast und dann 4 GB an ARC das System auffrisst. Dann greift ZFS auf Platte zurück, und Lesezugriffe werden langsamer.

Für einen typischen Homelab-Server mit 16 GB RAM und einem Pool unter 10 TB ist ZFS gut laufend. Mit 8 GB geht es auch, aber der Cache ist klein und der Puffer gegenüber anderen Diensten, die RAM brauchen (Nextcloud, PostgreSQL, Docker), ist knapp.

Wichtig: Deduplizierung (Dedup) ist ein optionales ZFS-Feature, das deutlich mehr RAM verbraucht – oft 5-10 GB oder mehr, abhängig von Datenmenge und Referenz-Set. Für einen Homelab-Einsatz ohne sehr große Datenmenge mit vielen Duplikaten (Backups, Snaphot-Chains) lohnt sich Dedup selten, und die RAM-Kosten überwiegen. ZFS ohne Dedup ist die realistische Wahl.

Fragmentierung und Pool-Exporte

ZFS ist Copy-on-Write – es schreibt neue Daten an neue Positionen, statt bestehende Blöcke zu überschreiben. Das ist gut für Integrität, aber es bedeutet auch, dass eine Platte über Zeit fragmentiert kann, wenn viele Schreibvorgänge an verschiedenen Positionen liegen.

In der Praxis: Für einen Pool mit vielen kleinen Schreibvorgängen (Datenbank, Nextcloud mit vielen Dateien) kann Fragmentierung über Monate spürbar werden. Für einen Pool mit größeren, sequenziellen Schreibvorgängen (Media, Archive) ist Fragmentierung ein geringeres Problem.

Pool-Exporte: ZFS-Pools können über zpool export exportiert und über zpool import wieder eingebunden werden. Das ist nützlich für Migrationen, aber man muss auf die Daten achten – ein Export während laufender Schreibvorgänge kann zu Inkonsistenzen führen, wenn nicht korrekt synchronisiert.

ZFS ohne ECC auf Privathardware – heikel, aber nicht unmöglich

Das ist ein Heikles Thema. ZFS puffert Daten im RAM, bevor sie auf Platte geschrieben werden. Wenn RAM einen Einzelbitfehler hat und ZFS die Daten vor dem Schreiben verfälscht, schreibt ZFS die falschen Daten – mit korrekter Prüfsumme für den falschen Inhalt. Die Prüfsumme merkt das nicht, weil das Schreiben korrekt verlief, aber die Daten sind schlecht.

ECC-RAM korrigiert Einzelbitfehler und erkennt Mehrbitfehler. Auf Server-Hardware ist ECC Standard. Auf Consumer-Hardware (Desktop-PC, Mini-PC, gebrauchter Server ohne ECC-Support) ist ECC oft nicht verfügbar.

Fazit: ZFS auf einem System ohne ECC-RAM ist ein akzeptiertes Risiko mit zwei Bedingungen:

1. Du hast ein separates Backup auf einem anderen Ort.

2. Die Daten, die du dort speicherst, sind nicht so kritisch, dass ein seltenes Bit-Flip katastrophal wäre.

Für einen Privathomelab mit 16 GB RAM, einem Mirror-Pool und einem regulären Backup auf einen zweiten Ort ist das ein realistischer Betrieb – solange man das Risiko kennt und akzeptiert. Für ein kleines Büro mit Geschäftsdaten ist ECC dringend empfohlen.

Wann ZFS passt – und wann nicht

ZFS passt, wenn:

ZFS passt weniger, wenn:

Btrfs: Subvolumes, Snapshots und die Dinge, die man kennen muss

Btrfs ist im Linux-Kernel enthalten, braucht keine zusätzliche Installation und bietet Cop-on-Write mit Prüfsummen, Subvolumes, Snapshots und Kompression. Für ein Linux-nativer Homelab-Einsatz ist es die sichtbare Wahl, wenn man kein ZFS installieren will oder kann.

Subvolumes und Snapshots

Btrfs-Subvolumes sind wie unabhängige Dateisystem-Bäume innerhalb eines Btrfs-Dateisystems. Jedes Subvolume kann eigenständig gemountet werden, hat eigene Eigenschaften und kann einzeln gesnapshotet werden.

Ein typisches Setup: Ein Subvolume für /, ein Subvolume für /home, und Snapshots von /home nach größeren Änderungen.


# Btrfs-Subvolume erstellen
sudo btrfs subvolume create /home/subvol_backup

# Snapshot des Subvolumes
sudo btrfs subvolume snapshot /home/subvol_backup /home/subvol_backup_snap_$(date +%Y%m%d)

# Liste der Subvolumes
sudo btrfs subvolume list /home

# Snapshot löschen
sudo btrfs subvolume delete /home/subvol_backup_snap_20260927

Snapshots in Btrfs sind Copy-on-Write – sie halten Referenzen auf die alten Datenblöcke und verbrauchen Speicher nur für geänderte Blöcke. Das ist effizient und schnell.

Kompression und atime

Btrfs-Kompression ist auf Subvolume-Ebene einstellbar. zstd ist für die meisten Fälle ein guter Kompromiss zwischen Kompressionsverhältnis und Performance:


# Kompression auf Subvolume setzen
sudo btrfs property set /home/subvol_backup compression zstd

# atime (Last-Access-Time) deaktivieren, um unnötige Schreibvorgänge zu vermeiden
sudo btrfs property set /home/subvol_backup atime never

Die Quota-Falle

Btrfs-Quotas sind ein mächtiges Feature, aber sie haben eine Falle: Quotas werden auf Subvolume-Ebene verwaltet und können sich überraschend verhalten, wenn Subvolumes verschachtelt sind oder wenn Snapshots Berücksichtigung finden.

Eine häufige Fehlerquelle: Man setzt ein Quota auf ein Subvolume, aber Snapshots des Subvolumes zählen zur Quota-Nutzung, weil sie auf die gleichen Datenblöcke verweisen. Das kann zu unerwarteten Quota-Überschreitungen führen, wenn Snapshots nicht gelöscht werden.

Regel: Wenn man Btrfs-Quotas nutzt, muss man Snapshots in die Rechnung einbeziehen und regelmäßig rotieren (ältere Snapshots löschen).

Btrfs gegen ext4: Wann Btrfs gewinnen muss

Btrfs gewinnt gegen ext4 in Szenarien, in denen ein oder mehrere der folgenden Features gebraucht werden:

ext4 gewinnt, wenn:

Das Metadatenproblem bei Millionen kleiner Dateien

Btrfs hat bekannte Performance-Probleme mit Metadaten bei sehr großen Zahlen kleiner Dateien – z.B. eine Nextcloud-Instanz mit Millionen von kleinen Dateien. Die Metadaten-Struktur von Btrfs ist auf solche Mengen nicht optimiert und kann zu langsamen Operationen führen (Verzeichnis-Listen, Metadata-Operationen).

Für einen Medien- oder Archivpool mit wenigen großen Dateien ist das kein Problem. Für einen Pool mit sehr vielen kleinen Dateien (Nextcloud, Git-Repositorys, Mail-Speicher) sollte man das beachten und ggf. ext4 oder ZFS in Betracht ziehen.

ext4: Der Minimalist

ext4 ist das Standard-Dateisystem auf den meisten Linux-Systemen. Es ist reif, stabil, hats keine Cop-on-Write-Features, keine Prüfsummen, keine Snapshots auf Dateisystemebene. Für viele Homelab-Setups, in denen die Daten entweder durch Snapshots auf anderer Ebene (LVM, Proxmox) oder durch Backup geschützt sind, reicht ext4.

tune2fs: Die Einstellungen für große Platten

ext4 auf großen Platten (über 2 TB) sollte mit bestimmten Einstellungen betrieben werden, um Performance und Wartung zu optimieren. Besonders zwei Parameter sind relevant: die Hash-Größe für Verzeichnisse und die Behandlung großer Dateien (Huge-Files).


# tune2fs: Hash-Größe für große Verzeichnisse erhöhen (Default oft zu klein für viele Dateien)
sudo tune2fs -O.has_journal_dev /dev/sdX1
sudo tune2fs -E inode_size=256 /dev/sdX1

# ext4 mit Large-File-Support und Performance-Optimierung
sudo tune2fs -O large_file -O dir_index /dev/sdX1

# Dateisystem-Check-Interval setzen (alle 2 Monate, 2 Wochen)
sudo tune2fs -c 60 -i 2m /dev/sdX1

# Maximale Mount-Counts für fsck festlegen
sudo tune2fs -e continue /dev/sdX1

Periodical fsck auf großen ext4-Partitionen: ext4 sollte regelmäßig einem Dateisystem-Check unterzogen werden (fsck -f), besonders nach unclean shutdowns. Bei großen Partitionen (über 2 TB) kann ein vollständiger fsck lange dauern (Stunden). Einerseits ist das für produktive Systeme unpraktisch; andererseits ist ein ausbleibender fsck-Risiko, weil Fehler nicht erkannt werden.

Für produktive Systeme mit большими ext4-Partitionen ist eine geplante Wartungsfenster für fsck empfehlenswert, oder man nutzt ein Dateisystem mit eingebautem Scrubbing (ZFS, Btrfs).

Ceph und Gluster: Ehrlich eingestuft

Ceph und GlusterFS sind verteilte Dateisysteme. Sie sind für Cluster gedacht, nicht für ein oder zwei Geräte.

Ceph: Für wen das Overhead-Gegenargument überhaupt greift

Ceph verteilt Daten auf OSDs (Object Storage Daemon) und repliziert oder paritätisiert sie. Standard ist 3x Replikation für Verfügbarkeit bei einem OSD-Ausfall. Das bedeutet: Für 1 TB nutzbarer Daten musst du 3 TB physischen Speicher haben (bei 3x Replikation).

Der Overhead ist nicht nur Speicher. Ceph-Daemonen (OSD, Monitor, Manager, Metadata-Server) belegen RAM und CPU. Ein einzelner OSD kann 1-2 GB RAM belegen; ein kleiner Cluster mit 3 OSDs und Monitor/Manager braucht signifikant mehr RAM als ein einzelner ZFS-Server.

Für wen Ceph:

Ceph für wen nicht:


# Ceph-Status schnell prüfen
sudo ceph -s

# RBD-Snapshot-Liste für ein Volume
sudo rbd snap ls my-disk

GlusterFS: Eine Alternative, aber nicht die erste Wahl

GlusterFS ist ein weiteres verteiltes Dateisystem, das auf zellularen Node-Architekturen basiert. Es hat weniger RAM-Overhead als Ceph, aber weniger eingebaute Funktionen für Datenintegrität (keine Prüfsummen auf Blöcken, keine integrierten Scrubs). Für einen verteilten Storage mit replizierenden Volumes ist Gluster in Betracht zu ziehen, aber für Homelab-Einsätze mit geringer Node-Anzahl ist ZFS oder Btrfs oft die einfachere Wahl mit besseren Integritätsgarantien.

Fünf häufige Fehler – und wie man sie vermeidet

1. ext4 auf großen Platten ohne fsck oder mit zu langem Check-Intervall

ext4 ohne regelmäßigen Dateisystem-Check ist riskant, weil Fehler nicht erkannt werden. tune2fs -c und -i steuern die Mount-Count- und Zeit-Intervalle für fsck. Für große Partitionen (über 2 TB) ist ein fsck ohne geplantes Wartungsfenster schwierig, aber nicht auszuschließen.

Regel: Check-Interval festlegen (tune2fs -c 60 -i 2m) und einen Wartungsplan für größere Dateisysteme machen.

2. Btrfs ohne Snapshots

Btrfs hat Snapshots als Kernfeature. Wenn man Btrfs nur als flaches Dateisystem nutzt, ohne Subvolumes und Snapshots, verpasst man einen Großteil des Nutzens. Insbesondere für System-Updates und Konfigurationsänderungen sind Snapshots ein praktisches Rollback-Tool.

Regel: Subvolumes für wichtige Daten erstellen, regelmäßige Snapshots anlegen, Snapshot-Rotation (ältere Snapshots löschen) betreiben.

3. ZFS ohne Scrubs

ZFS-Prüfsummen erkennen Korruption, aber nur wenn man aktiv danach sucht. Ein zpool scrub liest alle Daten und vergleicht Prüfsummen – das ist der Mechanismus, der stilllechte Datenkorruption aufdeckt und repariert (bei Mirror oder RAID-Z mit redundante Kopie).

Ohne Scrubs weißt du nicht, ob deine Daten korrupt sind, solange sie nicht gelesen werden. Regelmäßige Scrubs (monatlich oder alle paar Monate, abhängig von Datenmenge) sind Teil des ZFS-Betriebs.


# ZFS-Scrub starten
sudo zpool scrub my-pool

# Scrub-Status prüfen
sudo zpool status my-pool

4. Ceph ohne dreifache Replikation

Ceph mit einem Replikationsfaktor von 1 (keine Replikation) ist kein resilientes System. Mit 2x Replikation kann Ceph einen OSD-Ausfall überstehen, aber der Risikofaktor ist höher als bei 3x Replikation (z.B. wenn der zweite OSD zeitgleich ausfällt).

Standard für Produktions-Ceph ist 3x Replikation. Das kostet mehr Speicher, ist aber der Preis für definierte Verfügbarkeit bei OSD-Ausfall.

5. Snapshot-Spaces, die das Root-Laufwerk fressen

Snapshots (ZFS, Btrfs) verbrauchen Speicher für geänderte Datenblöcke. Wenn man Snapshots nicht rotiert und alte Snapshots liegenlassen, können sie beträchtlichen Speicherplatz belegen – besonders bei Subvolumes mit vielen Schreibvorgängen.

Regel: Snapshot-Rotation einplanen: Snapshots nach bestimmter Zeit (z.B. 7 Tage für kurze Rollback-Snapshots) löschen. Ein Snapshot, der noch für Rollbacks benötigt wird, aber nicht länger benötigt wird, sollte gelöscht werden. Für Backups gehört der Snapshot in ein separates Backup-Speicher, nicht auf demselben Pool.

Empfehlungen nach Einsatzzweck

Medien-NAS: Große Daten, seltene Änderungen, Zugriff gelegentlich massiv

Für einen Medien-Pool (Filme, Fotos, Musik) ohne aktive Änderungen ist Storage-Kapazität wichtiger als Echtzeit-Ausfallsicherheit.

Empfehlung:

Nicht empfohlen: Ceph für einen einzelnen Medien-Pool – Overhead überwiegt den Nutzen.

Proxmox-Datenpool: VM-Storage, Snapshots für VMs

Proxmox nutzt Storage-Pools für VM-Images. Die Wahl des Dateisystems unter Proxmox betrifft VM-Storage, Snapshot-Erstellung und Migration.

Empfehlung:

Einzelheiten zur Proxmox-Storage-Wahl findest du im Artikel Proxmox VE für kleine Unternehmen.

Container-Storage mit Docker: Datenvolumes, Images, ephemeral vs. persistent

Docker-Container haben zwei Datentypen: Images (readonly, pro Container) und Volumes (persistente Daten). Die Wahl des Dateisystems für Docker-Volumes betrifft Performance und Backup.

Empfehlung:

Maximale Billigkeit: Was geht mit wenig Geld?

Für das Budget-constrained Setup – ein gebrauchter Mini-PC oder ein älterer Server mit wenig RAM und zwei Platten – ist die Wahl eingeschränkt.

Empfehlung:

Nicht: ZFS auf 4-8 GB RAM ohne Backup und ohne Scrubs – das Risiko ist zu hoch für kritische Daten.

Großes Cluster: 3+ Node, gemeinsamer Storage

Für Cluster mit mehreren Node und gemeinsamem Storage ist Ceph die primäre Überlegung.

Empfehlung:

Nicht: Ceph mit weniger als 3 OSD-Node ohne klare Einsicht in das Verlustrisiko.

Kosten-Risiko: Übersicht je Dateisystem

|| System | RAM-Kosten (geschätzt) | Implementierungsaufwand | Wartungsaufwand | Wiederherstellungszeit (typisch) | größte Stärke | kritischster Schwachpunkt |

||---|---|---|---|---|---|---|

|| ZFS | 8-16 GB für sinnvolle Betriebsgröße; mehr für Dedup | Mittel (Pool-Konzept, Dataset, Send/Receive) | Regelmäßige Scrubs, Snapshot-Rotation, Send/Receive-Replikation | Schnell bei Mirror; bei Pool-Totalverlust Forensik nötig (Stunden bis Tage) | Integrität, Snapshots, Kompression | RAM-Bedarf, ECC-Problematik ohne ECC, Lernkurve |

|| Btrfs | 4-8 GB für kleinere Setups; weniger Overhead als ZFS | Mittel (Subvolumes, Snapshot-Management) | Snapshot-Rotation, Quotas beachten, Scrubs | Schnell bei Mirror und Snapshots; bei Einzelgerät ohne Backup kein Automatismus | Linux-natürlich, Subvolumes, Kompression | RAID-5/6-Implementierung, Metadaten-Problem bei vielen kleinen Dateien, Quotas |

|| ext4 | Gering (Standard-Page-Cache) | Gering (Standard-Dateisystem) | fsck-Intervalle, große Platten-Besondere | Keine eingebaute Schnellwiederherstellung; Restore aus Backup (abhängig von Backup-Größe) | Einfach, stabil, Standard | Keine Prüfsummen, keine Snapshots, keine Kompression auf FS-Ebene |

|| Ceph | 4-8 GB pro Node (OSD, Monitor, Manager); mehr bei größerer Clustergröße | Hoch (OSD-Addition, CRUSH-Map, Pool-Verwaltung, Replikation) | OSD-Verwaltung, Monitor-Status, Replikations-Faktor, Netzwerk-Überwachung | Automatische Wiederherstellung nach OSD-Ausfall (mit Replikation); bei mehreren OSDs ausfallen Forensik | Verteilte Verfügbarkeit, Cluster-Storage | Overhead (RAM, CPU, Netzwerk), Komplexität, Mindest-Node-Anzahl |

FAQ

Wann ist ext4 die richtige Wahl?

ext4 ist die richtige Wahl, wenn du ein einfaches, stabiles Dateisystem ohne Copy-on-Write-Features brauchst, wenn die Daten durch externes Backup (z.B. Proxmox-Backups, LVM-Snapshots, separates Backup-Speicher) geschützt sind, und wenn du die komplexität von ZFS oder Btrfs nicht brauchst oder nicht eingehen willst. ext4 ist vor allem für kleine bis mittlere Setups geeignet, in denen die Datenmenge überschaubar ist und Backup auf separater Ebene läuft.

Kann ich ZFS auf privater Hardware ohne ECC-RAM betreiben?

Ja, aber mit klar akzeptiertem Risiko. Der Risikofaktor ist: Einzelbitfehler im RAM können zu falsch geschriebenen Datenblöcken führen, die ZFS nicht erkennt, weil das Schreiben korrekt verlief. Für einen Privathomelab mit 8-16 GB RAM, einem Mirror-Pool und einem separaten Backup auf einem zweiten Ort ist das ein akzeptierbares Risiko – solange man es kennt. Für Geschäftsdaten oder kritische Daten ist ECC dringend empfohlen.

Wie oft sollte ich Btrfs-Snapshots machen?

Das hängt von der Datenveränderung ab. Für System-Subvolumes (z.B. /) nach größeren Updates oder Konfigurationsänderungen: Snapshot vor der Änderung, löschen nach wenigen Tagen, wenn der Rollback nicht mehr gebraucht wird. Für Daten-Subvolumes mit häufigen Änderungen: regelmäßige Snapshots nach einem festen Plan (z.B. täglich, wöchentlich), mit Rotation älterer Snapshots. Snapshots, die nicht mehr für aktive Rollbacks gebraucht werden, sollten gelöscht werden, um Speicherplatz zu sparen.

Wann lohnt sich Ceph für einen Homelab-Cluster?

Ceph lohnt sich für einen Homelab-Cluster, wenn du mindestens 3 Node hast, ein Netzwerk, das den Datenverkehr zwischen Node trägt (gängige 1 Gbit oder besser), und einen gemeinsamen verteilten Storage brauchst, der unabhängig von einzelnen Node-Ausfällen verfügbar ist. Für ein oder zwei Node ist Ceph zu komplex und hat kein definiertes Verfügbarkeitsniveau. Für kleinere Cluster mit 3 Node und begrenztem RAM ist Ceph möglich, aber RAM- und CPU-Overhead sind zu beachten.

Was ist mit Millionen kleiner Dateien in Btrfs?

Btrfs hat eingebaute Performance-Probleme mit Metadaten bei sehr großen Zahlen kleiner Dateien. Für eine Nextcloud-Instanz mit Millionen von Dateien, ein Git-Server mit vielen kleinen Dateien oder Mail-Speicher mit vielen kleinen E-Mails kann Btrfs langsam werden. Für solche Szenarien ist ext4 oder ZFS eine Überlegung, weil diese besser mit großen Metadaten-Anzahlen umgehen.

Interne Verlinkungen: BsN-Artikel als Vertiefung

Wenn du tiefer einsteigen willst, verweisen wir auf diese BsN-Artikel:

Meta-Vorschlag für Suchmaschinen

Schluss und CTA

Die Wahl des Dateisystems ist keine reine Hardware-Entscheidung – sie ist eine Infrastruktur-Entscheidung, die sich auf Betrieb, Wartung und Wiederherstellung auswirkt. Für die meisten Homelaber mit Linux-Hardware ist Btrfs oder ZFS die sichtbare Wahl; Ceph ist für Cluster mit mindestens 3 Node gedacht und bringt Overhead mit sich, der sich nur in Cluster-Szenarien lohnt. ext4 ist die Minimalwahl, wenn die Daten durch externes Backup geschützt sind und Cop-on-Write-Features nicht gebraucht werden.

Bist du unsicher, welches Dateisystem für dein Setup passt, oder willst du dein Homelab-Setup von jemandem betrachten, der das täglich macht? BsN aus Ebnath in der Oberpfalz berät Selfhoster und kleine Firmen bei Storage-Entscheidungen – von der Hardware-Auswahl über Dateisystem-Konfiguration bis hin zu Backup-Strategie. Schreib uns oder ruf an – wir schauen gemeinsam, was zu deinem Setup passt.

Bildvorschläge für den Artikel

1. Bildtyp: Vergleichsmatrix als Grafik

Was zu zeigen: Eine übersichtliche Matrix-Grafik, die ZFS, Btrfs, ext4 und Ceph gegen die Kriterien Datenintegrität, Snapshots, RAM-Overhead, RAID-Konzept und Wiederherstellungszeit abbildet. Farbcodierung: ZFS in Blau, Btrfs in Grün, ext4 in Orange-Gelb, Ceph in Violett.

Alt-Text: "Vergleichsmatrix: ZFS vs. Btrfs vs. ext4 vs. Ceph – Datenintegrität, Snapshots, RAM-Overhead und RAID-Konzept im Überblick"

2. Bildtyp: Entscheidungsbaum als Flussdiagramm

Was zu zeigen: Ein einfaches Flussdiagramm, das bei der Frage "Welches Dateisystem für mein Homelab?" startet und nach RAM-Verfügbarkeit, Node-Anzahl, Datenmenge und gewünschten Features (Snapshots, Kompression, Cluster) zu den vier Kandidaten führt. Kein realistisches Foto, sondern eine schematische Darstellung.

Alt-Text: "Entscheidungsbaum: Welches Dateisystem für mein Homelab? – Pfade zu ZFS, Btrfs, ext4 und Ceph nach RAM, Node-Anzahl und Features"

3. Bildtyp: Btrfs-Subvolume-Struktur als Schema

Was zu zeigen: Ein vereinfachtes Diagramm, das die Hierarchie von Btrfs-Subvolumes zeigt: Ein Btrfs-Dateisystem mit mehreren Subvolumes (z.B. /, /home, /var/lib/docker), die jeweils einen eigenen Snapshot haben. Pfeile zwischen Subvolumes und Snapshots. Schematisch, nicht fotorealistisch.

Alt-Text: "Schema: Btrfs-Subvolumes mit eigenen Snapshots – Hierarchie und Schnittstellen für Daten, Home und Docker-Volumes"

4. Bildtyp: ZFS-Pool-Architektur als Schema

Was zu zeigen: Ein Diagramm, das einen ZFS-Pool mit Mirror (zwei Platten) und einem Dataset mit Kompression und Snapshots zeigt. Datenfluss: Schreibvorgang → Copy-on-Write → neuer Block → Snapshot-Referenz. Schematisch, nicht fotorealistisch.

Alt-Text: "Schema: ZFS-Pool mit Mirror und Dataset – Copy-on-Write, Kompression und Snapshot-Referenz für Datenintegrität"

5. Bildtyp: Cluster-Storage-Vergleich als Leverage-Diagramm

Was zu zeigen: Ein Leverage-Diagramm oder einfache Spannbreite, das den RAM-Overhead, den Implementierungs-Aufwand und die Wiederherstellungszeit für ZFS (Single-Node mit Mirror), Btrfs (Single-Node) und Ceph (3-Node-Cluster) gegenüberstellt. Kein fotorealistisch, sondern schematisch oder als einfache Balken-/Flächengrafik.

Alt-Text: "Vergleich: RAM-Overhead, Implementierungs-Aufwand und Wiederherstellungszeit für ZFS, Btrfs und Ceph im Selfhosting – Single-Node vs. Cluster"

Artikel wurde für den BsN-Blog unter homelab.brillianze.de verfasst. Die Veröffentlichung erfolgt über das bestehende Deploy-Skript. Technische Daten basieren auf vorhandener Dokumentation und Praxis – keine erfundenen Benchmarks, keine exakten Preise. Bei konkreten Entscheidungen prüfen, welche Daten und Hardware vorliegen.

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.