Selbstbau NAS RAID1 sinnvoll?

Zuaroacha

Lt. Commander
Registriert
Nov. 2001
Beiträge
1.157
Hallo,
ich bin gerade dabei mir ein NAS zu bauen mit XigmaNAS. Jetzt hab ich noch 2x Western-Digital Red herumliegen die im letzten "Soho" Server verbaut waren.
Die eine hat um die 50k und die andere 30k Stunden aktuell drauf, also nicht gerade wenig. Jetzt stellt sich mir die Frage, soll ich die beiden Platten ins NAS in einem RAID1 betreiben oder soll ich eine neue einzelne Platte besorgen.

Bevor hier die Diskussion RAID -> kein Backup aufkommt hier die Aufklärung.

Das NAS dient ausschließlich als Backup. Ich habe in meinen 2x HP-Servern einen Raid-Verbund und würde 1x pro Woche (ausreichend für Heimbetrieb) sämtliche VMs auf das NAS sichern.

Und ja, es gibt auch noch ein manuelles offline-Backup vom NAS -> externe Platte.

Aber die Frage ist, soll ich "versuchen" mit den WD-Reds zu fahren bis Sie wirklich das zeitliche segnen, oder eine neue Platte für das NAS besorgen?

Danke fürs Feedback!
LG
 
Willst du weiter backups machen koennen, falls eine Platte stirbt, bis du eine zweite besorgt hast -> nimm Raid 1.

Ist es dir egal -> nimm kein Raid1. Was auf den Platten liegt ist egal, Raid 1 nimmt man, um die Verfuegbarkeit zu erhoehen und fuer nichts anderes.
 
Genau, ich gehe ja davon aus, dass eine der beiden Platten mit dieser Laufleistung mal demnächst das zeitliche Segnen werden, wenn ich dann also RAID1 hätte, hab ich keinen Ausfall und ich muss erst "später" investieren. Wenn ich kein RAID1 mache, würde ich es nicht mit den alten Platten versuchen sondern direkt eine neue besorgen.
 
NJay schrieb:
Ist es dir egal -> nimm kein Raid1. Was auf den Platten liegt ist egal, Raid 1 nimmt man, um die Verfuegbarkeit zu erhoehen und fuer nichts anderes.
Najaaaa....
Ein Backup auf einer einzelnen Platte kann defekt und nicht wiederherstellbar sein, wenn die Platte ne Macke hat, ohne dass du das unbedingt zeitnah merkst.
Ich würde bei relevanten Daten immer nur auf gespiegelte Dateisysteme Backups machen.
 
NJay schrieb:
Raid 1 nimmt man, um die Verfuegbarkeit zu erhoehen und fuer nichts anderes.
Da würde ich widersprechen.

Ein Dateisystem wie ZFS oder BTRFS braucht natürlich redundante, gespiegelte Daten (und damit ein redundantes RAID), um fehlerhafte Daten aus der Redundanz wiederherstellen zu können.

Ansonsten trifft das, was du sagst, aber zu.
 
  • Gefällt mir
Reaktionen: KurzGedacht, iWaver und 0x7c9aa894
RAID ja, aber nur in Verbindung mit ZFS, Btrfs (oder in Zukunft Bcachefs).
Ein reines Hardware RAID 1 bringt die doppelte Gefahr von geflippten Bits.
 
  • Gefällt mir
Reaktionen: Banned
@Banned Bei ZFS könnte man sogar mit einer einzelnen Disk und der Option copies=2 Daten korrekt wieder herstellen aus defekten Blöcken. Ist ein gangbarer Weg wenn man z.B. ZFS auf einem Laptop nutzen möchte^^

@Zuaroacha Aus rein wirtschaftlicher Betrachtung macht es keinen Sinn jetzt schon neue HDDs zu kaufen und die alten weg zu schmeißen nur weil diese 50k/30k Stunden hinter sich haben. Du kaufst dir doch auch nicht sofort ein neues Auto nur weil das alte 100k km auf dem Tacho hat aber ansonsten noch funktioniert.
Auch neue Platten würden dich nicht vom Thema Backup befreien also solange die alten Laufwerke funktionieren und die Kapazität ausreicht spricht nix dagegen. Wenn sie in einer Woche oder einem Monat ausfallen brauchst erst dann Ersatz und wenn sie noch ein Jahr halten dann erst dann.
 
  • Gefällt mir
