TrueNAS

1. TrueNAS heute: SCALE als Hauptplattform, CORE als Altbestand

TrueNAS ist weiterhin eine der stärksten Self-Hosted-Plattformen für ZFS-basierten Storage. Für neue Installationen sollte man Stand 2026 aber klar zwischen TrueNAS SCALE und TrueNAS CORE unterscheiden:

  • SCALE: Linux-basierte Hauptplattform und Standardempfehlung für Neuinstallationen.
  • CORE: sinnvoll vor allem für bestehende Installationen; neue Feature-Entwicklung spielt klar auf SCALE.

Das ist mehr als eine Geschmacksfrage. Aktuelle TrueNAS-Entwicklung, moderne App-Workflows und die allgemeine Plattformrichtung liegen eindeutig bei SCALE. CORE ist für reine Storage-Altbestände weiter nutzbar, aber kein naheliegender Startpunkt mehr, wenn man heute ein neues Homelab oder einen neuen NAS aufsetzt.

2. ZFS-Grundlagen für sinnvolle Entscheidungen

TrueNAS steht und fällt mit ZFS. Wer die wichtigsten Begriffe versteht, trifft spätere Architekturentscheidungen deutlich besser:

  • Pool: oberste Speichereinheit, zusammengesetzt aus einem oder mehreren vdevs.
  • vdev: Redundanz- und Performance-Baustein, etwa Mirror, RAIDZ1, RAIDZ2 oder RAIDZ3.
  • Dataset: flexibles Dateisystem mit eigenen Eigenschaften wie Kompression oder Quota.
  • zvol: Blockdevice für iSCSI oder VM-Storage.
  • Snapshot: schreibgeschützter Zeitpunkt eines Datasets oder zvols.

Der wichtigste ZFS-Satz im Alltag lautet: Die Redundanz steckt im vdev, nicht im Pool-Namen. Wer einen Pool aus mehreren vdevs baut, vergrößert Kapazität und parallele Leistung, übernimmt aber auch die Konsequenzen des gewählten vdev-Typs.

Für die meisten Self-Hosted-Setups gilt:

  • Mirror für kleine, schnelle Pools und flexible Erweiterung,
  • RAIDZ2 für größere kapazitätsorientierte Datenspeicher,
  • Dedup nur in sehr begründeten Sonderfällen,
  • Kompression fast immer aktivieren, typischerweise lz4 oder zstd.

3. Pools, Datasets und sinnvolle Storage-Layouts

Ein TrueNAS-System wird deutlich wartbarer, wenn man nicht alles in ein einziges Dataset kippt. Besser ist eine klare Struktur nach Workload und Schutzbedarf. 

tank/
  data/
    documents
    media
    photos
  apps/
  backups/
  vm/
  iscsi/

Vorteile dieser Trennung:

  • pro Dataset eigene Kompression, Quotas und Snapshots,
  • bessere Replikations- und Backup-Strategien,
  • saubere Abgrenzung zwischen Nutzdaten, App-Daten und VM-Storage.

Gute Basiseinstellungen:

  • ashift passend zur realen Sektorgröße,
  • Kompression standardmäßig aktiv,
  • atime nur wenn nötig, sonst aus,
  • recordsize nicht blind global ändern, sondern workloadbezogen.

Für Backups und Medien ist ZFS hervorragend. Für sehr I/O-intensive Datenbanken oder viele zufällige VM-Writes sollte man genauer auf vdev-Layout, RAM und SSD/NVMe-Strategie schauen.

4. SMB, NFS und iSCSI sauber bereitstellen

TrueNAS unterstützt alle gängigen Freigabeprotokolle, aber jedes hat seinen idealen Einsatzzweck:

  • SMB: Standard für Windows, Office-Dateien und klassische Benutzerfreigaben.
  • NFS: gut für Linux-Clients, Proxmox-Storage oder bestimmte VMware-Szenarien.
  • iSCSI: für Block-Storage, z. B. an Hypervisoren oder Spezialanwendungen.

