Ein NAS ist ein NAS und benötigt ein eigenes Backup.
Auf einem NAS liegen Daten, und die brauchen immer mindestens zwei Backups.
Ein NAS mit RAID wird erst mit einem RAID 5 interessant (HDD im Betrieb austauschbar).
RAID1 ist ebenfalls im Betrieb austauschbar.
(Es wäre schön, wenn wir uns wieder daran erinnern, wofür das "R" in RAID steht! Deshalb schrieb ich das nämlich in meinem letzten Beitrag fett.)
Ein NAS im Privatbereich benötigt kein RAID, RAID erhöht nur die Verfügbarkeit.
Ein NAS ohne RAID ist bei einem Datenträgerausfall bis zum vollständigen Zurückspielen des externen Backups down. Ein Backup mit
RAID ist nur während des Datenträgerraustauschs down (bei hotswap nicht mal das).
Du hast also recht, dass RAID die Verfügbarkeit erhöht. Die Entscheidung, ob das der Privatanwender braucht (oder haben will), überlass doch bitte ihm!
Persönlich will ich auch immer alles, baue alles ein, dann funktioniert es kurzfristig bis zum nächsten Update.
Natürlich sollte man bei Produktivsystemen die Komplexität nicht über die eigene Kompetenz hinaus erhöhen, denn dann ist das Geschrei groß, wenn es klemmt.
Genau deshalb habe ich das Asustor-NAS ja nicht durch OMV ersetzt, denn der Nutzer kann kein RAID-Rebuild auf der Konsole. Das Asustor-Linux kommt nach dem HDD-Tausch mit degraded RAID von selbst wieder hoch und fragt nach ob es ein Rebuild machen soll. Dann klickt man ja, arrangiert sich ein paar Stunden mit verringerter Performance und danach ist alles wieder schick.
Was, wenn NAS selbst Sicherungsziel ist? Braucht man dann eine Sicherung von der Sicherung?
Ja, braucht man. Eine zweite Sicherung brauchst du aus zwei Gründen:
1. Bei einem korrupten Datensatz (Arbeitssystem oder Sicherung) kannst du bei nur zwei Datensätzen im schlimmsten Fall nicht entscheiden, welcher Datensatz korrupt ist. ECC, Dateisystem-Journals und was dir sonst noch an Fehlerkorekturmaßnahmen einfallen, können das Risiko drastisch senken, lösen aber das Problem nicht.
2. Beim Backup gibt es einen Zielkonflikt: Einerseits soll es schnell verfügbar sein, andererseits soll es ausfallsicher sein. Dein lokales Backup ist schnell verfügbar, wird aber zusammen mit deinen Arbeitsdaten vernichtet, wenn dein Haus abbrennt. Daher brauchst du ein Offsite-Backup an einem anderen Ort.* In Zeiten schnellen Internets ließe sich auch ein Offsite-Backup schnell anbinden, aber wer dafür einen Cloud-Dienstleister in Anspruch nimmt, macht sich von dessen Vefügbarkeit abhängig, weshalb das keine alleinige Option ist.
Was, wenn man schnelle temporäre Datenablage will die schnell beschrieben und genauso schnell gelöscht werden soll? Brauche ich da auch eine Erhöhung der Verfügbarkeit durch RAID5?
So einen Datenspeicher nannte man früher "Scratch-Platte". Das ist prinzipiell nichts für ein NAS, denn da wird das Netzwerk zum Flaschenhals. Ein Scratch-Speicher sollte idealerweise eine lokale SSD sein.
Echtes
RAID ist für so einen Datenträger zwiespältig. Striping über mehrere Datenträger erhöht zwar den Durchsatz, aber Parity ist eher kontraproduktiv. Am praktikabelsten wäre wohl ein RAID0**, falls eine einzelne SSD noch zu langsam ist.
Oder warum soll ich bei kritischen Daten nur den Ausfall einer HDD abfangen und nicht zwei, drei, ...?
Kannst du auch machen (siehe z.B. RAID6, RAID10). Das kann man prinzipiell ins Unendliche treiben, wird man aber nicht tun, denn auch ein RAID mit interner Redundanz ist als Gesamtsystem immer noch ein Single Point of Failure (z.B. bei Ausfall des RAID-Controllers). Daher wird man recht schnell auf externe Sicherungen wechseln, wenn eine gewisse Grundredundanz innerhalb des RAIDs erreicht ist und man die Sicherheit weiter erhöhen will.
*) (im sinnvollen Rahmen) physisch so weit weg wie möglich: Das offsite-Backup ist nicht wirklich "offsite" wenn es beim Nachbarn im selben Mietshaus steht und beide Wohnungen gemeinsam abbrennen. Bei einem Atombombenabwurf möchtest du es in einer anderen Stadt haben, bei einem größeren Meteoriteneinschlag auf einem anderen Planeten. Das ist halt Abwägung.
**) was kein echtes
RAID ist.
