Die congenio hat eines der neuen Ugreen NASync-Systeme bestellt, die  aktuell vergünstigt über Kickstarter bezogen werden können. Auf der Seite von Ugreen werden  Informationen zu RAID-Levels usw. zur Verfügung gestellt, die ziemlich schlecht und teilweise sogar falsch ins Deutsche übersetzt wurden. Auch aufgrund der Tatsache, dass die Fakten dort nur aufgezählt, aber nicht eingeordnet werden, entsteht ein irreführender Eindruck davon, was mit der angebotenen Hardware sinnvollerweise getan werden könnte bzw. sollte. Tatsächlich befindet sich die Software aktuell in Entwicklung, es ist aber absehbar, dass sie bestimmte Entwicklungen nicht aufgreift und daher von Beginn an eher schlechter (da unreifer) als aktuelle Lösungen anderer Hersteller wie Synology oder QNAP sein wird. Dieser Artikel soll zeigen, was wir mit der Hardware vorhaben und welche Vorteile das gegenüber der von Ugreen angebotenen Software-Lösung bieten kann. Manchen Leser werden die Informationen vielleicht sogar dazu bringen, ein anderes Modell zu wählen als bislang geplant. Ganz falsch ist der oben verlinkte Artikel natürlich nicht, denn er gibt immerhin einen grundsätzlichen Überblick über die zur Verfügung stehenden Verfahren, mit denen sich Redundanz erzielen lässt. Für die meisten Anwendungsfälle wird der gezogene Schluss so ausfallen, dass man die im NAS verbauten Festplatten in einem RAID5-Verbund betreiben wollen wird, bei dem eine zusätzliche Platte nur für Redundanzzwecke eingesetzt wird. Das ist jedoch, gelinde gesagt, suboptimal - aus verschiedenen Gründen:

• Bei einer kleineren Anzahl von Platten ist der Verschnitt entsprechend hoch, z.B. bleiben 25% der Kapazität eines 4-Bay-NAS ungenutzt. Und das, obwohl die Ausfallsicherheit dadurch keineswegs garantiert ist (siehe nächster Punkt).
• RAID5 schützt - theoretisch - vor einem Ausfall einer einzelnen Festplatte, ohne, dass Daten verloren gehen.
  
  
  Warum nur theoretisch?
  
  
  Das ist auf die Funktionsweise eines RAIDs zurückzuführen: Ein auftretender Fehler wird nämlich nur dann erkannt, wenn eine Festplatte diesen Fehler selbst meldet, z.B. bei einem defekten Datenblock oder durch eine Rückmeldung, dass die Platte nicht angesprochen werden kann. Es gibt aber Fehlerarten, bei denen eine solche Meldung unterbleibt, nämlich, wenn die Elektronik versagt (z.B: RAM-Puffer defekt) oder auch einfach, weil ein Lesefehler unentdeckt bleibt.
  
  
  Letzteres tritt leider häufiger auf als gedacht: Da Festplatten heute mit Speicherdichten nahe der Rauschgrenze betrieben werden, arbeiten sie ständig mit Korrekturcodes, die gewisse Fehlerwahrscheinlichkeiten aufweisen. Sogar bei Enterprise-Modellen von Festplatten werden z.B. Fehlerraten von 1 Fehler auf 10^15 Bits angegeben, was einem falschen Byte in 125 TByte entspricht. Bei Desktop-Modellen liegt die Rate sogar um den Faktor 10 höher. Das bedeutet im Endeffekt, dass beim Lesen einer 18-TByte-Festplatte (solche liegen zur Zeit im "Sweet Spot" beim Preis pro Terabyte) im Mittel 1,5 fehlerhafte Bits geliefert werden.
  
  
  Das wirklich Schlimme dabei ist, dass solche Fehler durch RAID überhaupt nicht entdeckt werden! Es würde interessanterweise aber auch nichts helfen: Nehmen wir an, dass beim Lesen immer alle 4 RAID5-Platten gelesen würden. Selbst, wenn jetzt beim Vergleich auffiele wird, dass die Daten der drei "Daten"-Festplatten nicht zu den Daten von der vierten, "Redundanz"-Festplatte passen: Was sollte man jetzt tun? Da keine der beteiligten Festplatten einen Datenfehler anzeigt, kann man keine Korrektur vornehmen, weil man ja nicht weiß, welche der vier Platten fehlerhafte Daten geliefert hat. Tatsächlich wird aus diesem Grund auf das Lesen aller Festplatten verzichtet, wie  Tests von Level1Techs (sehr sehenswert!) bewiesen haben.
  
  
  Man muss sich das einmal klarmachen: Wenn man einfach auf einer der RAID5-Festplatten direkt beliebige Daten schreibt, werden diese ohne Abwehr durch das RAID-System zurückgeliefert und man merkt nicht, dass dies nicht mehr die ursprünglichen Daten sind!
  
  
  Erschwerend kommt noch eines hinzu: Wenn eine Festplatte ausgefallen ist, wird man sie normalerweise schnellstmöglich durch ein neues Exemplar ersetzen. Dann muss jedoch die Redundanz neu hergestellt werden, wozu alle Platten einmal komplett gelesen werden müssen. Das bedeutet, es werden beispielsweise bei 18-TByte-Festplatten 54 TByte gelesen und 18 TByte geschrieben. Einerseits ist das Risiko hoch, dass bei dieser großen Beanspruchung eine weitere Festplatte versagt, andererseits treten dabei wiederum statistisch 5 Bitfehler auf, die dann ggf. für die Zukunft erhalten bleiben, weil dann entsprechend fehlerbehaftete Redundanzinformationen geschrieben werden - beim Schreiben treten noch 1,5 weitere Bitfehler auf.

