[TS-859 Pro+] Platine defekt / RAID 5 mit vier Platten [Worst Case!]

    Hallo Forum,


    mein QNAP TS-859 Pro+ arbeitet wie er soll, dass vorweg geschickt!


    Jedoch belastet mich seid kurzem der Gedanke, was mit meinen Daten geschehen wird, wenn nicht die Festplatten Ihren Geist aufgaben, sondern mehr das Gehirn ... als die Hardware des QNAP´s selber ?
    Hat da jemand schon einmal Erfahrung mit machen müssen ? Was würde mit den vier Festplatten im RAID5 Verbund geschehen müssen, falls mir so etwas passieren sollte ?


    Der QNAP wird mit einer ausreichend ausgelegten USV "gesichert". Die wichtigsten Daten des QNAP werden nochmals auf einen anderen Backupserver gesichert/gespiegelt.
    Will damit nur sagen, dass ich die als Privatperson so einigermaßen gut aufgestellt bin was Datensicherheit und Datensicherung betrifft. Mich es aber einfach interessiert, was z.B. bei einem QNAP Platinendefekt gemacht werden könnte/müsste.


    Vielen Dank bereits jetzt für weitere Informationen
    Grüße Marco

    Hi Marco,


    trifft sich gut :cursing: , ich spiele grade den Worstcase mit meinem SS-839. Leider nicht als Übung sondern scharf.


    Vorneweg, wenn "nur" das Gerät selbst einen Abgang macht hast du recht gute Karten. QNAP verwendet den mdadm von Linux, du kannst das Raid also prinzipiell auf jedem Linux Kasten mounten, der genügend Plattenanschlüsse hat.


    Ich habe (hatte) 7 Platten drin 1-5+7 als RAID 5 Verbund, die 6 als Hotspare, hat sich beim letzten Plattenersatz so ergeben. Ein Datenbackup habe ich mir normalerweise (ja ich habs 6 Monate verbummelt) auf eine externe Platte gezogen. Vor 2 Tagen dann der effektive Worstcase Nr 5 geht über der Jordan die 6 wird automatisch ins Raid aufgenommen, der Rebuild crasht weil die 1 auch kaputte Sektoren hat. Kiste tot, Daten futsch, zumindest erstmal. NAS startet nicht mehr.


    Soviel vorgeplänkel.


    Nun zu den Problemen die sich ergeben.


    1. Systembackup
    Auch wenn du noch so regelmäßig ein Datenbackup machst, die Systemkonfiguation ist nicht dabei, die muss man extra machen.
    Das Backup kommt als .bin, ich würde(werde) es ab sofort vor und nach jedem FW Update machen. Da steht alles drin was wichtig ist.
    Daten ohne System nützen nur wenig, zumindest kostet es Unmengen an Zeit das alles wieder zu rekonstruieren.
    2. iSCSI Devices
    Wird die wenigsten betreffen, auch die sind nicht im Daten Backup drin :-/ . Extra Job im Konfigurationsdialog der iSCSI Devices.
    3. Zusaätzliche Apps
    Da bin ich mir noch nicht so sicher, weil meine Daten noch von ddrescue bearbeitet werden. Ich gehe aber davon aus, dass die Konfiguration der zusätzlich installierten Apps ebenfalls getrennt gesichert werden muss. Wie dürfte von der App abhängen.


    Was noch:
    Warum ist das eigentlich passiert ? 2 Platten zeitgleich, wo ich doch noch extra dafür gesorgt habe, dass die nicht aus der gleichen Charge kommen.
    Schuld ist QNAP, beide Platten schreien seit einem halben und einem ganzen Jahr täglich nach Hilfe:

    Code
    6084,"Information","2015-10-26","18:58:37","System","127.0.0.1","localhost","Host: Drive5 read error corrected."
