QNAP Dual-NAS - High Availability Enterprise-Hochverfügbarkeit ab dem 4-Bay-NAS

Wenn ein NAS ausfällt, stehen abhängige Workloads still: Fileservices, Backup-Ziele, iSCSI-Datastores für die Virtualisierung, Aufzeichnungen aus der Videoüberwachung. Im Mittelstand wird dieses Risiko oft akzeptiert, weil echte Hochverfügbarkeit auf Storage-Ebene bisher mit teuren Enterprise-Systemen verbunden war – Dual-Controller-SANs, Cluster-Lizenzen, separates Heartbeat-Switching. Mit der QNAP Dual-NAS High Availability-Lösung verschiebt QNAP diese Schwelle deutlich nach unten: Zwei baugleiche NAS bilden ein Active-Passive-Cluster, das einen Knotenausfall in unter 90 Sekunden auffängt – mit Hardware, die schon ab dem TS-473A beginnt. Dieser Artikel erklärt, wie die Lösung technisch funktioniert, welche Modelle freigegeben sind, wovor sie schützt und wovor nicht, und worauf bei Planung und Beschaffung zu achten ist.

Kurzüberblick (in 60 Sekunden):

Was ist QNAP-Dual-NAS HA?

QNAPs Dual-NAS-HA-Lösung ist ein Hochverfügbarkeits-Cluster aus zwei baugleichen NAS-Systemen. Beide Knoten teilen sich eine virtuelle Cluster-IP, über die Clients alle Dienste erreichen – SMB, NFS, iSCSI, S3, Anwendungsdienste. Nur ein Knoten ist zu jedem Zeitpunkt aktiv und beantwortet Anfragen; der zweite Knoten läuft als passiver Hot-Standby und hält über kontinuierliche Block-Level-Replikation einen synchronen Datenbestand vor.

Die Verwaltung übernimmt eine eigene Anwendung im App-Center: der High Availability Manager. Damit werden beide Knoten zum Cluster zusammengeführt, der Heartbeat konfiguriert, der Quorum-Server hinterlegt und die Cluster-IP definiert. Im laufenden Betrieb überwacht der Manager den Zustand beider Knoten, koordiniert geplante Switchovers (etwa für Wartung) und löst bei einem Ausfall automatisch einen Failover aus.

Der entscheidende Punkt ist die Replikations-Engine im Hintergrund: SnapSync. Sie nutzt die ZFS-Snapshot-Mechanik von QuTS hero und überträgt Änderungen blockgenau auf den Standby-Knoten – nicht datei- oder ordnerbasiert wie ein klassisches rsync. Dadurch ist die Replikation sowohl schnell als auch konsistent: Anwendungen, die auf dem aktiven Knoten in einer offenen Datei schreiben, werden im Failover-Fall auf dem Standby exakt im selben Block-Status fortgesetzt.

Die Architektur-Zusammenfassung:

• Active-Passive: Ein Knoten serviert, der zweite hält den Datenstand vor. Kein Active-Active-Loadbalancing — der passive Knoten erbringt im Normalbetrieb keine Client-I/O.
• Virtuelle Cluster-IP: Clients sprechen das Cluster an, nicht einzelne Knoten. Ein Failover ist für den Client transparent.
• Block-Level-Replikation via SnapSync: ZFS-basiert, Real-Time, konsistent.
• Quorum-Server (optional, dringend empfohlen): Verhindert Split-Brain bei gleichzeitigem Ausfall von Heartbeat und Cluster-Netzwerk.

Wie funktioniert das HA-Cluster technisch?

Block-Level-Replikation via SnapSync

SnapSync ist QNAPs ZFS-basierte Replikations-Engine – exklusiv für QuTS hero, nicht für das ext4-basierte Standard-QTS verfügbar. Im HA-Kontext arbeitet SnapSync kontinuierlich: Jeder geschriebene Block auf dem aktiven Knoten wird sofort über die Heartbeat-Verbindung an den Standby übertragen. Der Datenstand auf beiden Knoten ist damit nahezu synchron, der Recovery Point Objective (RPO) liegt im Mikrosekundenbereich. Die Latenz zwischen den beiden Knoten liegt bei etwa 100 Mikrosekunden.