Leider nur sehr bedingt: RAID6 hilft, wenn mehr als eine Festplatte gleichzeitig ausfällt, oder wenn bei der Recovery eine weitere Festplatte versagt. Die genannten Einschränkungen in Bezug auf die Erkennung, wann ein Fehler aufgetreten ist, sind jedoch die selben wie bei RAID5. Zusätzlich erhöht sich auch noch der Verschnitt - ein RAID6 mit 4 Festplatten ist z.B. wenig sinnvoll, da bereits 50% der Kapazität nur für Redundanz und nicht für Nutzdaten zur Verfügung stehen. Vor diesem Hintergrund ist es umso verwunderlicher, dass offenbar der überwiegende Teil der Kickstarter-Backer ausgerechnet das 4-Bay-NAS DXP4800 gewählt hat. Unserer Meinung nach benötigt man mindestens ein 6- oder 8-Bay-NAS. Zum Glück gibt es mit dem Zettabyte Filesystem (ZFS) seit einigen Jahren eine sinnvolle Alternative. Dieses Dateisystem deckt verschiedene Bereiche ab, die normalerweise in verschiedenen Subsystemen bzw. Schichten liegen:

• ZFS integriert RAID5/6/7, dort heißt dies raid-z1/z2/z3 für jeweils eine, zwei oder drei redundante Festplatten.
• ZFS betreibt konsequente Prüfsummen auf allen Ebenen (Datei, Block und Metadaten). Es ist praktisch unmöglich, dass ein Datenfehler unbemerkt bleint, da ZFS eigene, von der Festplatten-Hardware unabhängige Prüfsummenverfahren nutzt. Es kann also durchaus vorkommen, dass Lesefehler auftreten - diese werden aber immer bemerkt und gemeldet und im Fall von raid-z eben auch korrigiert.
• Ein weiterer Vorteil von ZFS liegt darin, dass es ein Copy-On-Write (COW) Dateisystem ist: Jede Änderung wird zunächst geschrieben, bevor ggf. alte Daten gelöscht werden. Dadurch ist ZFS transaktionssicher und es kann vor allem Snapshots anlegen - indem man die alten Daten nicht sofort freigibt, sondern nur markiert, kann man den vorherigen Zustand wieder herstellen. So kann man z.B. regelmäßige Aufgaben erstellen, bei der z.B. alle 15 Minuten ein Snapshot erzeugt wird. Diese Snapshots belegen nur Speicherplatz, wenn etwas geändert wurde. Durch Angabe einer gestaffelten Haltedauer kann der Speicherplatz dann nach Ablauf wieder freigegeben werden.
  
  
  Diese Snapshots können per Samba als "Vorgängerversionen" sichtbar gemacht werden. Vorbei also die Zeiten von "Oh, ich habe aus Versehen dieses Dokument überschrieben!"