Reaktionen: Androos
Wenn du ZFS nimmst, sollte dir übrigens klar sein, dass bereits Sektorenfehler dazu führen, dass der ZFS pool extrem Performance einbüßt. Ich würde erstmal einen Short-Self-Test mit den Platten machen (z.B. mit GSmartControl unter windows oder smartctl unter *nix) und schauen, ob sie errors haben. Wenn sie schon errors haben, kauf neue. Wenn sie noch ohne Error sind, kannste die eigentlich noch nehmen.
 
Das wären mal die Werte von der "älteren" WD-Red...

Code:
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   180   176   021    Pre-fail  Always       -       5975
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       615
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   017   017   000    Old_age   Always       -       61036
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       171
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       123
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       491
194 Temperature_Celsius     0x0022   116   106   000    Old_age   Always       -       34
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0


Denke ich werd es mal mit dem RAID1 ggf. mit einem ZFS versuchen, da wie bereits zuvor erwähnt, dieses NAS nur das Backup für das laufende System ist und kein "klassisches" Datengrab.
D.h. ich müsste schon bei einer Trägermaschine einen RAID-Defekt haben und gleichzeitig auch noch das NAS verlieren, das ich wirklich Daten verliere.
Ich glaub für die Heimanwendung sollte das ausreichend sein :smokin:
 
KurzGedacht schrieb:
Najaaaa....
Ein Backup auf einer einzelnen Platte kann defekt und nicht wiederherstellbar sein, wenn die Platte ne Macke hat, ohne dass du das unbedingt zeitnah merkst.
Gescheite Backup-Software checkt das regelmäßig.

Banned schrieb:
Ein Dateisystem wie ZFS oder BTRFS braucht natürlich redundante, gespiegelte Daten (und damit ein redundantes RAID), um fehlerhafte Daten aus der Redundanz wiederherstellen zu können.
Nein, man kann auch ZFS so konfigurieren, dass es auf einer Platte Daten wiederherzustellen kann. Verringert dann natürlich die Kapazität.
 
NJay schrieb:
Nein, man kann auch ZFS so konfigurieren, dass es auf einer Platte Daten wiederherzustellen kann. Verringert dann natürlich die Kapazität.
Nur weil etwas technisch möglich ist, heißt das nicht, dass es auch praktisch sinnvoll ist.

Den von @snaxilian geschilderten Nutzungsfall mit einem portablen Gerät mal ausgeschlossen.

Ansonsten ist es natürlich sehr unclever, redundante Daten auf dem gleichen Datenträger zu speichern, der davon repariert werden soll. Das dies die Fehleranfälligkeit bzw. einen Datenverlust gegenüber einem RAID erheblich wahrscheinlicher macht, sollte auf der Hand liegen. Die Performance des Datenträgers sinkt ebenfalls, da ein Performancevorteil beim Lesen nicht mehr vorhanden ist, und Schreibprozesse doppelt auf dem gleichen Datenträger ausgeführt werden müssen.
 
Zuletzt bearbeitet:
Banned schrieb:
Ansonsten ist es natürlich sehr unclever, redundante Daten auf dem gleichen Datenträger zu speichern, der davon repariert werden soll. Das dies die Fehleranfälligkeit bzw. einen Datenverlust gegenüber einem RAID erheblich wahrscheinlicher macht, sollte auf der Hand liegen.
Backups brauchst du sowieso. Bzw da es hier ja um Backupdaten geht, hast du ja noch die originale. (Und nach 3-2-1 noch einw eiteres Backup)
 
Bei ZFS geht es hauptsächlich um die Integrität der Daten.

Was bringen dir 20 Backups, wenn du nicht weißt, ob die nicht korrumpiert sind?

Klar kannst du bei allen regelmäßig Prüfsummen abgleichen - aber das ist im Vergleich zu einem Dateisystem mit Sektorprüfsummen doch recht umständlich bzw. aufwendig.
 