Im Unterschied zu klassischen Replikationsverfahren wie rsync oder zur datei-basierten Replikation in HBS3 hat SnapSync drei strukturelle Vorteile: Die Replikation ist crash-konsistent auf Block-Ebene – der Standby-Datenstand entspricht dem Zustand nach einem unsauberen Reboot des aktiven Knotens; ZFS sorgt durch Copy-on-Write und Transaktions-Gruppen dafür, dass diese Block-Sicht intern konsistent ist. Sie ist inkrementell auf Block-Ebene (es werden nur tatsächlich geänderte Blöcke übertragen, nicht ganze Dateien). Und sie liegt auf demselben ZFS-Storage-Layer mit Ende-zu-Ende-Checksummen, sodass Block-Korruption auf beiden Seiten erkannt wird.

Heartbeat-Verbindung und Quorum-Server

Die Heartbeat-Verbindung ist die Lebensader des Clusters. Sie überträgt sowohl die SnapSync-Replikationsdaten als auch das Statussignal beider Knoten. QNAP fordert hier eine dedizierte Direktverkabelung zwischen beiden NAS – ohne dazwischenliegenden Switch. Empfohlen sind 10 GbE oder schneller; bei den Enterprise-Modellen der TS-h-Serie sind 25 GbE und höher verfügbar. Da der Heartbeat sowohl Statusmeldungen als auch Replikationsdaten transportiert, empfiehlt QNAP, das Interface mit der höchsten verfügbaren Bandbreite zu wählen.

Der Quorum-Server ist eine Schiedsinstanz für den Fall, dass die Knoten sich gegenseitig nicht mehr sehen. Wenn nur die Heartbeat-Verbindung ausfällt, der Cluster aber im Produktivnetz weiterläuft, könnten beide Knoten denken, der jeweils andere sei tot – und beide würden aktiv werden. Genau diesen „Split-Brain"-Zustand verhindert der Quorum-Server: Vor jedem Failover prüft der überlebende Knoten, ob er die definierte Quorum-IP erreicht. Tut er das und der Partnerknoten nicht, übernimmt er. Ohne Quorum-Server bleibt im Doppelausfall-Szenario keine Schiedsinstanz – ein Split-Brain ist dann nicht mehr automatisch verhindert und erfordert manuelles Eingreifen.

Das Praktische: Der Quorum-Server muss kein dedizierter Server sein. Es genügt eine dauerhaft erreichbare IP-Adresse im Netzwerk – typischerweise das Standard-Gateway, ein DNS-Server oder ein zentrales Management-System. Ein eigener Agent ist nicht erforderlich.

Failover und Switchover

QNAP unterscheidet zwei Übergänge:

• Failover: Ungeplant. Der aktive Knoten fällt aus — Hardwaredefekt, Stromausfall, Kernel-Panic. Der Standby übernimmt automatisch.
• Switchover: Geplant. Der Administrator löst manuell einen Wechsel aus, etwa für Firmware-Updates oder Hardwarewartung. Auch hier übernimmt der Partnerknoten, der Switchover läuft kontrolliert ab.

Die Failover-Zeit liegt laut QNAPs Hands-on-Lab auf einem TVS-h474-Pair bei 89 Sekunden für den Failover beim Ausfall des aktiven Knotens und bei 82 Sekunden beim Ausfall des passiven Knotens; der Reconnect zurück auf den ursprünglich aktiven Knoten dauerte 74 Sekunden. Windows-SMB-Clients erleben in dieser Zeit dank SMB Transparent Failover ein kurzes „Hängen" der Verbindung; nachdem die Cluster-IP auf dem Standby aktiviert ist, setzen die Übertragungen automatisch fort – ohne Anwender-Eingriff, ohne Datenverlust, sofern der replizierte Block-Stand aktuell war. Linux- und macOS-Clients unterstützen SMB Transparent Failover nicht und müssen offene Übertragungen nach dem Failover manuell neu anstoßen.