Gute Praxis ist, das Protokoll nicht nur nach "geht irgendwie" auszuwählen, sondern nach Zugriffsmodell:

  • Dateifreigabe für Menschen: SMB.
  • Dateisysteme für Linux-Hosts oder bestimmte Datastores: NFS.
  • Block-Devices für Hypervisor oder Datenbank-Appliances: iSCSI auf zvol-Basis.

ACLs und Rechte sollten bewusst getestet werden. Gerade SMB-Freigaben wirken schnell einfach, werden aber unübersichtlich, wenn lokale Benutzer, AD, unterschiedliche ACL-Modelle und gemischte Clients zusammenkommen.

5. Apps und Virtualisierung auf aktuellen SCALE-Releases

Einer der größten inhaltlichen Änderungen gegenüber älteren TrueNAS-Artikeln ist die App-Plattform: aktuelle SCALE-Releases nutzen Docker-basierte Apps und nicht mehr das frühere Kubernetes-/K3s-Modell, das lange viele Setups geprägt hat.

Das ist wichtig, weil viele ältere Anleitungen inzwischen veraltet sind. Aussagen wie "TrueNAS Apps basieren auf Kubernetes und TrueCharts ist der Standardweg" sind in dieser Form nicht mehr belastbar.

Für die Praxis heißt das:

  • Apps sollten als eigener Workload-Bereich betrachtet werden, nicht als beiläufiges Extra auf dem NAS.
  • App-Daten gehören in klar getrennte Datasets.
  • Updates und Migrationen der App-Plattform müssen bewusst geplant werden.
  • Für kritische Produktiv-Apps bleibt ein separates Compute-System oft wartbarer als "alles auf dem NAS".

TrueNAS kann Anwendungen bereitstellen, ist aber in erster Linie eine Storage-Plattform. Wer viele Dienste, komplexe Abhängigkeiten oder häufige Deployments plant, fährt oft besser mit einem getrennten App-Host und nutzt TrueNAS für das, was es besonders gut kann: ZFS, Snapshots, Replikation und zuverlässige Datenspeicherung.

6. Snapshots, Replikation und Off-Site-Backups

Der eigentliche Mehrwert von TrueNAS zeigt sich bei Datensicherung und Wiederherstellung:

  • Snapshots: schnelle Wiederherstellung versehentlich geänderter oder gelöschter Daten.
  • Replikation: effiziente Übertragung von Deltas zu zweitem TrueNAS oder anderem ZFS-System.
  • Cloud Sync: zusätzliche Off-Site-Sicherung für wichtige Datasets.

Eine sinnvolle Standardstrategie:

  • stündliche bis tägliche Snapshots je nach Dataset,
  • Replikation auf zweites System für wichtige Daten,
  • zusätzliche Off-Site-Kopie für wirklich kritische Inhalte.

Wichtig ist, zwischen Snapshot und Backup zu unterscheiden. Snapshots helfen gegen versehentliche Änderungen und manche Ransomware-Szenarien, sind aber kein Ersatz für getrennte, versionierte und im Idealfall Off-Site liegende Sicherungen.

7. Monitoring, Wartung und häufige Fehler

Ein NAS ist nur dann zuverlässig, wenn laufende Pflege ernst genommen wird. Zu den Pflichtaufgaben gehören:

  • SMART-Tests und ZFS-Scrubs,
  • Überwachung von Pool-Status, Temperatur und freiem Speicher,
  • geplante Update-Fenster,
  • regelmäßige Restore-Tests.

Typische Fehler in Self-Hosted-Setups:

  • zu wenig RAM für die tatsächlichen Workloads,
  • Dedup "aus Interesse" aktiviert,
  • ein einziger großer Pool ohne Datensatz-Struktur,
  • Apps und VM-Workloads auf dem NAS betrieben, ohne deren Recovery zu planen,
  • Snapshots vorhanden, aber nie Rücksicherung getestet.

Wer TrueNAS primär als Storage-Layer behandelt und Apps nur bewusst und begrenzt darauf laufen lässt, erhält in der Regel die stabilere Plattform.