Banned schrieb:
Bei ZFS geht es hauptsächlich um die Integrität der Daten.
Mich brauchst du von ZFS nicht ueberzeugen, ich nutze es selbst und bin grosser Fan davon.

Banned schrieb:
Was bringen dir 20 Backups, wenn du nicht weißt, ob die nicht korrumpiert sind?
Wenn deine Backups auf nem Dateisystem wie ZFS liegen oder das Backupprogramm selbst checksummen nutzt (z.B. borg-backup), dann weisst du, ob sie korrumpiert sind oder nicht.
 
NJay schrieb:
Wenn deine Backups auf nem Dateisystem wie ZFS liegen oder das Backupprogramm selbst checksummen nutzt (z.B. borg-backup), dann weisst du, ob sie korrumpiert sind oder nicht.
Wobei man bei den meisten Backup Programmen auch erst merkt dass das Backup ne Macke hat, wenn es eigentlich zu spät ist.
So eine Funktion ist am besten im Dateisystem aufgehoben. Da ist ZFS schon die richtige Wahl.
 
  • Gefällt mir
Reaktionen: Banned
KurzGedacht schrieb:
Wobei man bei den meisten Backup Programmen auch erst merkt dass das Backup ne Macke hat, wenn es eigentlich zu spät ist.
Vor allem ist es auch brutal umständlich und fehleranfällig. Angenommen das Backup ist korrumpiert. Dann muss man erst das nächste Backup anschließen und bei diesem wieder einen Abgleich machen, und hoffen, dass es okay ist. Und wer sagt einem eigentlich überhaupt, dass die gespeicherten Prüfsummen des Backup-Programms nicht korrumpiert sind?

Wenn man sowas über das Dateisystem (inklusive redundanter Daten) regeln kann, dann macht man es auch. Alles andere ist doch halbgares Zeug.
 
  • Gefällt mir
Reaktionen: KurzGedacht
Banned schrieb:
Und wer sagt einem eigentlich überhaupt, dass die gespeicherten Prüfsummen des Backup-Programms nicht korrumpiert sind?
Ehm.. das ist das gleiche Prinzip was auch ZFS nutzt... Also wieso sollte es ZFS erkennen?
KurzGedacht schrieb:
Wobei man bei den meisten Backup Programmen auch erst merkt dass das Backup ne Macke hat, wenn es eigentlich zu spät ist.
Bei ZFS sollte man auch regelmaessige scrubs machen, das kann man genauso bei seinem Backup regelmaessig machen.
 
NJay schrieb:
Ehm.. das ist das gleiche Prinzip was auch ZFS nutzt...

Im Prinzip schon, das stimmt.

Der Unterschied ist jedoch:
Das Backup-Programm erstellt die Prüfsumme pro Datei und nicht pro Sektor, oder? Dies erhöht zumindest die Fehleranfälligkeit bzw. vermindert die Chance, den Fehler beheben zu können.

Auch kann keine automatische Reparatur stattfinden, da keine direkt vorhandene Redundanz.
Man müsste dann manuell das nächste Backup anschließen und analysieren bzw. vergleichen.

Das ist schon echt umständlich.

Am einfachsten ist es, ein ZFS-RAID zu haben und davon ein Backup zu machen und noch ein weiteres zu haben. Beim Erstellen des Backups bzw. beim lesen jedes Sektors wird automatisch ein Abgleich vorgenommen. So macht man quasi zwei Arbeitsschritte auf einmal (Prüfung in ZFS und Erstellung des Backups).
 
Banned schrieb:
Das ist schon echt umständlich.

Am einfachsten ist es, ein ZFS-RAID zu haben und davon ein Backup zu machen und noch ein weiteres zu haben. Beim Erstellen des Backups bzw. beim lesen jedes Sektors wird automatisch ein Abgleich vorgenommen. So macht man quasi zwei Arbeitsschritte auf einmal (Prüfung in ZFS und Erstellung des Backups).
Ich will dir gar nicht widersprechen. Ein ZFS RAID auf Host und Backup zu verwenden und einfach snapshots zu verschicken ist eine sehr elegante Loesung. Aber halt nicht die einzige valide Loesung.
 
  • Gefällt mir
Reaktionen: snaxilian und Banned
Zurück
Oben