Einordnung

Eine Failover-Zeit unter 90 Sekunden ist für Mittelstandsanforderungen sehr stark. Klassische Dual-Controller-SANs erreichen Werte unter 30 Sekunden, kosten aber das Vielfache; rein dateibasierte Backup-Restore-Verfahren liegen typischerweise im Bereich von Minuten bis Stunden. Für die meisten Workloads – Fileservices, Backup-Ziele, virtualisierte Umgebungen mit Toleranz für kurze Storage-Pausen – sind 60–90 Sekunden ausreichend. Geschäftsapplikationen mit harten Echtzeit-Anforderungen sollten mit dem Hersteller der Anwendung verifiziert werden.

Voraussetzungen: Hardware, OS, Netzwerk

QuTS hero h5.3 als Production-Baseline

Die wichtigste Entscheidung steht ganz am Anfang: QNAP-HA gibt es ausschließlich unter QuTS hero, dem ZFS-basierten Betriebssystem. Standard-QTS auf ext4-Basis ist nicht HA-fähig. Wer ein bestehendes QTS-NAS auf QuTS hero umstellen will, muss die Daten vorher sichern und das System neu aufsetzen – ein direkter Migrationspfad ohne Datenverlust existiert nicht.

Als Production-Baseline empfiehlt sich derzeit (Stand April 2026) QuTS hero h5.3 – aktuell die Stable-Linie h5.3.2. Diese Version unterstützt SnapSync in Echtzeit innerhalb des HA-Clusters und ist breit produktiv im Einsatz. Die nachfolgende Version h6.0 ist als Beta verfügbar und bringt zusätzliche Features wie immutable Snapshots, hat aktuell aber noch Lücken: Real-time SnapSync, Q'center-Anbindung, VJBOD und Drittanbieter-Apps sind im HA-Kontext unter h6.0 Beta noch nicht freigegeben. Für neue Installationen mit produktivem HA-Anspruch ist h5.3 daher die saubere Wahl.

Identische Knoten und Heartbeat-Direktverkabelung

Beide Knoten im HA-Cluster müssen bauidentisch sein: gleiches Modell (vom HA-Manager validiert), identische RAM-Gesamtkapazität, identische QuTS-hero-Version, identische HA-Manager-Version. Das ist nicht nur eine Empfehlung, sondern technische Voraussetzung – Mischbetrieb wird vom Cluster nicht akzeptiert. Auch die Datenträger-Bestückung sollte identisch sein (Modell, Kapazität, RAID-Layout).

Die Heartbeat-Verbindung ist eine Punkt-zu-Punkt-Direktverbindung zwischen beiden NAS, ohne dazwischenliegende Switches. Das vereinfacht die Topologie und schließt Switch-Ausfälle als Heartbeat-Störungsquelle aus, erfordert aber ein freies Netzwerk-Port-Paar an beiden Knoten und ein passendes Direktanschlusskabel (DAC oder LWL bei längeren Distanzen). QNAP empfiehlt für den Heartbeat mindestens 10 GbE; in höheren Modellklassen sind 25 GbE oder schneller verfügbar.

Cluster-Netzwerk und Single-Site-Architektur

Beide Knoten sitzen im gleichen Subnetz und sind idealerweise an denselben Switch oder denselben Switch-Stack angeschlossen. Über dieses Cluster-Netzwerk wird die virtuelle Cluster-IP propagiert – die einzige IP, die Clients adressieren. Bei einem Failover migriert die Cluster-IP automatisch auf den Standby-Knoten, sodass Clients weiterhin dieselbe Adresse ansprechen.

Eine wichtige Konsequenz: Eine native Stretched-Cluster-Konfiguration über zwei Standorte hinweg ist mit der QNAP-Dual-NAS-HA-Lösung nicht vorgesehen. Beide Knoten gehören in denselben Raum, idealerweise sogar in dasselbe Rack. Wer Standortredundanz braucht, ergänzt die HA-Lösung um eine zeitgesteuerte SnapSync-Replikation an einen dritten NAS in einem anderen Brandabschnitt oder Standort.

