Ersatz für DS213+ - was bringt ECC RAM?

[DS213+]

Da es ab 2024 keine Updates mehr gibt und auch die 4TB Ironwolf mit > 60.000 Stunden nicht das ewige Leben haben wird suche ich Ersatz. Eingebaut werden soll eine 8 TB 870 QVO.

Es soll wieder ein Plus Modell werden. Jetzt habe ich mich ein bisschen über BTRFS, die nicht komplette Implementierung bei Synology, die Notwendigkeit von RAID für die Fehlererkennung und das es ohne ECC RAM nicht sinnvoll ist eingelesen. Habe da auch mitbekommen, das die Meinungen wohl auseinander gehen.

Was kann BTRFS bei Synology besser als EXT4, was bringt dann noch ECC RAM und was RAID? Bisher bin ich mit EXT4 gut gefahren.

Wenn ich keinen ECC RAM benötige würde ich eine DS223+ (die ja wahrscheinlich auch wie die DS423+ mit dem 4 Kern Celeron aus der DS720+/DS920+ kommt) und hätte ein sparsames System. Sonst müsste ich ein Ryzen NAS nehmen und hätte einen höheren Leerlaufverbrauch.

 

[ottosykora]

es gibt mittlerweile nützliche Apps die man ohne btrfs gar nicht erst installieren kann

Raid , so heisst es, erhöht die Verfügbarkeit der Daten. Also wenn eine Platte defekt ist, läuft alles weiter, man kann dan eine neue Platte kaufen, einschieben und hat dann wieder alles ohne Betriebsunterbruch oder Backup zurückspielen etc

 

[plang.pl]

ECC RAM kann einen Bit-Rot im Life Betrieb verhindern / bzw korrigieren. Ohne ECC RAM musst du bei so einem Bit-Rot das ganze Dateisystem prüfen und mithilfe des RAIDs / der btrfs-Checksumme wiederherstellen

 

[DS213+]

Ok, danke. Bedeutet mit ECC RAM bräuchte ich kein Raid und hätte trotzdem den Bit-Rot Schutz? Weil die Verfügbarkeit brauche ich nicht und Backups habe ich.

 

[plang.pl]

Nein, geht nur mit RAID/SHR

 

[DS213+]

Ok, konnte ich mir auch nicht erklären. War da nicht was, das es bei Synology trotzdem nicht geht, weil es das falsche (nicht BTRFS) RAID hat und somit zwar den Fehler über die Prüfsumme feststellt, ihn aber nicht reparieren kann weil die Platte nicht bekannt ist?

 

[plang.pl]

Synology verwendet nicht das RAID, das btrfs mitliefert, sondern mdadm. Mit der Datenintegrität hat das aber meines Wissens nichts zu tun.

 

[DS213+]

Relativ weit unten im Link:
„Synology legt nun aber unter das Btrfs-RAID ein LVM, wodurch diese automatische Korrektur nicht mehr möglich ist. Das System erkennt nun zwar eine Datei mit defekten Bits, da die Prüfsummen nicht stimmen. Es kann den Schaden aber nicht mehr automatisch reparieren, da es nicht weiß, von welcher Platte die defekten Daten stammen.“ https://linuxundich.de/gnu-linux/synology-btrfs-snapshots/

 

[plang.pl]

Aha!
Das ist mir neu. Wenn das aber stimmt, wäre das schade.

 

[DS213+]

Je mehr ich lese um so unsicherer werde ich. Bitkippen tritt lt. einer Google Studie viel häufiger im Speicher auf als auf den Platten. Und wenn da was kippt bekommt es das Filesystem nicht mit.

 

[plang.pl]

Naja, man muss auch die Kirche im Dorf lassen. Seit fast 7 Jahren intensiver NAS-Nutzung im Dauerbetrieb ist mir so etwas noch nicht passiert. Aber es ist natürlich immer schade, wenn technisch vorhandene Möglichkeiten nicht genutzt werden

 

[DS213+]

Hat Synology die Selbstheilung mittlerweile aktiv? Oder immer noch nur Meldung?

Bekomme ich die Meldung auch mit einer Platte hin (scrubbing)? Dann könnte ich das vor jedem Backup machen und könnte so sicher stellen, das der Fehler nicht ins Backup wandert. Oder passiert das automatisch, da beim Backup ja alle Dateien gelesen werden?

 

[Jagnix]

Es kann den Schaden aber nicht mehr automatisch reparieren, da es nicht weiß, von welcher Platte die defekten Daten stammen

Der Artikel ist von 2016 ... kann mir gut vorstellen das sich da einiges getan hat.

 

[DS213+]

Glaube ich nicht. Dann müsste Synology das BTRFS RAID nehmen und das ist für RAID 5 / 6 noch nicht stabil.

Edit: scheint doch aktiv zu sein
https://kb.synology.com/de-de/DSM/tutorial/How_to_enable_file_self_healing_on_DSM

 

[DS213+]

Edit 2: Synology scheint nicht die BTRFS Heilung zu nutzen, sondern etwas Proprietäres. BTRFS bringt nur die auslösende Fehlermeldung und dann wird wie auch immer geheilt. Ich habe dazu nirgendwo eine Beschreibung gefunden.

 

[DS213+]

Zwischenfazit:

ECC RAM ist für die Datenintegrität wichtig, hat aber mit dem Filesystem nichts zu tun. Bitkippen im Speicher tritt öfter auf als auf den Platten.

RAID mit Redundanz und BTRFS und pro Ordner extra eingeschaltet ist für die Selbstheilung nötig. Was Synology da genau macht ist unklar. Warum das nicht für das gesamte Volume geht auch.

Ob mir BTRFS für die Datenintegrität bei nur einer Festplatte etwas nützt weiß niemand.

 

[plang.pl]

Nein, geht nur mit RAID/SHR

 

[Jagnix]

Ich habe dazu nirgendwo eine Beschreibung gefunden.

Nicht verzagen Synology fragen.

 

[synfor]

Ob mir BTRFS für die Datenintegrität bei nur einer Festplatte etwas nützt weiß niemand.

Natürlich nützt dir das. Du erfährst, wenn Daten kaputt sind. Reparatur ist dann aber nicht.

 

[himitsu]

Du erfährst, wenn Daten kaputt sind.

Und welche Daten kaputt sind, bzw. Welche höchstwahrscheinlich noch OK sind.



ECC, RAID und Btrfs miteinander zu Verlgeichen
ist wie Äpfel mit Birnen Tofu oder Steak.

RAID ist als Ausfallschutz für eine Festplatte, also weiterarbeiten ohne Unterbrechung trotz "eines" Fehlers.
Backup ist auch erstmal ein Ausfallschutz, aber hier steht erstmal alles Still und man muß erst reparieren und das Backup zurück spielen.
Auch schützt das Backup vor Datenverlusten durch Löschen oder Überschreiben. (ausversehn oder durch böse Buben)

Btrfs hat für Datenschutz und Verschlüsselung etwas mehr in petto.
Und über die Snapshots hat man eine ultraschnelle Versionierung, ähnlich wie beim Backup.
-> ja, z.B. Docker und VMM benutzen SubVolume und Snapshot des Btrfs.

ECC schützt vor fehlerhaftem Arbeitsspeicher/RAM (die Anderen vor defekten Daten/Festplatten).
Bit Rot und Co., also wenn der Fehler nur gering ist (ein Bit unentdeckt defekt und nicht gleich der Totalausfall des Riegels) und anfangs nicht auffällt. dann können fehlerhafte Daten auf dem Datenträger landen und erst viel später auffallen, wenn schon zuviel kaputt ist.