Disaster Recovery für Einstiegs-NAS
Abgeraucht? Plan B!
Veröffentlicht in Ausgabe 11/2025 - SCHWERPUNKT
In praktisch jedem Büro wie auch in vielen privaten Haushalten sehen sich Nutzer mit der Herausforderung konfrontiert, Daten an zentraler Stelle sicher abzulegen. Kein Problem, denken Sie an dieser Stelle vielleicht, schließlich ist die Geräteklasse der NAS-Speicher bereits erfunden. NAS, die Abkürzung für Network Attached Storage, bildet eine eigene Art von Speicher, der immer dieselben Grundfunktionen hat: Er wird mittels Ethernet in das lokale Netzwerk integriert und stellt dann über Protokolle wie NFS oder CIFS Netzwerklaufwerke zum Ablegen von Daten bereit. Professionelle Modelle sprechen auch iSCSI oder NVMe-over-Fabric (NVMe-oF), was sie für Virtualisierungsaufgaben interessant macht.
Ganz gleich aber, wofür ein NAS zum Einsatz kommt: In den meisten Fällen ist das Maschinchen nach kurzer Zeit aus dem Alltag nicht mehr wegzudenken und von zentraler Bedeutung. Wie kritisch ein Ausfall ist, hängt von der jeweiligen Situation ab und schon im Privathaushalt kann es empfindlich schmerzen, wenn die Urlaubsfotos oder die Sicherungen privater Korrespondenz verloren sind. Für Unternehmen kann es schlicht eine existenzielle Krise bedeuten, steht ein Netzwerkspeicher nicht länger zur Verfügung. Admins sollten sich daher auch im Kontext des Themas Business Continuity regelmäßig Gedanken hinsichtlich der Frage machen, wie sie sich sinnvoll gegen ein ausgefallenes NAS absichern.
Redundanz vs. Disaster Recovery
Zu unterscheiden ist dabei grundsätzlich zwischen den Punkten Disaster Recovery (DR) und Hochverfügbarkeit (HA). Letztere bezieht sich auf ein Betriebskonzept der Redundanz. Hier geht es darum, kurzfristig einen Ersatz für ein temporär ausgefallenes Gerät zur Verfügung zu stellen – und zwar im Idealfall innerhalb weniger Sekunden. Das hält eine Unterbrechung des Betriebs so kurz wie möglich und dämmt entsprechend die schlimmen Folgen ein, die ein nicht funktionsfähiges NAS mit sich bringt. HA-Konzepte für NAS-Laufwerke beziehen sich deshalb im Regelfall auf Redundanz der NAS-Komponenten einerseits und die Nutzung der entsprechenden Softwarefunktionen andererseits.
In praktisch jedem Büro wie auch in vielen privaten Haushalten sehen sich Nutzer mit der Herausforderung konfrontiert, Daten an zentraler Stelle sicher abzulegen. Kein Problem, denken Sie an dieser Stelle vielleicht, schließlich ist die Geräteklasse der NAS-Speicher bereits erfunden. NAS, die Abkürzung für Network Attached Storage, bildet eine eigene Art von Speicher, der immer dieselben Grundfunktionen hat: Er wird mittels Ethernet in das lokale Netzwerk integriert und stellt dann über Protokolle wie NFS oder CIFS Netzwerklaufwerke zum Ablegen von Daten bereit. Professionelle Modelle sprechen auch iSCSI oder NVMe-over-Fabric (NVMe-oF), was sie für Virtualisierungsaufgaben interessant macht.
Ganz gleich aber, wofür ein NAS zum Einsatz kommt: In den meisten Fällen ist das Maschinchen nach kurzer Zeit aus dem Alltag nicht mehr wegzudenken und von zentraler Bedeutung. Wie kritisch ein Ausfall ist, hängt von der jeweiligen Situation ab und schon im Privathaushalt kann es empfindlich schmerzen, wenn die Urlaubsfotos oder die Sicherungen privater Korrespondenz verloren sind. Für Unternehmen kann es schlicht eine existenzielle Krise bedeuten, steht ein Netzwerkspeicher nicht länger zur Verfügung. Admins sollten sich daher auch im Kontext des Themas Business Continuity regelmäßig Gedanken hinsichtlich der Frage machen, wie sie sich sinnvoll gegen ein ausgefallenes NAS absichern.
Redundanz vs. Disaster Recovery
Zu unterscheiden ist dabei grundsätzlich zwischen den Punkten Disaster Recovery (DR) und Hochverfügbarkeit (HA). Letztere bezieht sich auf ein Betriebskonzept der Redundanz. Hier geht es darum, kurzfristig einen Ersatz für ein temporär ausgefallenes Gerät zur Verfügung zu stellen – und zwar im Idealfall innerhalb weniger Sekunden. Das hält eine Unterbrechung des Betriebs so kurz wie möglich und dämmt entsprechend die schlimmen Folgen ein, die ein nicht funktionsfähiges NAS mit sich bringt. HA-Konzepte für NAS-Laufwerke beziehen sich deshalb im Regelfall auf Redundanz der NAS-Komponenten einerseits und die Nutzung der entsprechenden Softwarefunktionen andererseits.
So bieten die allermeisten Geräte heute verschiedene RAID-Level, um sich gegen ausgefallene Datenträger zu schützen. Fortgeschrittene Geräte bringen redundante Netzteile mit. Wollen Sie sich gegen den Ausfall eines ganzen NAS absichern, betreiben Sie einfach ein baugleiches NAS und richten eine synchrone Replikation zwischen den Maschinen ein. Sowohl QNAP als auch Synology als Platzhirsche am Markt für "kleine" NAS-Geräte haben in ihrer Software entsprechende Funktionen integriert. Vor zwei Jahren war HA auf Ebene von NAS-Speichern bereits ausführliches Thema im IT-Administrator [1].
Auch NAS-Geräte von weniger prominenten Herstellern lassen sich entsprechend einrichten, selbst wenn hier manchmal etwas mehr Handarbeit nötig ist. Weil fast alle NAS am Markt auf Linux setzen, greift im äußersten Notfall Standardsoftware für das freie Betriebssystem. Klar ist aber: HA auf NAS-Ebene dient stets dem Zweck, den Ausfall eines NAS kurzfristig durch Redundanz zu kompensieren.
Zu unterscheiden von klassischer Redundanz und Hochverfügbarkeit ist das Thema Disaster Recovery. Der englische Begriff, der keine sinngleiche Entsprechung im Deutschen hat und sich noch am ehesten mit "Vorsorge für den Katastrophenfall" übersetzen ließe, bezieht sich nicht auf den kurzzeitigen Ausfall eines NAS-Laufwerks oder von IT-Infrastruktur generell.
Stattdessen meint der Begriff die Schaffung eines Konzepts für Business Continuity in jenen Fällen, in denen ein NAS nicht nur kurzzeitig nicht zur Verfügung steht, sondern aufgrund katastrophaler Einflüsse von außen dauerhaft untergeht.
"Untergehen" ist dabei ein passender Begriff, denn oft ist es eine Naturkatastrophe, die DR-Szenarien auslöst. Etwa eine Flut, die ganze Keller von Büros unter Wasser setzt und die dortige Hardware unbrauchbar macht. Meist ist die Hardware danach Schrott und die auf ihr liegenden Daten sind höchstens für teures Geld noch im Labor zu retten. Noch schlimmer ist das Thema Feuer: Ist von einem NAS nur noch ein rauchendes Häufchen Asche übrig, hilft auch das tollste Labor nicht mehr weiter. Auch andere Szenarien sind denkbar: Einbrecher etwa, die das Büro ausräumen und das NAS-Gerät einfach mitnehmen, sorgen für kaum weniger Ärger.
Weil Hochverfügbarkeit und Disaster Recovery zwei verschiedene Einsatzszenarien sind, gelten für sie auch jeweils andere Herausforderungen. Unser Artikel befasst sich im Hinblick auf klassische NAS-Geräte vor allem mit dem Thema der Vorsorge für katastrophale Ereignisse, also Disaster Recovery. Und so viel sei schon jetzt verraten: Gerade die SoHo-Geräte der verschiedenen Hersteller bieten in Sachen DR nicht das Maß an Funktionalität, das sich Admins eigentlich wünschen würden.
Enterprise-Szenarien für KMU meist nicht umsetzbar
Gerade in der Großrechenzentrums-IT sind die Anforderungen an Disaster-Recovery-Setups meist klar definiert. Selbst beim katastrophalen Ausfall eines ganzen Rechenzentrums soll ein schneller Failover hin zu einem anderen Standort stattfinden. Idealerweise sogar automatisiert, damit die Downtime so kurz wie möglich ist.
Das aber setzt auf der Infrastrukturebene diverse Vorkehrungen voraus. So muss das jeweilige Netzwerk mittels BGP (Border Gateway Protocol) bis zum ersten lokalen Router reichen, damit es im Katastrophenfall schnell umschwenken kann. Gleichzeitig muss praktisch die gleiche Hardware auf beiden Seiten vorhanden sein und sie muss äquivalent konfiguriert sein und betrieben werden – Replikation der Daten inklusive. Ein solches Szenario kostet im Regelfall mehr Geld als KMU oder private Haushalte zu investieren bereit sind.
Unser Artikel beschränkt sich deshalb auf Konzepte, die mit deutlich weniger Budget umzusetzen sind. Dafür sind Abstriche in Sachen Funktionalität und Verfügbarkeit nötig. Der zentrale Fokus dieses Artikels liegt entsprechend darauf, Daten überhaupt zu erhalten, um sie in überschaubarer Zeit nach einer Katastrophe mit händischer Einwirkung wieder online zu bringen. Ein Automatismus ist nicht vorgesehen, ebenso wenig wie eine sofortige Umschaltung.
Dabei ergeben sich im Hinblick auf NAS-Geräte üblichen Zuschnitts zwei Herausforderungen: Einerseits sind die Daten so zu sichern, dass sie sich im Falle eines Falles schnell wiederherstellen lassen, andererseits ist die Konfiguration der Geräte als separate Aufgabe zu betrachten.
Nutzdaten und Konfiguration sichern
So viel gleich vorweg: Attraktive, umfassende DR-Mechanismen für NAS-Laufwerke existieren am Markt im Moment schlicht nicht. Das liegt maßgeblich eben an der Trennung zwischen Nutzdaten und Konfiguration. In den allermeisten Fällen sind NAS-Geräte so eingerichtet, dass sie ein lokales RAID-Array verwenden, auf dem ein Dateisystem liegt, das seinerseits dann in verschiedene Netzwerkfreigaben unterteilt ist. Clients greifen auf die einzelnen Freigaben zu.
De facto können die Geräte heute aber viel mehr. Mittels ihrer Firmware lassen sich Zusatzdienste installieren, teils in Form von Containern, teils in Form von eigenständigen Tools und Programmen. Dabei entstehen haufenweise Metadaten, also Informationen, die die Konfiguration des NAS selbst und seine Nutzung betreffen. Ein gutes Beispiel sind virtuelle Instanzen: Haben Sie ein etwas teureres Gerät erworben und nutzen es per iSCSI oder NVMe-oF beispielsweise für Proxmox, enthält es einerseits die Volumes, die als virtuelle Festplatte an VMs durchgereicht werden. Andererseits enthält es aber auch die Konfiguration des Betriebssystems für LVM und den eigentlichen iSCSI-Initiator. Wollen Sie Disaster Recovery ermöglichen, sind beide Inhalte zu sichern.
Im Fall von iSCSI ist das zumindest bei QNAP und Synology noch für beide Teile des Szenarios gut zu bewältigen, denn sowohl für Volumes als auch für die Systemkonfiguration gibt es Snapshot-Mechanismen. Bedienen sich Unternehmen aber umfassend an den App-Stores der Hersteller, die diese als integralen Bestandteil des Angebots lautstark bewerben, sieht die Welt weniger rosig aus. Sowohl QNAP als auch Synology etwa haben mittlerweile CRM-Applikationen. Die sind gerade in KMU recht beliebt, weil sie lokal verfügbar sind. Teil der Abläufe beim Systembackup sind sie aber bei beiden Anbietern nicht. Hier lassen sich also nur die Nutzdaten der Anwendungen sichern, etwa das Verzeichnis im Speicher, das die Daten des CRM enthält. Die CRM-App selbst ist bei einem Neuanlauf aber händisch wieder zu installieren und zu konfigurieren.
Die 3-2-1-Regel als Grundlage für NAS-Backups
Wie sollten Admins nun das Thema Disaster Recovery für NAS-Systeme also sinnvoll angehen? Zunächst begegnet uns hier in Form einer goldenen Regel für Datensicherung ein alter Bekannter, nämlich das 3-2-1-Schema. Das gibt vor, dass mindestens drei Backups eines Datensatzes existieren müssen, und zwar auf mindestens zwei verschiedenen Medien, von denen sich eines an einem anderen Ort befinden muss als die ursprüngliche Datenquelle.
Weil Sicherungen für das Disaster Recovery essenziell sind, greift die goldene Backupregel auch für das Thema DR: Haben Sie ein lokales Backup des NAS, lassen sich vor Ort Daten schnell wieder einspielen, falls etwa versehentlich einzelne Datensätze gelöscht worden sind. Ursprünglicher Datensatz und lokales Backup gelten als zwei Kopien der Daten. Die dritte Kopie liegt dann idealerweise an einem anderen Ort und damit implizit auch auf einem anderen Medium und kommt nur im Katastrophenfall zum Einsatz.
Backupwerkzeuge von QNAP und Synology im Vergleich
Umsetzen lässt sich ein DR-Konzept nach der 3-2-1-Regel aber nur dann gut, wenn Sie auf die Funktionen setzen, die der Hersteller des eigenen Gerätes dafür vorsieht. Für das lokale Backup, das der schnellen Wiederherstellung einzelner Datensätze dient, bieten sowohl QNAP als auch Synology eigene Werkzeuge an. Diese beinhalten die Möglichkeit, eine Kopie der Daten auf einer lokal angeschlossenen USB-Festplatte zu erstellen, auf einem entfernten anderen NAS-Gerät oder auch in der Cloud.
Wichtig dabei: Die meisten Unternehmen hierzulande haben aus guten Gründen kein gutes Gefühl dabei, ihre Daten auf Servern US-amerikanischer Cloudanbieter abzulegen – also auch nicht bei Microsoft, Amazon oder Google. Sowohl QNAP als auch Synology unterstützen in ihren Tools aber das Anlegen verschlüsselter Backups. Die Daten lassen sich dann etwa in S3 ablegen, sind dort aber nicht im Klartext nutzbar. Für den Zugriff ist stattdessen der festgelegte Schlüssel nötig, den der Administrator in der Back-upsoftware angibt. Für Synology heißt die entsprechende Software "Active Backup (for Business)", bei QNAP "Hybrid Backup Sync (HBS)".
Die Funktionsweise der Anwendungen ist vergleichbar: In beiden legt der Administrator zunächst die zu sichernden Daten fest und erstellt dann ein Backupziel an einem entfernten Ort, etwa in S3 oder Google Drive. Dann hinterlegt er die festgeschriebene Konfiguration als periodisch wiederkehrende Aufgabe. Die jeweilige Software kümmert sich dann um das inkrementelle Sichern der Daten. Die Programme der Platzhirsche bieten dabei auch die Möglichkeit, die Metadaten der Geräte mitsamt ihrer Konfiguration als eigenes Backup zu sichern. Hier gelten aber die bereits beschriebenen Ausnahmen, etwa was aus dem App-Store nachinstallierte Anwendungen betrifft.
Dank Replikation schneller wieder online
Allen Ansätzen, die auf Backup per eigenständiger Software fußen, ist gemein, dass der jeweils verfügbare Satz an Daten nicht sekundengenau und aktuell ist. Zwar bieten die jeweiligen Sicherungstools hierfür in Teilen eine Abhilfe. So gibt es in Hybrid Backup Sync von QNAP beispielsweise eine Funktion namens "Echtzeitsynchronisation" (Real Time Sync), die Änderungen auf dem lokalen Gerät unmittelbar auch auf das Backupmedium schreibt. Eine echte synchrone Kopie ist das aber nicht.
Besteht der Anspruch, bestehende NAS-Geräte so zu sichern, dass der gesamte Datensatz stets synchron auch woanders vorhanden ist, kommt Replikation als zusätzlicher Faktor hinzu. Zumindest die beiden genannten Hersteller vertreiben Tools für die Replikation von Volumes als Bestandteil ihrer NAS-Betriebssysteme. Unterschiede ergeben sich im Detail. Zudem zeigt sich hier, dass DR und klassische HA-Strategien eben doch nicht vollständig zu trennen sind. Denn Replikation ganzer Volumes kann sowohl für Disaster Recovery als auch für Hochverfügbarkeit hilfreich sein. Vereinfacht ausgedrückt verkürzt das Vorhandensein einer vollständigen Kopie eines NAS-Speichers auf Ebene der Volumes abhängig von der Konfiguration die Zeit bis zum Wiederanlauf.
Gut belegen lässt sich das anhand von QNAPs SnapSync- und Snapshot-Replica-Funktion (Bild 1). Letztere tut im Wesentlichen, was ihr Name suggeriert: Sie legt auf dem Quell-NAS von den Daten einen Snapshot an und kopiert diesen Snapshot dann auf ein anderes NAS-Gerät. Hier fehlt allerdings der Aspekt der Echtzeitsynchronisation. Den liefert SnapSync: Ein damit kopiertes Volume von NAS 1 existiert in exakt derselben Form stets auch auf NAS 2, dort allerdings im Read-Only-Modus. Voraussetzung dafür ist, dass sowohl Quell- als auch Ziel-NAS die QNAP-Firmware QuTS hero nutzen, das auf ZFS fußt.
Kommt stattdessen QTS mit ext4 als Dateisystem zum Einsatz, lässt sich das SnapSync-Feature zwar auch verwenden, es ergeben sich dann aber Unterschiede im Detail: In QuTS lässt sich auf dem zweiten NAS eine vorhandene Kopie eines Volumes unmittelbar in Betrieb nehmen. Wenige Mausklicks reichen dann aus, damit NAS 2 mit denselben Daten online geht, die zuletzt auch NAS 1 hatte. In QTS hingegen ist ein Replica-Snapshot lediglich dazu nutzbar, um das ursprüngliche Gerät wiederherzustellen.
Hier sind zwar Tricks denkbar, etwa das Anlegen einer lokalen Kopie des Replica-Snapshots auf NAS 2, die dann ihrerseits mit etwas Bastelei wieder zu einem eigenständigen, nutzbaren Volume wird. Elegant ist das aber nicht, und der Vorgang setzt voraus, dass NAS 2 genügend lokalen Speicher hat, um den gesamten Inhalt des NAS zumindest temporär vorzuhalten. Nachdem sich auf einigen QNAP-Geräten QuTS hero und QTS alternativ nutzen lassen, tun Administratoren also gut daran, eher auf das erstgenannte OS zu setzen.
Deutlich entspannter ist die Situation bei Synology: Hier fußt der Unterbau des NAS weitgehend auf Btrfs und seinen Snap-shot-Funktionen. Seit Synology auf Btrfs setzt, gibt es mit "Snap-shot Replication" auch eine Funktion für die Replikation ganzer Volumes. Diese lässt sich in den Snapshot-Einstellungen des Systems konfigurieren (Bild 2).
Kosten und Bandbreite bedenken
Gegenüber der zuvor beschriebenen Variante mit Backups per Synchronisationssoftware haben SnapSyncs in QNAP und Snapshot-Replicas in Synology den Nachteil, dass sie das Vorhandensein eines zweiten NAS-Systems voraussetzen. Dieses muss zudem über mindestens die gleiche Hardware wie das Ursprungssystem verfügen. Softwarestand und Konfiguration sollten zudem deckungsgleich zwischen den Geräten sein.
Im Gegenzug liefern dieser Ansatz aber auch einen zentralen Vorteil: Weil an einem anderen Ort bereits ein Datensatz vorhanden ist, der sich ohne viel Aufwand aktiv schalten lässt, ist die Wiederanlaufzeit bei diesem Ansatz kürzer als beim Wiederherstellen eines neuen Geräts etwa aus der Cloud. Höheren Anschaffungskosten stehen also möglicherweise geringere Ausfälle bei einer Katastrophe durch schnelleren Wiederanlauf gegenüber.
Nicht vergessen sollten Administratoren bei diesem Ansatz aber auch, dass er einige Anforderungen im Hinblick auf die zur Verfügung stehende Anbindung zwischen den beiden Standorten stellt. Sind diese in einem Unternehmen direkt miteinander verbunden, sollte die verfügbare Bandbreite ausreichend sein. Müssen die Daten allerdings durchs Internet und möglicherweise noch durch ein VPN, sieht die Sache schon anders aus. Vielerorts kommen schließlich asynchrone DSL-Verbindungen für die Anbindung von Büros zum Einsatz, die üblicherweise nicht mit dickem Uplink ausgestattet sind. Eine 50er-DSL-Leitung aber liefert im Schnitt fünf MByte Durchsatz pro Sekunde, was bei kontinuierlichem Schreiben auf das NAS bereits zu wenig sein kann.
Hier gilt es im Vorfeld also, den Bedarf zu erheben. Reicht der verfügbare Uplink nicht, fällt die Livereplikation ins Wasser. Backupmechanismen sollten zudem so konstruiert sein, dass sie die Daten vor allem dann ins Netz laden, wenn die Leitung ansonsten nicht genutzt wird, beispielsweise nachts.
Möglichkeiten mit Linux- und BSD-Bordmitteln
Deutlich heterogener gestaltet sich die Situation, wenn wir den Blick von den großen Anbietern abwenden und zu diversen Nischenprodukten schweifen. Asustor etwa bietet NAS-Geräte an, ebenso Ugreen. Hinzu gesellen sich diverse Kleinsthersteller. Hier sind die Fähigkeiten im Hinblick auf Disaster Recovery stark abhängig von der genutzten Software. Viele fertige NAS dieser Art kommen zwar mit einem GUI daher. Das ist aber meist nicht annähernd so umfangreich wie jenes der Platzhirsche.
Unter der Haube findet sich auch hier meist ein Linux- oder ein BSD-Derivat. Anders als bei QNAP und Synology lässt sich bei diesen Systemen aber die Kommandozeile im Gespann mit Linux-Bordmitteln meist hervorragend verwenden. Dann führt ein Weg zu DR über die Standardwerkzeuge etwa des Linux-Kernels. Wer asynchron hin zu einem anderen Standort replizieren kann, nimmt dafür beispielsweise DRBD, das Bestandteil des Linux-Kernels ist. Unter FreeBSD steht "High-Availability Storage", kurz HAST, zur Verfügung, der ähnlich funktioniert und vergleichbare Ergebnisse liefert.
Externe Backupsoftware als flexible Alternative
Liefert ein Gerät abseits der großen Hersteller keine befriedigende Backupfunktionalität oder genügen die in QNAP- oder Synology-Devices angelegten Funktionen den eigenen Ansprüchen nicht, kann eine valide Alternative der Umweg über eine Backupsoftware sein. Praktisch alle etablierten Werkzeuge wie Veeam oder Commvault bieten NAS-spezifische Funktionen oder eigene Varianten ihrer Programme für NAS-Laufwerke an.
Die Veeam Data Platform etwa ist darauf ausgelegt, sich mit den Netzwerkexporten vorhandener NAS-Geräte zu verbinden und von diesen Eins-zu-Eins-Kopien entfernt anzulegen (Bild 3). Zum Teil inter-agieren die Sicherungsprogramme auch unmittelbar mit den APIs der NAS-Laufwerke. Veeam ist hier allerdings nur ein Beispiel, auch andere Tools bieten entsprechende Funktionalität. Wer lieber auf Open Source setzt, findet auch in Bacula oder Bareos entsprechende Features. Hier führt der Weg meist über das Einhängen eines geteilten Volumes im lokalen Netz und das Kopieren der Daten.
Der Vorteil des Ansatzes ohne herstellerspezifische Werkzeuge besteht darin, dass eine Integration in normale Bordmittel jeder Linux-Distribution möglich ist. Das kann sowohl für Nischengeräte als auch für die großen Anbieter wie QNAP und Synology gelten. Binden Sie jene etwa an Bareos oder Bacula an, gelten dieselben Grundsätze in Sachen NAS-DR, die auch für den Rest der Infrastruktur Verwendung finden. Zudem sind Sie in diesem Szenario unabhängig von proprietären Funktionen einzelner Hersteller. Selbst wenn Sie also ein QNAP-NAS zu einem späteren Zeitpunkt durch ein Synology-Gerät ersetzen, ändert sich der DR-Ansatz dabei nicht.
Fazit
Disaster Recovery für NAS-Systeme erfordert eine klare Entscheidung: Entweder Sie nutzen die integrierten Backup- und Replikationsfunktionen von QNAP oder Synology, oder Sie greifen auf Linux-/ BSD-Werkzeuge und externe Software zurück. Maßgeblich ist das gewünschte Service-Level: Reicht eine Wiederherstellung mit Verzögerung, genügt eine Sicherung in der Cloud. Wer schnell wieder arbeitsfähig sein will, setzt auf ein zweites NAS mit Replikation. Für weniger bekannte Hersteller bieten Linux-Grundfunktionen und unabhängige Backupwerkzeuge praktikable Alternativen.
(ln)
Links
[1] HA bei QNAP und Synology in IT-Administrator 09/2023: https://it-a.eu/paz31