• ZFS raid-z hat einen etwas größeren Verschnitt als das entsprechende RAID-Verfahren, gleich dies allerdings durch eine im Dateisystem selbst vorgenommene Komprimierung aus (wirkt natürlich nur bei Daten, die nicht bereits vorab komprimiert sind wie Videos oder MP3). Es wird auch häufig empfohlen, die freie Kapazität nur bis zu 80% auszunutzen, wodurch die zur Verfügung stehende Kapazität weiter sinkt. Tatsächlich ist es dann nur schwerer, zusammenhängenden freien Platz zu finden, d.h. Dateien werden dann eventuell stärker fragmentiert und das Lesen wird entsprechend langsamer. Das gilt allerdings nur im Verhältnis zum Gesamtspeicher große Dateien, was bei heutigen Dateisystemgrößen von vielen Terabyte kaum ins Gewicht fallen dürfte, denn selbst große Videodateien haben maximal einige Gigabyte.
• Ein oft genanntes Problem von ZFS ist, dass viel RAM für ein effizientes Arbeiten benötigt wird. Dies Rede ist oft von 1 GByte RAM für jeweils 1 TByte Festplattenkapazität. Richtig ist, dass ZFS geschwindigkeitsmäßig von RAM profitiert, notwendig ist dies jedoch nicht.
• Ein weiteres angebliches Problem ist, dass für absolute Sicherheit auch ECC-RAM bentigt wird. Natürlich kann ZFS nicht verhindern, dass durch Umkippen eines Bits im RAM der gelesene Inhalt verfälscht wird, bevor er verarbeitet werden kann, jedoch ist die Wahrscheinlichkeit hierfür sehr viel geringer als ein Festplattenfehler.
• Eine Kapazitätserweitertung ist bei ZFS raid-z ebenso möglich wie bei RAID - wenn man noch freie Einschübe hat! Auch hier irrt übrigens der oben verlinkte Artikel von Ugreen: Inzwischen ist das auch ohne Verdopplung der Anzahl von Festplatten möglich, dieses Feature ist noch relativ jung. Es gibt subtile Unterschiede beim anfänglichen Verschnitt nach einer erfolgten Erweiterung, bei raid-z bleibt er anfangs für vorhandene Dateien beim alten Wert, beim Hinzufügen einer 5. Festplatte zu einem RAID5 sinkt der Verschnitt z.B. von 25% auf 20%, bei raid-z1 bleibt er für die alten Dateien erst bei 25%. Aufgrund COW würde der Wert beim Umkopieren von Dateien (genau wie für neue Dateien) aber sinken.

