TrueNAS HA: Wann lohnt sich der Dual-Controller?

“Brauchen wir HA?” — das ist eine der häufigsten Fragen bei TrueNAS-Beratungsterminen für Enterprise-Modelle. Die Antwort ist selten ein klares Ja oder Nein. Dual-Controller-Hochverfügbarkeit kostet Aufpreis (oft im hohen vier- bis fünfstelligen Bereich), bringt Komplexität ins System und löst nicht alle Verfügbarkeitsprobleme. Gleichzeitig ist sie in bestimmten Szenarien alternativlos.

Dieser Artikel hilft bei der Entscheidung — pragmatisch und ohne Verkaufsdruck.

Was TrueNAS HA technisch macht

Ein TrueNAS-HA-System besteht aus zwei identischen Controller-Heads, die sich Zugriff auf dasselbe Disk-Shelf bzw. dieselben Pool-Disks teilen. Ein aktiver Controller bedient die Clients, der zweite ist im Stand-by und übernimmt automatisch, wenn der aktive ausfällt.

Konkret:

• Heartbeat zwischen beiden Controllern über dedizierte Links
• Shared SAS-Backend auf die Disks (Dual-Path-Multipathing)
• Synchronisierte Konfiguration (Pool-Layout, Shares, Snapshot-Pläne)
• Floating IPs / Virtual IPs, die im Failover-Fall auf den zweiten Controller wandern
• NVRAM-Mirror für Schreibcache-Konsistenz

Failover dauert typischerweise im Sekundenbereich. Für Block-Clients (iSCSI, FC, NVMe-oF) ist das in der Regel transparent — die Sessions werden vom zweiten Controller übernommen, IO pausiert kurz. Für File-Clients (SMB, NFS) kann je nach Client-Konfiguration ein Session-Reconnect nötig sein; moderne SMB- und NFSv4-Stacks sind tolerant, ältere weniger.

Wann HA sinnvoll ist

Aus unserer Beratungspraxis: HA lohnt sich tatsächlich in folgenden Konstellationen.

1. 24/7-Betrieb mit strenger SLA. Wenn Storage-Ausfall direkt Produktionsausfall bedeutet — Fertigungslinien, Krankenhaus-Anwendungen, Online-Plattformen, Trading-Systeme — und die SLA mit Minuten oder Sekunden Recovery-Time gemessen wird, ist HA das richtige Werkzeug.

2. Einzige Storage-Quelle für Mission-Critical-Workload. Wenn alle virtuellen Maschinen einer Produktionsumgebung von einem einzigen TrueNAS leben (z.B. iSCSI an einen Proxmox- oder VMware-Cluster), ist HA ein erheblicher Stabilitätsgewinn. Ein Controller-Ausfall ohne HA bedeutet hier Storage-Stillstand für alle VMs gleichzeitig.

3. Geringer Wartungsspielraum. Manchen Umgebungen fehlt schlicht das Wartungsfenster. Wenn Firmware-Updates am Controller laufenden Betrieb erfordern, ist HA praktisch alternativlos — ein Controller wird gepatcht und neugestartet, der andere übernimmt, dann der andere herum.

4. Compliance-Anforderungen. Manche Branchen (Finanz, Gesundheit, kritische Infrastruktur unter NIS2 / CER) erwarten dokumentierte Hochverfügbarkeit. Hier ist HA oft die einfachste Art, diesen Punkt nachweisbar abzuhaken.

Wann HA NICHT sinnvoll ist

Genauso wichtig — und in der Beratung der häufigere Fall:

1. Backup-Targets. Ein TrueNAS, das Proxmox-Backup-Server, Veeam, Restic oder ähnliche Backup-Tools beherbergt, braucht in der Regel kein HA. Wenn das Backup-Ziel für ein paar Stunden steht, läuft das Backup einfach beim nächsten Termin oder zeitversetzt. Hier wäre HA-Investition in Performance oder Kapazität besser angelegt.

2. Wartungsfenster ist möglich. Wenn das Unternehmen z.B. abends oder am Wochenende ohnehin Wartungsfenster nutzt, sind Controller-Updates kein Problem für ein Single-Controller-System.

3. Replikation auf zweites NAS ist Alternative. Zwei TrueNAS Single-Controller-Systeme mit ZFS-Replikation (asynchron, alle 15 Minuten oder häufiger) bieten bessere Resilience gegen Standortausfall als ein HA-System an einem Standort. Mehr dazu unten.

4. Storage ist nicht der kritische Pfad. Wenn die Geschäftskritikalität an Datenbanken, ERP-Systemen oder Applikations-Servern hängt — und nicht direkt am NAS — ist HA am NAS oft die falsche Priorisierung.

Was HA NICHT löst — der wichtigste Punkt

Hier liegen die häufigsten Missverständnisse:

HA löst keinen Bedienfehler. Wenn ein Administrator rm -rf / auf einem Dataset macht, oder ein Pool versehentlich exportiert wird, oder ein Snapshot mit zfs destroy weggeworfen wird — der zweite Controller macht exakt das Gleiche. HA repliziert keine Entscheidungen, sondern sorgt nur dafür, dass der aktive Controller immer einer ist.

HA löst keine Pool-Korruption. Wenn ein ZFS-Pool durch einen Bug, einen Strom-Spike oder kombinierte Disk-Fehler in Mitleidenschaft gezogen wird, ist das Problem auf beiden Controllern gleichzeitig sichtbar — sie teilen sich denselben Pool.

