Synology Volume reparieren ohne Festplatten Inhalte zu löschen

[Zoker]

Hallo zusammen,

ich wollte heute mein NAS (Synology DS918+) reinigen und habe es deshalb heruntergefahren. Ich habe leider nicht bemerkt, dass das NAS mit angezeigt hat, dass noch ein Backup Auftrag am laufen ist und das NAS deswegen nicht heruntergefahren werden kann (ja ich bin zu schnell von der Seite weggegangen, das war definitiv ein großer Fehler). Ich konnte kein Festplatten Geräusch vernehmen und die LEDs sind per Einstellungen deaktiviert, deswegen dachte ich es sei aus und habe eine Festplatte herausgenommen. Das NAS hat sofort angefangen zu piepen und ich habe die Platte auch sofort wieder reingesteckt. Das piepsen hat nicht aufgehört und im DSM wurde mir angezeigt, dass mein Volume jetzt degraded ist. Wenn ich nun auf reparieren klicke, sagt mir das System, dass der komplette Inhalt der Platte gelöscht werden muss.
Nun meine Frage: Ist es möglich das Volumen zu reparieren, ohne alle Daten zu löschen? Immerhin handelt es sich um eine 6TB Platte und ich schätze, dass das widerherstellen des SHR Raids sehr lange dauert.

Vielen Dank schonmal!

 

[conf_t]

Da hast du was falsch verstanden. Weil die Festplatte im Betrieb rausgezogen wurde muss ein RAID Rebuild erfolgen. Dazu wird die herausgezogene HDD gelöscht und die Daten anhand der Paritätsdaten auf den anderen 3Platten wiederhergestellt
Also die HDD muss zwingend gelöscht werden. Dein Volume, also die anderen 3HDDs werden nicht gelöscht.

Aber bevor du loslegst:
welches RAID hast du? SHR1 oder SHR2?
Welche HDDs hast du verbaut? Beides relevant für die Wrfolgswahrscheinlochkeit des Rebuilds.
Mache vorher noch ein Backup.

 

[t-6]

Nein, ist afaik nicht möglich bzw. würde es wahrscheinlich genauso lange dauern.

In dem Moment wo du die Festplatte gezogen hast, hat das Volume bzw. die Daten auf dem Volume ja nicht einfach aufgehört zu "arbeiten". Es fehlen die Paritätsinformationen für alle Daten die nach dem Ziehen der Platte erstellt wurden, so dass wenigstens für diese Daten durch die RAID-Reparatur Parität nachträglich neu berchechnet werden muss. Und da afaik nicht Buch darüber geführt wird für welche Blöcke Paritätsinformationen vorhanden sind und für welche nicht, muss der RAID-Rebuild ohnehin alle Blöcke anfassen, lesen, Paritätsinformationen berechnen und dann schreiben. Oder wenigstens vergleichen ob evtl. bereits vorhandene Paritätsinformationen identisch zu den berechneten sind.

Möglich dass bestimmte RAID-Controller bzw. andere RAID-Systeme damit effizienter umgehen, aber ich hab noch nie gesehen dass bei Synology nicht ein voller Rebuild nach versehentlichem Ziehen einer HDD nötig wird.

Ergänzung: Allein schon aus Konsistenzgründen muss eine vollständige Überprüfung stattfinden. Das RAID hat die "Hoheit" über die Festplatte für eine Zeit verloren. Eine gerechtfertigte Annahme wäre, dass die Daten auf der gezogenen Festplatte zwischenzeitig geändert wurden, so dass dem Datenzustand der HDD überhaupt nicht mehr zu trauen ist ohne eine komplette Überprüfung vorzunehmen. Und wenn man schon mal dabei ist, kann man eigentlich auch gleich die Daten direkt neu schreiben.

 

[Zoker]

welches RAID hast du? SHR1 oder SHR2?
Welche HDDs hast du verbaut? Beides relevant für die Wrfolgswahrscheinlochkeit des Rebuilds.

SHR1, da ich nur eine Platte Redundanz habe und bei 2x 4TB und 2x 6TB insgesamt 13TB Speicher.
Beides sind WD Red und zwar WD40EFRX und WD60EFRX

Dann mache ich jetzt mal ein Backup und baue dann das Array neu.

Wie hoch sind denn die Wahrscheinlichkeiten, dass das ohne Probleme neugebaut werden kann?

 

[LGTT1]

@Zoker naja das Array baust du nicht neu du lässt es reparieren/wiederherstellen dafür gibt es ja die Redundanz.

 

[t-6]

Wie hoch sind denn die Wahrscheinlichkeiten, dass das ohne Probleme neugebaut werden kann?

Schwer zu sagen. Hängt vom Alter/Verschleiß der Festplatten ab.
Ein RAID-Rebuild ist sehr belastend für alle beteiligten HDDs, und aufgrund zunehmender Rebuild-Dauer mit zunehmender HDD-Größe ist es nicht unwahrscheinlich ist dass ausgerechnet beim Rebuild eine weitere HDD aussteigt. Deswegen verliert RAID5 & Co. in den letzten Jahren zunehmend an Popularität.
Wenn eine der HDDs kürzlich angefangen hat fehlerhafte Sektoren zu werfen, ist das Risiko noch mal höher bzw. ein Indikator dafür, dass der Rebuild mit höherer Wahrscheinlichkeit schiefgeht.

Mach ein Backup & prüf das Backup bevor du den Rebuild anstößt.

 

[conf_t]

WD Red sind nicht zu empfehlen für RAIDs mit einfacher Parität, wegen der schlechten unkorrigierbaren Lesefehlerrate von 1:10^14. Damit sollte man den Betrieb von Volumes größer 12 TB vermeiden, da man dann beim Rebuild mit unkorrigierbaren Lesefehlern rechnen muss. Sprich beim Rebuild wird irgendwo ein Bit kippen können und eine Datei kaputt gehen können. Das ist wie durch einen Vogelschwarm fliegen.

Auch hier ist bei solchen Platten aus diesem Grundsuf doppelte Parität imRAID zu setzen, oder man kauft sich bessere (nicht mal wirklich teurere) Platten.

Aber grundsätzlich sollte das Rebuild klappen. Erst dem letzt gab es hier einen, der sich wunderte,warum das Rebuild mit WD Green fehlschlug, mit total erlitt. Deshalb fragte ich. Reds sind nicht toll, aber besser als Green oder Blue.

 

[pepsifreak]

Und was für Platten sollte man dan nehmen?.

 

[conf_t]

Eine Unkorrigierbaren Lesefehler Rate von mindestens 1:10*15(UBER) bieten z.B. alle Ironwolfs ab (einschließlich) 6 TB, die Toshiba MG Enterprise Capacity afaik bei allen Modellen, das wären die vergleichbar teuren. Ansonsten gibt es dann die teuren WD Gold. WD Red pro ist diesbezüglich nicht besser als die non-pro, Und einige weitere, aber dazu muss man die Datenblätter wälzen. Jedenfalls ist mir keine empfehlenswerte HDDmit weniger als 7200rpm bekannt. Die meisten (alle?) mit 5x00 rpm bieten keine geeignete Fehlerrate, um ein Raid5 zubauen mit mehr als 12 TB. Da dann besser RAID. Der Unkehrschluss alle mit 7200 wären geeignet ist natürlich genauso falsch.

 

[Zoker]

Vielen Dank nochmal für eure Hilfe!

Das neuberechnen der Platte hat ca. 8 Stunden gedauert und ist ohne Probleme durchgelaufen