TrueNAS Sizing Guide: wie viel Storage brauche ich wirklich?

Eine der ersten Fragen in jeder TrueNAS-Beratung ist zugleich die missverstaendlichste: “Wie viel Storage brauchen wir?” Und fast immer folgt darauf eine unrealistische Zahl. Entweder wird die aktuelle Datenmenge einfach genommen und verdoppelt — oder es kommt eine Wunschzahl auf den Tisch, die weder Snapshots, noch Wachstum, noch RAID-Overhead beruecksichtigt. Beides fuehrt in dieselbe Sackgasse: das System ist entweder nach 18 Monaten voll oder deutlich zu gross fuer den realen Bedarf gekauft.

Dieser Sizing Guide zeigt, wie man ehrlich rechnet: von der Nutzdaten-Baseline zur Rohkapazitaet, mit allen dazwischenliegenden Faktoren. Ohne Marketing-Zahlen, ohne Wunschdenken, ohne festen Preistabellen — denn Hardwarepreise schwanken zu stark fuer belastbare Zahlen im Blog.

Warum die naive Rechnung “wir haben 20 TB, wir brauchen 40 TB” nicht funktioniert

Die klassische Faustformel “aktuelle Datenmenge mal zwei” ignoriert vier Dinge, die auf einem ZFS-basierten System jedoch entscheidend sind:

• Snapshots belegen Platz — teilweise erheblich, je nach Aenderungsrate und Retention.
• Kompression spart Platz — teilweise erheblich, aber nicht garantiert und nicht auf allen Datentypen.
• Wachstum ist nicht linear, sondern kumulativ. 25 Prozent Wachstum pro Jahr sind nach fuenf Jahren mehr als eine Verdreifachung.
• RAID-Overhead ist kein Feature, sondern eine Rechengroesse. Je nach Layout gehen zwischen zehn und ueber vierzig Prozent der Rohkapazitaet an Redundanz.

Wer diese vier Faktoren sauber trennt und einzeln berechnet, kommt zu einem belastbaren Zielwert. Wer sie zusammenwirft oder ignoriert, kauft entweder zu klein oder deutlich zu gross.

Schritt 1: die Nutzdaten-Baseline sauber erheben

Ausgangspunkt ist immer die reale, heute genutzte Datenmenge — nicht die Kapazitaet des bestehenden Systems, sondern das, was tatsaechlich belegt ist. Und zwar getrennt nach Kategorie:

• Aktive Nutzdaten — Fileserver-Anteile, Datenbanken, VM-Images, Projektdaten
• Backup-Daten — Snapshots, PBS-Ziele, Replikations-Empfaenger
• Archiv-Daten — Alt-Projekte, gesetzliche Aufbewahrung, kalt lagernde Volumes

Diese Trennung ist wichtig, weil die Anteile sich sehr unterschiedlich verhalten. Aktive Nutzdaten wachsen linear mit dem Geschaeft. Backup-Daten wachsen mit Retention und Aenderungsrate. Archiv-Daten wachsen sprunghaft, wenn Projekte enden.

In der Praxis heisst das: ein Datenscan auf dem alten NAS oder Fileserver, aufgeteilt nach diesen Kategorien, und ein Gespraech mit den Fachabteilungen ueber laufende und geplante Projekte. Nur so kommt eine ehrliche Baseline heraus.

Schritt 2: den Snapshot-Overhead korrekt einschaetzen

Snapshots sind das Killer-Feature von ZFS — und der am haeufigsten unterschaetzte Platzfresser. Ein Snapshot verbraucht zunaechst wenig Platz, waechst aber mit jeder Aenderung an den referenzierten Bloecken. Wer eine 30-Tage-Retention auf Fileserver-Daten faehrt, hat schnell einen zweistelligen Prozentsatz an zusaetzlichem Verbrauch.

Realistische Rahmenwerte aus der Praxis:

• Fileserver mit Buerodaten — 10 bis 25 Prozent Overhead bei 30 Tagen Retention
• VM-Storage mit hoher Aenderungsrate — 30 bis 60 Prozent Overhead bei 14 Tagen Retention
• Datenbanken mit haeufigen Writes — 40 bis 80 Prozent Overhead bei 7 Tagen Retention
• Archiv-Datasets — unter 5 Prozent Overhead, weil kaum Aenderungen

