OpenZFS

Entstehung und Beteiligte

ZFS wurde ab 2001 bei Sun Microsystems von einem Team um Jeff Bonwick und Matt Ahrens entwickelt und 2004 angekündigt. OpenSolaris veröffentlichte den Code 2005. Nach Oracles Schließung der Entwicklung entstand 2013 OpenZFS als gemeinsames Projekt.

Welches Problem sollte gelöst werden?

Volume Manager und Dateisystem waren getrennt, stille Bitfehler blieben oft unbemerkt und große Speicherpools waren schwer zu verwalten. ZFS sollte Integrität, Pooling, Snapshots und RAID in einer Architektur verbinden.

Technische Hürden und Lösungen

Copy-on-Write und End-to-End-Prüfsummen benötigen Speicher und sorgfältige Recoverylogik. RAIDZ, Scrubs, ARC und Transaktionsgruppen unterscheiden sich von klassischen RAID-Systemen. RAM-Mythen ersetzen keine belastbare Dimensionierung.

Standardisierung und Einordnung

Speichersysteme müssen Daten trotz Defekten, Bedienfehlern und Ausfällen erhalten. Historisch verlagerte sich der Fokus von einzelnen Datenträgern zu Verbünden, Snapshots, Prüfsummen, Replikation und verteilten Objekten. Redundanz ist dennoch kein Backup: Sie schützt meist vor Hardwareausfall, nicht automatisch vor Löschen, Verschlüsselungstrojanern oder fehlerhaften Anwendungen.

Technik im praktischen Betrieb

Speicher muss anhand von Fehlerdomänen geplant werden: Datenträger, Controller, Host, Rack, Standort, Zugangsdaten und Verwaltungssoftware können jeweils gemeinsam ausfallen. Prüfsummen erkennen bestimmte Beschädigungen, Replikation erhält Verfügbarkeit und Snapshots ermöglichen schnelle Rücksprünge; keine dieser Funktionen ersetzt automatisch eine unabhängige Sicherung. Regelmäßige Scrubs, SMART- beziehungsweise Gerätezustände, Kapazitätsreserven und Restoretests gehören zum Betrieb. Besonders wichtig ist ein dokumentierter Weg, Daten auch dann wiederherzustellen, wenn die ursprüngliche Verwaltungsoberfläche nicht mehr startet.

Warum das Thema heute noch relevant ist

Die Bedeutung wächst mit der Datenmenge, aber auch mit gesetzlichen und betrieblichen Anforderungen. Historische Speicherfehler zeigen, dass „das Laufwerk funktioniert“ keine ausreichende Integritätsaussage ist. Prüfsummen, Versionen und unabhängige Kopien beantworten verschiedene Risiken. Ein belastbares Konzept definiert deshalb, welche Daten wie lange aufbewahrt werden, wie schnell sie zurückkehren müssen und wer eine Wiederherstellung auch unter Zeitdruck durchführen kann.

Daten und Meilensteine

• 2001 beginnt die Entwicklung bei Sun.
• 2005 wird ZFS mit OpenSolaris veröffentlicht.
• 2013 entsteht OpenZFS.
• Snapshots sind keine unabhängigen Backups, wenn sie im selben Pool liegen.

Pools, VDEVs und Datasets

Datenträger bilden VDEVs, aus denen ein Pool entsteht. Datasets erhalten eigene Eigenschaften wie Kompression, Quota oder Snapshot-Regeln. Die Redundanz eines Pools wird durch seine VDEV-Struktur bestimmt und lässt sich später nicht beliebig umformen.

Prüfsummen und Scrubs

ZFS prüft Daten und Metadaten beim Lesen. Ein Scrub liest den gesamten belegten Bestand und vergleicht Prüfsummen. Bei Spiegeln oder RAID-Z kann eine fehlerhafte Kopie aus intakten Daten rekonstruiert werden.

Snapshots sind kein externes Backup

Snapshots schützen gut vor versehentlichen Änderungen, liegen aber im selben Pool. Gegen Totalausfall, Diebstahl oder Verschlüsselung braucht es replizierte oder separat gesicherte Kopien.