Für die Hardware-Anbindung im Cluster-Netzwerk lohnt der Blick auf die QNAP-Switch-Familie, die mit den NAS-Modellen abgestimmt ist und 10/25-GbE-Ports in resellertauglichen Preisklassen anbietet.

Unterstützte Modelle: vom 4-Bay bis PetaByte

QNAP positioniert die Dual-NAS-HA-Lösung bewusst skalierbar: Vom kompakten Desktop-NAS für kleinere Serverräume bis zum All-Flash-PetaByte-Cluster im Rechenzentrum laufen dieselben Cluster-Prinzipien, dieselbe Verwaltung, derselbe HA Manager. Die Hardware skaliert mit dem Bedarf – die Architektur bleibt konstant.

Einstieg (Desktop ZFS): TVS-h474, TVS-h674, TVS-h874

Die TVS-hx74-Serie ist QNAPs günstigste HA-fähige Modellfamilie. Drei Bay-Stufen (4, 6 oder 8 Einschübe), Intel-Pentium- bis 12th-Gen-Core-Plattform, ZFS-tauglich, kompaktes Desktop-Format. QNAP belegt den HA-Einsatz explizit für die TVS-h474 – der Hands-on-Lab-Failover wurde dort mit 89 s (Active-Ausfall) bzw. 82 s (Passive-Ausfall) gemessen. Die baugleichen Schwester-Modelle TVS-h674 und TVS-h874 sind technisch identisch positioniert; die jeweils gültige HA-Support-Matrix ist vor Beschaffung im HA Manager zu prüfen.

Diese Modellklasse ist das realistische Einstiegs-Szenario für QNAP HA: ein 4-Bay-Pärchen aus zwei TVS-h474 erreicht Hardware-Listenpreise im Bereich um 3.000 EUR – ohne Datenträger. Mit zwei Knoten zu je 16 GB RAM, einer Heartbeat-DAC und einem QNAP-Switch wird daraus eine vollwertige HA-Lösung, die im Mittelstand für Fileservices, kleinere iSCSI-Datastores und 24/7-Backupziele dimensioniert ist. Eine Auswahl passender Geräte findet sich in der Kategorie QNAP-Desktop-NAS.

Tower und Rackmount Enterprise: TS-h-Serie

Für höhere Anforderungen stellt QNAP die TS-h-Familie bereit – Tower- und Rackmount-Modelle in mehreren Generationen, mit Bay-Zahlen von 9 bis 24 in 2U/3U/4U-Bauform. Die neueren AXU-Modelle (z. B. TS-h1677AXU-RP, TS-h2477AXU-RP) setzen auf AMD Ryzen 7000 mit DDR5-RAM; ältere Generationen wie das TS-h1283XU-RP, TS-h1886XU-RP oder TS-h2287XU-RP nutzen Intel Xeon D/E mit DDR4-ECC, das TS-h977XU-RP und TS-h1277XU-RP AMD Ryzen 7 (Zen 2) mit DDR4-ECC. Welche TS-h-Modelle für eine konkrete HA-Konfiguration aktuell freigegeben sind, ist gegen die jeweils gültige QNAP-Support-Matrix zu klären.

Diese Klasse adressiert klassische Rechenzentrums-Workloads: VMware-/Hyper-V-Datastores in mittleren Cluster-Größen, ERP-Datenbanken, Surveillance-Pools mit hoher Schreiblast, M365-Backups in der KMU-Klasse. Eine kuratierte Auswahl gibt es unter QNAP 19" Rackmount NAS.

All-Flash für maximale Performance