Das ist kein Naturgesetz — die Werte haengen konkret vom Change-Rate ab. Wer es genau wissen will, kann auf einem bestehenden System eine Woche lang messen und hochrechnen. Fuer die Sizing-Planung reichen die Rahmenwerte als konservative Annahme. Details dazu haben wir im Beitrag zu TrueNAS Snapshot-Schedule und Best Practices beschrieben.

Schritt 3: den Kompressions-Rahmen ehrlich ansetzen

ZFS-Kompression — in aller Regel LZ4 oder ZSTD — ist verlustfrei und sehr schnell. Sie spart auf vielen Datentypen deutlich Platz, auf anderen fast keinen. Ehrliche Richtwerte:

• Textdaten, Office-Dokumente, Logs, Datenbanken — Faktor 1,5 bis 2,5
• VM-Images mit typischen OS-Installationen — Faktor 1,3 bis 2,0
• Bereits komprimierte Medien — JPEG, MP4, ZIP, verschluesselte Daten — Faktor 1,0 bis 1,05
• Gemischte Fileserver-Datasets — Faktor 1,4 bis 1,8

Wichtig: Kompression darf man in der Sizing-Rechnung als Puffer einsetzen, nicht als fixe Groesse. Wir rechnen intern konservativ mit Faktor 1,4 fuer gemischte Umgebungen — alles was drueber kommt, ist Reserve. Wer den Konfigurator nutzt und einen erwarteten Faktor eingibt, sollte diesen Wert immer eher zu niedrig als zu hoch ansetzen. Mehr technischen Hintergrund liefert der Beitrag ZFS-Komprimierung: Speichereffizienz und Performance.

Schritt 4: Wachstum realistisch modellieren — 20 bis 40 Prozent pro Jahr

Der Punkt, der in der Sizing-Diskussion am meisten Widerspruch erzeugt: Datenwachstum. Kunden schaetzen ihr eigenes Wachstum fast immer zu niedrig ein. Studien und unsere eigene Beobachtung ueber Jahre hinweg zeigen: 20 bis 40 Prozent pro Jahr ist ein realistischer Rahmen fuer typische Mittelstands-IT.

Rechenbeispiel: Bei 30 Prozent Wachstum pro Jahr wird aus 10 TB Nutzdaten heute in fuenf Jahren nicht 25 TB, sondern 37 TB. Nach sieben Jahren sind es 62 TB. Der Zinseszins-Effekt schlaegt gnadenlos zu.

Praktische Konsequenz fuer das Sizing:

• Zielhorizont drei Jahre — Multiplikator 1,7 bis 2,7 auf die Nutzdaten-Baseline
• Zielhorizont fuenf Jahre — Multiplikator 2,5 bis 5,4
• Zielhorizont sieben Jahre — Multiplikator 3,6 bis 10,5

Wer eine TrueNAS-Appliance mit einer Abschreibungsdauer von fuenf Jahren kauft, muss auf mindestens den unteren Fuenf-Jahres-Multiplikator planen. Alles darunter fuehrt zu vorzeitiger Nacherweiterung, die im Enterprise-Bereich fast immer teurer ist als eine grosszuegigere Erst-Auslegung. Warum das gerade bei TrueNAS gilt, haben wir im Artikel TrueNAS fuer KMU diskutiert.

Schritt 5: RAID-Overhead und Pool-Layout einrechnen

Der letzte Schritt vom Netto-Bedarf zur Rohkapazitaet ist der RAID-Overhead. Bei ZFS ist das kein klassisches RAID, sondern RAID-Z1, RAID-Z2, RAID-Z3 oder Mirrors — mit deutlich unterschiedlichen Auswirkungen auf Nutzkapazitaet und Ausfallsicherheit.

Grobe Overhead-Rahmen fuer typische Layouts:

• RAID-Z1 mit 5 Platten — ca. 20 Prozent Overhead, geeignet fuer unkritische Workloads
• RAID-Z2 mit 6 Platten — ca. 33 Prozent Overhead, Standard fuer Business-Storage
• RAID-Z2 mit 8 Platten — ca. 25 Prozent Overhead, guter Kompromiss
• RAID-Z3 mit 8 Platten — ca. 37 Prozent Overhead, Enterprise-Archiv
• Mirror-Layout — 50 Prozent Overhead, hoechste IOPS fuer VM-Storage