Durch die   Ankündigung von Ugreen, dass die Nutzung alternativer Betriebssysteme ohne Gewährleistungsverlust zuzulassen, ist es möglich, beispielsweise  Proxmox VE mit ZFS,  TrueNAS Core (FreeBSD-basiert) oder  TrueNAS Scale (Linux-basiert) zu verwenden. Wir raten stark dazu, dies zu tun, um in den Genuss der Vorteile von ZFS zu gelangen. Mit dem Schwerpunkt "reines NAS" wären die TrueNAS-Varianten vorzuziehen, wobei inzwischen TrueNAS Scale mehr Erweiterungsmöglichkeiten als das ältere TrueNAS Core bietet. Wer dagegen stärker auf Virtualisierung setzt, macht mit Proxmox VE sicher nichts falsch. Dazu sollte man allerdings das RAM aufrüsten, mindestens 32 GByte wären angezeigt. Den NAS-Teil kann man dann wahlweise auch mit einer echten NAS-Lösung wie TrueNAS in einer virtuellen Maschine abbilden. Eine mögliche Alternative zum ZFS-Einsatz wäre  Unraid. Dies gilt insbesondere, falls vorhandene Festplatten unterschiedlicher Größe genutzt werden sollen. Hierbei wird jeweils die größte Festplatt oder die beiden größten Festplatten als reine Redundanzlaufwerke verwendet (ähnlich wie RAID5 oder RAID6). Anders als bei klassischem RAID werden auch immer alle Platten gelesen, wodurch Fehler zumindest auffallen - also etwas cleverer als RAID, andererseits ist die Lesegeschwindigkeit die der langsamsten Platte. Außerdem ist Unraid kostenpflichtig und inzwischen sind keine neuen Lizenzen auf Lebenszeit mehr erhältlich.

• RAID5 ist nicht wirklich verläßlich, man "will" eigentlich doppelte Redundanz, also mindestens RAID6.
• Ein 4-Bay-NAS wie das DXP4800 ist für RAID6 bzw. ZFS raid-z2 wegen hohen Verschnitts ungeeignet, man sollte mindesten 6 oder 8 Bays nehmen.
• Die noch sehr frische Ugreen UPRO Software ist für uns ungeeignet, wir würden TrueNAS (Scale) oder Proxmox VE verwenden.
• Kapazitätserweiterung ist auch mit ZFS möglich - natürlich nur mit freien Festplatten-Slots.
• Falls Virtualisierung angepeilt wird: Mehr RAM ist Pflicht - angeblich gehen im DXP6800 und DXP8800 96 GByte.

Ein wichtiger Hinweis an dieser Stelle: Weder RAID noch ZFS ersetzen ein Backup! Gerade bei Einsatz als NAS - also als Netzwerkspeicher - muss man sich klarmachen: Wenn beispielsweise ein Kryptotrojaner die Daten auf dem NAS verschlüsselt oder löscht, kömmt man trotz noch so guter Redundanz (=Ausfallsicherheit) nicht an sie heran. Wiewohl also ZFS mit Snapshots einen kleinen Baustein im Puzzle liefert (man kann auf einen alten Stand zurück), sollte man auf eine zusätzliche Backup-Lösung nicht verzichten. Spinnt man den Gedanken noch weiter, wäre es sogar noch besser, sich durch ein Offsite-Backup abzusichern, also ein Backup, dass nicht einmal am selben Ort stattfindet (man denke an ein Feuer im Haus). Mit Differenz-Sicherungen kann so etwas mit aktuell verfügbaren Datenraten auch über das Internet erfolgen. Traut man der "Cloud" nicht, dann vielleicht einem Freund, der das gleiche Problem hat. Mann kann sich dann gegenseitig Speicherplatz zur Verfügung stellen und diesen dann für nächtliche Backups nutzen. Eine besonders charmante Lösung stellt dabei  Proxmox Backup Server dar. Dieser lässt sich auch als virtuelle Maschine unter Proxmox VE betreiben und kann im Pull-Betrieb sicher vor Kryptotrojanern Daten "ziehen", bei gleichzeitiger Speicherplatzeinsparung durch Deduplizierung. Und das alles umsonst! Man könnte also z.B. gleich zwei NAS-Systeme bestellen - oder noch besser: ein Größeres, denn da sinkt auch der Verschnitt! Sagten wir eigentlich schon, dass das DXP4800 keineswegs die Ideallösung darstellt?