Wer maximale IOPS und niedrigste Latenzen braucht – etwa für VDI-Profile, transaktionale Datenbanken oder Tier-1-Virtualisierungs-Datastores –, greift zu den All-Flash-Modellen. Die NVMe-Klasse umfasst das TS-h2490FU (24× U.2 NVMe), das TS-h1290FX (12-Bay-Desktop-NVMe) und das TS-h1090FU (1U, 10× NVMe). Daneben gibt es das TS-h3077AFU als SATA-SSD-All-Flash mit 30 Bays, AMD Ryzen 7000 und DDR5 – günstiger pro TB als reine NVMe-Plattformen, aber mit niedrigerer Spitzen-IOPS. Auch hier gilt das HA-Prinzip identisch: zwei baugleiche Geräte, Heartbeat-Direktverbindung, Cluster-IP, SnapSync-Replikation. Die typische Hardware-Investition für ein All-Flash-HA-Pair beginnt im fünfstelligen Bereich pro Knoten.

Vergleich der HA-Modellklassen

Preise sind orientierend für den deutschen Markt (Stand 2026-04, Listenpreise vor Reseller-Konditionen, ohne Datenträger). Die jeweils aktuelle Modell- und Preisübersicht für eine konkrete Konfiguration lässt sich im Beratungsgespräch prüfen.

Wovor schützt HA – und wovor nicht?

Hochverfügbarkeit ist kein Allzweckschutz. Sie adressiert eine ganz bestimmte Klasse von Ausfällen sehr gut – und andere Klassen gar nicht. Dieser Abschnitt grenzt klar ab, damit eine HA-Investition nicht zu falscher Sicherheit führt.

Wogegen HA wirksam schützt

• Hardwareausfall eines Knotens: Defekte Mainboard-Komponenten, Netzteile, RAM-Module, Controller. Der Standby übernimmt.
• Geplante Wartung: Firmware-Updates, OS-Updates, Hardware-Tausch laufen rollierend ab. Der zu wartende Knoten wird per Switchover entlastet.
• Heartbeat- oder Netzwerkkarten-Ausfall auf einem Knoten — sofern der Quorum-Server konfiguriert ist und antwortet.

Wogegen HA NICHT schützt

• Standortausfälle: Brand, Wassereinbruch, Stromausfall im gesamten Rack oder Raum, physischer Diebstahl. Beide Knoten stehen in der Regel im selben Raum.
• Ransomware und Logikfehler: Wird auf dem aktiven Knoten verschlüsselt, repliziert SnapSync die Verschlüsselung in Echtzeit auf den Standby. Das gleiche gilt für versehentliches Löschen, Datenbank-Korruption durch fehlerhafte Anwendungen, fehlerhafte Skripte.
• Konfigurationsfehler: Wer beide Knoten gleich falsch konfiguriert, hat doppelt falsche Knoten.

Konsequenz: Eine HA-Lösung ersetzt kein Backup. Sie ergänzt es. Die saubere Architektur kombiniert HA für Verfügbarkeit mit einem separaten, idealerweise offsite-fähigen Backup-Konzept – typisch über Hybrid Backup Sync (HBS3) auf einen dritten NAS, ein Tape-System oder einen Cloud-Speicher mit immutable-Snapshot-Funktion.

Wer mehr zur Architektur klassischer Speicherkonzepte vertiefen möchte, findet eine Einordnung im Wissensartikel zu den drei wichtigsten Speicherkonzepten und in den Storage-Grundlagen.

RTO und RPO realistisch eingeordnet

• Recovery Time Objective (RTO): unter 90 Sekunden für den automatischen Failover. Geplante Switchovers laufen häufig schneller, weil keine Time-Out-Erkennung nötig ist.
• Recovery Point Objective (RPO): typischerweise im niedrigen einstelligen Sekundenbereich bei aktiver Real-time-SnapSync-Replikation in QuTS hero h5.3 — abhängig von Schreiblast und Netzwerk. In Konfigurationen mit nur zeitgesteuerter Replikation entspricht der RPO dem konfigurierten Snapshot-Intervall.

Typische Einsatzszenarien

QNAP-HA passt überall dort, wo Storage-Downtime direkt zu Geschäftsausfall führt, ein klassisches Enterprise-SAN aber budgetlich oder organisatorisch nicht in Frage kommt. Die häufigsten Konstellationen:

• 24/7-Fileservices: SMB-/NFS-Shares für ein Unternehmen, das auch außerhalb der Bürozeiten kontinuierlichen Datenzugriff braucht — Logistik, Produktion, Service-Dienstleister.
• iSCSI-Datastores für VMware oder Hyper-V: Mittlere Virtualisierungs-Cluster, deren VMs auf dem NAS liegen. HA verhindert, dass ein Storage-Ausfall den ganzen Hypervisor-Cluster kippen lässt.
• Aufzeichnung in der Videoüberwachung: QVR Pro mit hoher Schreiblast braucht eine Storage-Backplane, die nicht für Wartung offline gehen darf, ohne Aufzeichnungslücken zu erzeugen.
• ERP- und Datenbank-Backends: Insbesondere kleinere SQL- oder PostgreSQL-Workloads, deren Backups sich auf dem NAS befinden oder die direkt auf iSCSI-LUNs schreiben.
• Backup- und Archiv-Ziel: Wenn das NAS selbst der Backup-Empfänger ist, darf es nicht der Single Point of Failure sein. HA macht es zum ausfallsicheren Backup-Tier.
• Medienproduktion und Post-Production: Schnitt-Workflows, die mehrere Editoren parallel auf gemeinsamen Datenbeständen abarbeiten.

QNAP HA im Vergleich zu klassischen Storage-HA-Lösungen

Hochverfügbarer Storage ist seit Jahrzehnten Domäne klassischer Enterprise-Anbieter – NetApp, Dell EMC, Pure Storage, HPE Primera. Diese Lösungen sind technisch ausgereift, bringen breite Feature-Sets und etablierten Support mit – haben aber traditionell eine deutlich höhere Einstiegsschwelle. Der folgende Vergleich ist bewusst grob gehalten, ordnet aber die strategische Position von QNAP HA ein.

Zwischenfazit: Für Workloads, deren Verfügbarkeitsanforderung im Bereich „Failover unter 90 Sekunden" liegt und deren Storage-Volumen im zweistelligen TB-Bereich beginnt, ist QNAP HA häufig die Lösung mit dem deutlich besseren Preis-Leistungs-Verhältnis. Wer harte Sub-30-Sekunden-Failover, Stretched-Cluster über Standorte oder garantierte 24/7-Vor-Ort-Reparatur in vier Stunden braucht, ist bei klassischen Enterprise-Anbietern besser aufgehoben.

Wer den Vergleich mit hyperkonvergenten Software-Defined-Lösungen sucht, findet im Wissensartikel zu Microsoft Storage Spaces Direct (S2D) eine Einordnung der Microsoft-Welt; ein direkter konzeptioneller Vergleich zu Block-Storage-Protokollen liefert Fibre Channel vs. iSCSI.

Limitationen, die Sie kennen sollten

Eine ehrliche Liste der Punkte, die in Marketingmaterial selten so klar formuliert werden:

• QuTS hero only: Standard-QTS unterstützt diese HA-Lösung nicht. Wechsel von QTS auf QuTS hero erfordert Datenmigration über Backup/Restore.
• Identische Hardware-Pflicht: Mischbetrieb ist nicht vorgesehen. Beide Knoten müssen Modell-, RAM- und Firmware-identisch sein sowie über die gleiche HDD-Kapazität verfügen.
• Single-Site-Architektur: Stretched Cluster über zwei Brandabschnitte oder Standorte ist nicht vorgesehen. Standortredundanz wird über zusätzliche zeitgesteuerte SnapSync-Replikation gelöst.
• Active-Passive, kein Loadbalancing: Die zweite Investition liefert keinen Performance-Gewinn im Normalbetrieb — sie ist reine Redundanz.
• Heartbeat als Direktverkabelung: Erfordert ein freies Port-Paar an beiden Knoten und ein passendes Kabel, kein Switch dazwischen.
• QuTS hero h6.0 noch Beta: Real-time SnapSync, Q'center-Anbindung, VJBOD und Drittanbieter-Apps sind im HA-Kontext unter h6.0 Beta noch nicht freigegeben. Für produktive Neueinrichtungen aktuell h5.3 nutzen.
• Quorum-Server dringend empfohlen: Ohne Quorum kann ein Doppelausfall (Heartbeat plus Cluster-Netzwerk gleichzeitig) zu einem Split-Brain-Error führen, der manuelles Eingreifen erfordert.
• Kein Ersatz für Backup: Replikation ist nicht Backup. Ransomware, Logikfehler und Standortausfälle bleiben separate Risiken.