Wichtig: RAID-Z1 ist bei grossen HDDs nicht mehr Stand der Technik. Sobald eine Platte ausfaellt und das Resilvern beginnt, ist das gesamte Array anfaellig fuer einen zweiten Fehler — und Rebuild-Zeiten von 12-Terabyte-Platten liegen im zweistelligen Stundenbereich. Fuer Business-Storage ist RAID-Z2 der neue Baseline-Standard. Details zur Layout-Entscheidung liefert der Beitrag RAID vs ZFS: warum noch klassisches RAID?.

Zusaetzlich: ZFS reserviert etwa 20 Prozent des Pools fuer Performance und Freiraum. Wer einen Pool ueber 80 Prozent Belegung faehrt, verliert deutlich an Schreibperformance. Dieser Slack gehoert in die Sizing-Rechnung mit hinein.

Rechenbeispiel: von 5 TB Nutzdaten zur Roh-Auslegung

Nehmen wir ein realistisches KMU-Szenario: eine Kanzlei mit 5 TB aktiven Nutzdaten heute, Fileserver-Charakteristik, moderate Aenderungsrate, gesetzliche Aufbewahrungsfristen.

Baseline: 5 TB aktive Nutzdaten Wachstum ueber fuenf Jahre (25 Prozent p.a.): Faktor 3,05 — ergibt 15,3 TB Snapshot-Overhead (20 Prozent): ergibt 18,3 TB Kompressions-Faktor (1,5): reduziert auf 12,2 TB Netto-Bedarf im Pool RAID-Z2-Overhead (33 Prozent): ergibt 18,3 TB Rohkapazitaet 80-Prozent-Slack (Reserve fuer Pool-Freiraum): ergibt 22,9 TB Rohkapazitaet als Zielwert

Die naive Rechnung “5 TB mal zwei” haette 10 TB ergeben — die realistische Rechnung landet bei rund 23 TB. Das ist der Unterschied zwischen einem System, das nach zwei Jahren voll ist, und einem, das die geplante Abschreibungsperiode ohne Nacherweiterung durchhaelt.

Wo unser Konfigurator die Rechnung uebernimmt

Genau diese Rechnung — Baseline, Snapshot, Kompression, Wachstum, RAID — ist im TrueNAS Konfigurator hinterlegt. Sie geben Ihre aktuellen Nutzdaten und Ihr Nutzungsprofil ein, waehlen einen Zielhorizont und einen erwarteten Wachstumsfaktor. Der Konfigurator rechnet die Rohkapazitaet und schlaegt eine passende TrueNAS-Modellklasse vor — vom F-Series-Kompaktsystem ueber H-Series-Hybrid bis zur M-Serie mit M30 oder M40 fuer groessere Umgebungen.

Was der Konfigurator bewusst nicht macht: Wunschdenken bestaerken. Wer 5 TB Nutzdaten hat und ein System mit 200 TB Rohkapazitaet konfiguriert, bekommt eine Warnung. Ueberdimensionierung kostet Geld, das ehrlicher in eine sinnvolle Backup-Strategie oder in HA gehoert. Wer umgekehrt eine offensichtliche Unterdimensionierung anlegt, wird ebenfalls darauf hingewiesen.

Feste Preistabellen finden Sie im Konfigurator uebrigens nicht — die tatsaechlichen Hardwarepreise schwanken zu stark, um sie sinnvoll oeffentlich einzupflegen. Fuer belastbare Zahlen gehen die Konfigurationen als individuelles Angebot ueber unsere Beratung. Wer die Systemklassen vorher besser einordnen moechte, findet in Home-Lab vs Enterprise TrueNAS den passenden Rahmen.

Wann Sizing schiefgeht — vier typische Fehler aus der Praxis

Aus Dutzenden Projekten koennen wir vier wiederkehrende Sizing-Fehler nennen:

