TrueNAS Sizing Guide: wie viel Storage brauche ich wirklich?

Eine der ersten Fragen in jeder TrueNAS-Beratung ist zugleich die missverständlichste: “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 berücksichtigt. Beides führt in dieselbe Sackgasse: das System ist entweder nach 18 Monaten voll oder deutlich zu groß für den realen Bedarf gekauft.

Dieser Sizing Guide zeigt, wie man ehrlich rechnet: von der Nutzdaten-Baseline zur Rohkapazität, mit allen dazwischenliegenden Faktoren. Ohne Marketing-Zahlen, ohne Wunschdenken, ohne festen Preistabellen — denn Hardwarepreise schwanken zu stark für 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 Änderungsrate 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 fünf Jahren mehr als eine Verdreifachung.
• RAID-Overhead ist kein Feature, sondern eine Rechengröße. Je nach Layout gehen zwischen zehn und über vierzig Prozent der Rohkapazität 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 groß.

Schritt 1: die Nutzdaten-Baseline sauber erheben

Ausgangspunkt ist immer die reale, heute genutzte Datenmenge — nicht die Kapazität des bestehenden Systems, sondern das, was tatsächlich belegt ist. Und zwar getrennt nach Kategorie:

• Aktive Nutzdaten — Fileserver-Anteile, Datenbanken, VM-Images, Projektdaten
• Backup-Daten — Snapshots, PBS-Ziele, Replikations-Empfänger
• 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 Geschäft. Backup-Daten wachsen mit Retention und Änderungsrate. Archiv-Daten wachsen sprunghaft, wenn Projekte enden.

In der Praxis heißt das: ein Datenscan auf dem alten NAS oder Fileserver, aufgeteilt nach diesen Kategorien, und ein Gespräch mit den Fachabteilungen über laufende und geplante Projekte. Nur so kommt eine ehrliche Baseline heraus.

Schritt 2: den Snapshot-Overhead korrekt einschätzen

Snapshots sind das Killer-Feature von ZFS — und der am häufigsten unterschätzte Platzfresser. Ein Snapshot verbraucht zunächst wenig Platz, wächst aber mit jeder Änderung an den referenzierten Blöcken. Wer eine 30-Tage-Retention auf Fileserver-Daten fährt, hat schnell einen zweistelligen Prozentsatz an zusätzlichem Verbrauch.

Realistische Rahmenwerte aus der Praxis:

• Fileserver mit Bürodaten — 10 bis 25 Prozent Overhead bei 30 Tagen Retention
• VM-Storage mit hoher Änderungsrate — 30 bis 60 Prozent Overhead bei 14 Tagen Retention
• Datenbanken mit häufigen Writes — 40 bis 80 Prozent Overhead bei 7 Tagen Retention
• Archiv-Datasets — unter 5 Prozent Overhead, weil kaum Änderungen

Das ist kein Naturgesetz — die Werte hängen konkret vom Change-Rate ab. Wer es genau wissen will, kann auf einem bestehenden System eine Woche lang messen und hochrechnen. Für 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, verschlüsselte 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 Größe. Wir rechnen intern konservativ mit Faktor 1,4 für gemischte Umgebungen — alles was drüber 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 schätzen ihr eigenes Wachstum fast immer zu niedrig ein. Studien und unsere eigene Beobachtung über Jahre hinweg zeigen: 20 bis 40 Prozent pro Jahr ist ein realistischer Rahmen für typische Mittelstands-IT.

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

Praktische Konsequenz für das Sizing:

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

Wer eine TrueNAS-Appliance mit einer Abschreibungsdauer von fünf Jahren kauft, muss auf mindestens den unteren Fünf-Jahres-Multiplikator planen. Alles darunter führt zu vorzeitiger Nacherweiterung, die im Enterprise-Bereich fast immer teurer ist als eine großzügigere Erst-Auslegung. Warum das gerade bei TrueNAS gilt, haben wir im Artikel TrueNAS für KMU diskutiert.

Schritt 5: RAID-Overhead und Pool-Layout einrechnen

Der letzte Schritt vom Netto-Bedarf zur Rohkapazität 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 Nutzkapazität und Ausfallsicherheit.

Grobe Overhead-Rahmen für typische Layouts:

• RAID-Z1 mit 5 Platten — ca. 20 Prozent Overhead, geeignet für unkritische Workloads
• RAID-Z2 mit 6 Platten — ca. 33 Prozent Overhead, Standard für 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, höchste IOPS für VM-Storage

Wichtig: RAID-Z1 ist bei großen HDDs nicht mehr Stand der Technik. Sobald eine Platte ausfällt und das Resilvern beginnt, ist das gesamte Array anfällig für einen zweiten Fehler — und Rebuild-Zeiten von 12-Terabyte-Platten liegen im zweistelligen Stundenbereich. Für Business-Storage ist RAID-Z2 der neue Baseline-Standard. Details zur Layout-Entscheidung liefert der Beitrag RAID vs ZFS: warum noch klassisches RAID?.