6083,"Information","2015-10-26","18:58:20","System","127.0.0.1","localhost","Host: Drive5 read error corrected."
6082,"Information","2015-10-26","16:10:08","System","127.0.0.1","localhost","Host: Drive1 read error corrected."
6081,"Information","2015-10-26","16:10:08","System","127.0.0.1","localhost","Host: Drive1 read error corrected."
6080,"Information","2015-10-26","14:35:41","System","127.0.0.1","localhost","Host: Drive5 read error corrected."


    Ich weiß nicht welcher Vollpfosten auf die Idee gekommen ist dieser Meldung den Status "Notice" zu verpassen.
    Fehler bekomme ich sofort als Mail, Warnungen prüfe ich regelmäßig. Nur in die sch.... Infos habe ich halt nie reingeschaut.


    Fazit:
    Wenn du die Backup Punkte die ich oben aufgeführt habe durchführst, auch die Infos aus dem Log regelmäßig liest solltest du safe sein.
    Macht das QNAP einen Abgang besorgst du dir entweder ein neues, steckst die Platten rein und bootest wieder, oder du hängst deine Platten an einen z.B. Ubuntu Rechner und liest dich in die Thematik raid mit mdadm ein.
    Schau dir deine Platten im SMART regelmäßig an und lerne was welche Meldungen bedeuten.Tausch die Platten bevor sie kaputt gehen !


    Gruss
    Stefan


    PS: Ich wünsche Dir, dass du diese Erfahrung nie machen musst. Mein SS-839 rennt übrigens sein 10/2009 im Dauerbetrieb.
    Ich habe meine NAS früher selbst gebaut, von dem her bin ich recht guter Dinge, dass ich an einen Großteil der Daten wieder dran kommen müsste.

    Huhu, zum Thema Apps sichern bin ich grad im fröhlichen Selbstversuch :D


    Hab seit kurzem ein TS-251 und werde als 2. Cloud Punkt noch eines kaufen. Dafür habe ich jetzt einfach mal die md9, md13 und m256 devices mit dd abgezogen und schau mal, ob ich die nicht nach intialisierung im neuen Device, im Notbackup-Modus wieder drauf gespielt bekomme :D Wenn ja, werde ich hier gerne berichten. Dann habe ich vielleicht ein Script fertig, das sämtliche QTS Files sichert...


    A propos, könnte mal jemand mit nem größeren NAS als 2 Platten den Output von


    Code
    cat /proc/mdstat


    hier posten, ich muss noch eine Vermutung bestätigen :D

    Für alle die mal über diesen Beitrag stolpern:


    Das Notfallrecovery von QNAP hat funktioniert, obwohl die Ausgangslage katastrophal war. Eine Platte geht kaputt, die Hotspare wird hinzugefügt, beim Rebuildversuch hängt sich die ganze Kiste weil eine zweite Platte lesefehler hat, die erst beim Rebuild bemerkt werden. Dümmer gehts nimmer..


    Ich habe die beiden beanstandeten 500GB Platten mit ddrescue umkopiert, hatte insgesamt etwa 20MB "verlust".
    Nach dem die erste fertig war habe ich das Nas auf den brauchbaren 6 Platten gestartet und ein Systembackup gemacht. Das RAID konnte in dem Zustand nicht gemountet werden. NAS aus und auf die letzte Platte gewartet.
    Nach Anleitung vom QNAP Support den Emergency Recovery Modus aktiviert:


    Nach dem Prozedere habe ich 20 Minuten gezittert :shock:
    Mein NAS ist wieder da, der abgebrochene Rebuild läuft. Die meisten Einstellungen sind erhalten geblieben, meine iSCSI Devices sind up and running.


    DANKE QNAP !
    Wenn jetzt die Info noch zum Fehler umdeklariert wird, ist alles schick.


    MarcoK
    Nach dem was ich heute erlebt habe, dürfte mit dem oben genannten Verfahren, ein HW Defekt unproblematisch sein. Neue QNAP Kiste mit mind. gleichviel Slots. Starten, warten, Platten rein, Auf Werkseinstellungen und alles wird gut...


    @ Mangoon2008

    genau das ist der Grund, warum ich RAID6 einem RAID5+Hotspare vorziehe:


    Fällt bei RAID5 eine Platte aus, wird ein Rebuild auf die Hotspare angestoßen. Währenddessen ist die Belastung auf den anderen Platten besonders hoch, denn es muss ja jeder einzelne Block gelesen werden.
    Wenn eine zweite Platte ausfällt, dann vermutich genau jetzt - und das kann ein RAID5 Verband nicht korrigieren.


    Bei RAID6 wird eine doppelte Parity verwand, d.h. nach dem Ausfall einer Platte ist das System immer noch äquivalent einem RAID5, ich kann in Ruhe eine neue Platte kaufen und zu einem geeigneten Zeitpunkt einbauen. Der RAID Rebuild ist jetzt auch nicht weniger aufwendig als beim Rebuild auf eine Hotspare, allerdings habe ich hier jetzt ja einen vollständigen RAID5 Verband und stelle nur die zweite Parity Platte wieder her. Sollte jetzt eine der alten Platten ausfallen, dann habe ich eben ein degraded RAID5 im Rebuild und bin immer noch so sicher wie beim Ausfall der ersten Platte im RAID5+Hotspare Fall.


    Belt & Braces, wie der Brite sagt.


    der Nachteil von RAID6 ist natürlich, dass ich keine globale Hotspare konfigurieren kann.


    pj

    Verständnisfrage: Einfach die Platten aus dem RAID an eine "beliebige" Linuxkiste mit mdadm (Software-RAID) hängen dürfte seit dem Konstrukt der "Volumes" (= QNAP-eigenes Format) bei einer ganzen Reihe von QNAP-Modellen nicht mehr gehen, nicht mal mehr mit einem RAID1, wo man früher mit jedem beliebigen ext3/4-ertüchtigten Rechner (Linux, Windows + Treiber, egal) notfalls quick & dirty an die Daten einer einzelnen Platte herankam....
    lG Matthias

    mein TS412 legt sein Dateisystem direkt auf dem md-Device an (also /dev/md0 z.B.). Deshalb kann ich über einen volume Manager nichts sagen. Es wäre aber unnötig proprietär und auch irgendwie dumm, hierfür nicht lvm zu verwenden.


    pj