HA löst keinen Standortausfall. Beide Controller stehen typischerweise im selben Rack. Brand, Wassereinbruch, Stromausfall oder Diebstahl betrifft beide.

HA löst keine Ransomware. Wenn Malware in den Pool schreibt, schreiben beide Controller gleichermaßen. HA ersetzt kein Backup, keine Snapshots und keine Immutable-Strategie (siehe Immutable-Backups gegen Ransomware).

Kurzformel: HA = Hardware-Ausfall-Schutz. HA ≠ Backup. HA ≠ Disaster Recovery.

Alternative: zwei Single-Controller-Systeme mit Replikation

Für viele KMU ist diese Variante 2026 die bessere Wahl:

• TrueNAS Single-Controller-System A am Hauptstandort
• TrueNAS Single-Controller-System B an einem zweiten Standort (oder anderer Brandabschnitt)
• ZFS-Replikation alle 15 Minuten (oder häufiger je nach Bandbreite und Datenvolumen)

Vorteile gegenüber einem HA-System am selben Standort:

• Standortausfall ist abgedeckt
• Pool-Korruption auf A schreibt sich nicht automatisch nach B (Replikation lässt sich anhalten)
• Ransomware-Befall lässt sich oft auf A begrenzen, wenn B abweichende Credentials und keine Schreibrechte zu A hat
• Höhere TCO-Effizienz — zwei Systeme statt eines Dual-Controllers liefern in vielen Fällen mehr Kapazität und Resilience für ähnliches Budget

Nachteile:

• Manueller Failover im Worst Case (DNS-Switch, Mount-Anpassungen, evtl. IP-Wechsel)
• RPO durch Replikations-Intervall (15 Minuten = max. 15 Minuten Datenverlust)
• Mehr Komplexität im Betriebs-Handbuch

Siehe auch unsere Praxismaterialien zur Replikation: Vorteile von TrueNAS-Snapshots und TrueNAS-ZFS-Replikation: Bandbreite throtteln.

Welche TrueNAS-Modelle bieten HA?

Eine kurze Übersicht, welche Serien mit Dual-Controller-Option verfügbar sind (Stand 2026):

• F-Serie (F60, F100): HA Standard — typischer Use-Case Mission-Critical-All-Flash
• V-Serie (V160): HA Standard — Tri-Mode für gemischte Workloads
• M-Serie (M30-M60): HA optional — Capacity-orientiert, viele HA-Deployments
• H-Serie (H10, H20, H30): HA optional — Compact Enterprise
• R-Serie (R20-R60): kein HA — kostenoptimiert, Single-Controller Design
• Mini-Serie: kein HA — SOHO/KMU-Segment

Wer mit dem TrueNAS-Konfigurator die Kombinationsmöglichkeiten durchspielen will, findet das auf truenas-configurator.de.

Failover-Verhalten in der Praxis

Aus zahlreichen Installationen ein realistisches Bild des Failover-Verhaltens:

• Geplanter Failover (Wartung, Update): Im Sekundenbereich. Block-Clients oft unbemerkt, File-Clients je nach Protokoll-Konfiguration.
• Hardware-Failover (Controller-Crash): Wenige Sekunden bis ca. eine Minute. Auch hier sind iSCSI/NVMe-oF in der Regel transparent; SMB-Clients sehen ggf. einen Reconnect-Hinweis und arbeiten weiter.
• Failback nach Reparatur: Manuell ausgelöst, dauert üblicherweise einige Minuten (Pool muss vom reparierten Controller übernommen werden, Synchronisation der Caches).

Tipp aus der Praxis: Failover regelmäßig testen. Ein HA-Setup, das jahrelang nicht failovern musste, kann beim Ernstfall überraschen — Firmware-Inkompatibilitäten, drifted Konfigurationen, ungetestete Network-Pfade. Wir empfehlen mindestens jährlich einen geplanten Failover-Test mit Dokumentation.

Empfehlung pro Use-Case

Eine kurze Orientierung:

Use-Case	Empfehlung
Produktions-Storage für 24/7-VMs, strenge SLA	TrueNAS HA (F/V/M-Serie)
Backup-Target (PBS, Veeam)	Single-Controller, ggf. zweites für Replikation
File-Server für 50-200 Mitarbeiter, normale Bürozeit	Single-Controller plus tägliche Replikation
ERP-Datenbank-Storage, hohe Verfügbarkeit	TrueNAS HA + zusätzliche Replikation off-site
Standort-Ausfall-Schutz primär	Zwei Single-Controller an zwei Standorten
Mission-Critical Multi-Site	TrueNAS HA an Hauptstandort + Replikation auf zweiten Standort

Fazit

TrueNAS HA ist ein konkretes Werkzeug für ein konkretes Problem: Hardware-Controller-Ausfall ohne Service-Unterbrechung überbrücken. Für alles andere — Backup, Disaster Recovery, Ransomware-Schutz, Standortausfall — gibt es bessere, oft günstigere Werkzeuge.

Die häufigste Empfehlung im KMU-Mittelstand 2026: ein HA-System nur dort, wo der Ausfall in Minuten kostet, ergänzt um Replikation auf ein zweites System für DR. Wer hingegen ein Backup-NAS oder ein File-Server-NAS auf HA aufrüsten will, sollte erst prüfen, ob das Geld nicht in mehr Kapazität, schnelleres Netzwerk oder Off-Site-Replikation besser investiert ist.

DATAZONE berät neutral und mit Blick auf den tatsächlichen Workload — wir empfehlen HA nur dann, wenn der Anwendungsfall es klar rechtfertigt, und schlagen sonst die kostenoptimierte Alternative vor.