Zusätzlich: ZFS reserviert etwa 20 Prozent des Pools für Performance und Freiraum. Wer einen Pool über 80 Prozent Belegung fährt, verliert deutlich an Schreibperformance. Dieser Slack gehört 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 Änderungsrate, gesetzliche Aufbewahrungsfristen.

Baseline: 5 TB aktive Nutzdaten Wachstum über fünf 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 Rohkapazität 80-Prozent-Slack (Reserve für Pool-Freiraum): ergibt 22,9 TB Rohkapazität als Zielwert

Die naive Rechnung “5 TB mal zwei” hätte 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 durchhält.

Wo unser Konfigurator die Rechnung übernimmt

Genau diese Rechnung — Baseline, Snapshot, Kompression, Wachstum, RAID — ist im TrueNAS Konfigurator hinterlegt. Sie geben Ihre aktuellen Nutzdaten und Ihr Nutzungsprofil ein, wählen einen Zielhorizont und einen erwarteten Wachstumsfaktor. Der Konfigurator rechnet die Rohkapazität und schlägt eine passende TrueNAS-Modellklasse vor — vom F-Series-Kompaktsystem über H-Series-Hybrid bis zur M-Serie mit M30 oder M40 für größere Umgebungen.

Was der Konfigurator bewusst nicht macht: Wunschdenken bestärken. Wer 5 TB Nutzdaten hat und ein System mit 200 TB Rohkapazität konfiguriert, bekommt eine Warnung. Überdimensionierung kostet Geld, das ehrlicher in eine sinnvolle Backup-Strategie oder in HA gehört. Wer umgekehrt eine offensichtliche Unterdimensionierung anlegt, wird ebenfalls darauf hingewiesen.

Feste Preistabellen finden Sie im Konfigurator übrigens nicht — die tatsächlichen Hardwarepreise schwanken zu stark, um sie sinnvoll öffentlich einzupflegen. Für belastbare Zahlen gehen die Konfigurationen als individuelles Angebot über unsere Beratung. Wer die Systemklassen vorher besser einordnen möchte, findet in Home-Lab vs Enterprise TrueNAS den passenden Rahmen.

Wann Sizing schiefgeht — vier typische Fehler aus der Praxis

Aus Dutzenden Projekten können wir vier wiederkehrende Sizing-Fehler nennen:

1. Wachstum als linear angenommen — 25 Prozent pro Jahr sind über fünf 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 groß gedacht, aber Overhead klein gerechnet. Beides muss zusammenpassen.
4. RAID-Z1 auf großen Platten — rechnet sich auf den ersten Blick günstig, ist bei modernen HDD-Kapazitäten aber Risiko.

Wenn Sie in einem laufenden Sizing-Prozess sind: prüfen Sie diese vier Punkte, bevor die Bestellung rausgeht. Nachträgliche Korrekturen sind teuer.

Fazit: ehrlich rechnen statt Bauchgefühl

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 berücksichtigt, kommt zu einem belastbaren Zielwert — und vermeidet die zwei teuersten Fehler: Nacherweiterung nach 18 Monaten oder Überdimensionierung um Faktor drei.

Der TrueNAS Konfigurator nimmt Ihnen die Rechnung ab und liefert eine Systemklassen-Empfehlung mit realistischer Kapazitätsplanung. Für die individuelle Beratung sind wir als Gold-zertifizierter iXsystems-Partner in Bayern und deutschlandweit ansprechbar — über unseren IT-Service oder direkt über die Konfigurator-Anfrage.

FAQ

Wie genau muss meine Nutzdaten-Baseline sein?

Für 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 Änderungsrate können 30 bis 60 Prozent Overhead bei zweiwöchiger Retention entstehen. Wer es genau wissen will, sollte auf einem Test-Dataset einmal über eine Woche messen und hochrechnen. Konservativ rechnen wir intern mit dem oberen Rand.

Ist Kompression bei ZFS immer sinnvoll?

Ja, LZ4 ist standardmäßig 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. Für die Sizing-Rechnung sollte man Kompression konservativ ansetzen.

Warum kein RAID-Z1 mehr auf großen 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 für 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 spürbar, weil ZFS Platz für Metadaten und Copy-on-Write benötigt. Ab 90 Prozent wird es kritisch. Der 20-Prozent-Slack gehört zwingend in die Sizing-Planung — er ist keine Reserve, sondern Betriebsanforderung.

Welche TrueNAS-Modellklasse passt zu meinem Sizing-Ergebnis?

Grob gilt: unter 20 TB Rohkapazität passen F-Series oder kleine H-Series, 20 bis 100 TB sind der Kernbereich von H-Series und M30, darüber ist die M40 die typische Wahl. Große Archive gehen in Richtung X-Serie. Der Konfigurator macht die Zuordnung automatisch und berücksichtigt auch Netzwerk- und HA-Anforderungen.