Diese Punkte sind keine K.-o.-Kriterien, sondern Planungs-Eingaben. Sauber geplant ist die Lösung in den meisten Mittelstands-Szenarien hochverfügbar, robust und budgetfreundlich.

Inbetriebnahme in fünf Schritten

Die Installation eines HA-Clusters ist im HA Manager weitgehend assistentengeführt:

1. Beide Knoten vorbereiten: Identisches QNAP-Modell, identischer RAM, QuTS hero h5.3 frisch installiert oder aktualisiert. Datenträger eingebaut, ZFS-Pools angelegt, Netzwerkadressen vergeben.
2. Heartbeat-Direktverbindung verkabeln: Ein freies 10-GbE- oder 25-GbE-Port-Paar an beiden Knoten direkt mit DAC oder LWL verbinden. Die zugehörigen Netzwerkkarten im QuTS-hero-Netzwerkmenü erkennen lassen.
3. High Availability Manager installieren: Über das App-Center auf beiden Knoten. Anschließend einen Knoten als Cluster-Initiator wählen und den Partner per IP einbinden.
4. Cluster bilden, Cluster-IP definieren, Quorum-Server eintragen: Im HA-Manager die virtuelle Cluster-IP setzen, den Quorum-Server (typischerweise das Standard-Gateway) hinterlegen und die initiale Synchronisation starten. Diese kann je nach Datenmenge mehrere Stunden dauern – ist aber ein Einmal-Vorgang.
5. Cluster-IP an Clients ausrollen: Bestehende SMB-/NFS-/iSCSI-Mounts auf die neue Cluster-IP umstellen. Failover-Test durch geplanten Switchover durchführen, danach produktiv schalten.

Für eine konkrete Sizing- und Implementierungsplanung – inklusive Switch- und Verkabelungsempfehlung – empfiehlt sich ein Beratungsgespräch.

Zusammenfassung

Die QNAP Dual-NAS-HA-Lösung verschiebt Enterprise-Hochverfügbarkeit auf Storage-Ebene in eine Preis- und Komplexitätsklasse, die sie für den Mittelstand zugänglich macht. Zwei baugleiche QNAP-NAS bilden ein Active-Passive-Cluster, der HA-Manager macht die Konfiguration assistentengeführt, SnapSync sichert die Block-Level-Replikation in Echtzeit, der automatische Failover läuft in unter 90 Sekunden. Voraussetzung sind QuTS hero h5.3 als Production-Baseline, identische Knoten, eine Heartbeat-Direktverbindung mit mindestens 10 GbE und ein Quorum-Server.

Das günstigste, offiziell freigegebene Einstiegsmodell ist das TS-473A. Wichtig bleibt: HA ist kein Allzweckschutz. Standortausfälle, Ransomware, Logikfehler und versehentliches Löschen werden vom Cluster nicht aufgefangen — die Replikation überträgt diese Ereignisse in Echtzeit auf den Standby-Knoten. Ein separates Backup-Konzept, idealerweise mit Offsite-Komponente und immutable Snapshots, bleibt zwingender Bestandteil einer ausfallsicheren Architektur.

Für die Evaluierung einer hochverfügbaren Storage-Lösung im Mittelstand stehen bei Serverhero passende Produkte bereit – darunter QNAP, QNAP-Switches und Rackmount-NAS – vom 4-Bay-Einstieg mit zwei TVS-h474 bis zum All-Flash-HA-Pair fürs Rechenzentrum.

FAQ