1. Wachstum als linear angenommen — 25 Prozent pro Jahr sind ueber fuenf Jahre eine Verdreifachung, nicht plus 125 Prozent.
2. Kompression zu hoch angesetzt — Faktor 3 auf gemischten Datasets ist Wunschdenken, Faktor 1,4 bis 1,8 ist realistisch.
3. Snapshots als Backup missverstanden — Retention gross gedacht, aber Overhead klein gerechnet. Beides muss zusammenpassen.
4. RAID-Z1 auf grossen Platten — rechnet sich auf den ersten Blick guenstig, ist bei modernen HDD-Kapazitaeten aber Risiko.

Wenn Sie in einem laufenden Sizing-Prozess sind: pruefen Sie diese vier Punkte, bevor die Bestellung rausgeht. Nachtraegliche Korrekturen sind teuer.

Fazit: ehrlich rechnen statt Bauchgefuehl

TrueNAS-Sizing ist keine schwarze Kunst, aber es ist auch keine einfache Multiplikation. Wer Baseline, Snapshot-Overhead, Kompressions-Rahmen, Wachstumsrate und RAID-Overhead sauber trennt und einzeln beruecksichtigt, kommt zu einem belastbaren Zielwert — und vermeidet die zwei teuersten Fehler: Nacherweiterung nach 18 Monaten oder Ueberdimensionierung um Faktor drei.

Der TrueNAS Konfigurator nimmt Ihnen die Rechnung ab und liefert eine Systemklassen-Empfehlung mit realistischer Kapazitaetsplanung. Fuer die individuelle Beratung sind wir als Gold-zertifizierter iXsystems-Partner in Bayern und deutschlandweit ansprechbar — ueber unseren IT-Service oder direkt ueber die Konfigurator-Anfrage.

FAQ

Wie genau muss meine Nutzdaten-Baseline sein?

Fuer die Sizing-Planung reicht eine Genauigkeit im Bereich +/- 10 Prozent. Wichtiger als der exakte Wert ist die saubere Trennung nach aktiven Daten, Backup und Archiv — diese drei Kategorien wachsen unterschiedlich schnell.

Wie hoch ist der Snapshot-Overhead auf einem VM-Storage wirklich?

Auf VM-Storage mit hoher Aenderungsrate koennen 30 bis 60 Prozent Overhead bei zweiwoechiger Retention entstehen. Wer es genau wissen will, sollte auf einem Test-Dataset einmal ueber eine Woche messen und hochrechnen. Konservativ rechnen wir intern mit dem oberen Rand.

Ist Kompression bei ZFS immer sinnvoll?

Ja, LZ4 ist standardmaessig aktiv und praktisch kostenlos — selbst wenn kaum Ersparnis entsteht. ZSTD spart mehr, kostet aber CPU. Auf bereits komprimierten Medien — JPEG, MP4, ZIP — bringt Kompression fast nichts, schadet aber auch nicht. Fuer die Sizing-Rechnung sollte man Kompression konservativ ansetzen.

Warum kein RAID-Z1 mehr auf grossen HDDs?

Weil Resilvern nach einem Plattenausfall bei 12- oder 16-Terabyte-Platten viele Stunden bis Tage dauert — und in dieser Zeit ein zweiter Ausfall das gesamte Array verliert. RAID-Z2 gibt einen zweiten Redundanz-Level und ist heute Baseline fuer Business-Storage. Details im Beitrag RAID vs ZFS.

Was passiert, wenn ein ZFS-Pool zu voll wird?

Ab etwa 80 Prozent Belegung sinkt die Schreibperformance spuerbar, weil ZFS Platz fuer Metadaten und Copy-on-Write benoetigt. Ab 90 Prozent wird es kritisch. Der 20-Prozent-Slack gehoert zwingend in die Sizing-Planung — er ist keine Reserve, sondern Betriebsanforderung.

Welche TrueNAS-Modellklasse passt zu meinem Sizing-Ergebnis?

Grob gilt: unter 20 TB Rohkapazitaet passen F-Series oder kleine H-Series, 20 bis 100 TB sind der Kernbereich von H-Series und M30, darueber ist die M40 die typische Wahl. Grosse Archive gehen in Richtung X-Serie. Der Konfigurator macht die Zuordnung automatisch und beruecksichtigt auch Netzwerk- und HA-Anforderungen.