TS-653A ISCSI Datenverlust nach Neustart

    Hallo Liebe Gemeinde,


    da ich nun zum zweiten mal einen schweren Datenverlust, nach einem Firmwareupdate meines TS653A, erleide würde mich interessieren ob jemand einen Tipp für mich dazu hat.
    Ich betreibe das NAS als reine ISCSI Storage (RAID5 5x6TB und 1x8TB mit jeweils einem LUN), angebunden sind beide an einem Windows Server 2012 R2 Standard.


    Der Fehler sieht wie folgt aus, nach dem Firmwareupdate des NAS wird ein Neustart ausgeführt, nach diesem waren quer durch die Bank (ca. 12TB Daten) vorallem große Files (1GB+) nicht mehr lesbar.
    Ich kann mir überhaupt nicht erklären woran es liegt, ein Cache Problem kann es kaum sein da es zum Teil auch sehr alte Dateien betrifft die in jedem Fall schon niedergeschrieben sein müssen, gibt es evt. etwas was man vor einem Reboot beachten sollte?


    Vorab schon mal vielen lieben Dank für jeden Hinweis!

    Fährst den Server vorher sauber runter und/oder nimmst das Volume sauber offline?
    Was sagt ein chkdsk? Schreibcache am NAS aktiviert?

    Ich habe die Laufwerke zwar im Datenträgermanager nicht offline genommen aber den Server vorher heruntergefahren.
    chkdsk /F repariert einiges am Index, die Daten sind dan zwar zum teil wieder Sichtbar aber unvollständig und ein /R /F habe ich noch nie durchlaufen lassen da hier ein Recovery vom Backup wesentlich effizienter ist > ETA 150 Stunden ... bzgl. dem Cache bin ich mir nicht mehr ganz sicher ob ich die Option überhaupt hatte (ohne zusätzliche Cache SSD, diese habe ich nämlich nicht im einsatz), aber wenn es diese auch ohne SSD gibt ist dieser sicher aktiviert :D

    Meinte den Schreibcache der Festplatten, aber Server vorher sauber runterfahren sollte reichen.
    Steht was im Log (Windows und NAS)? RAM mal getestet? Mal einen chdsk nach ein paar Tagen Laufzeit ohne Neustart des NAS durchführen. Es greift nur ein Server auf eine LUN zu, oder?

    Weder das Log vom Server noch das vom NAS zeigt Auffälligkeiten :(
    Meinst du den RAM vom NAS? Wo gibt es da eine check funktion oder muss ich das via SSH machen? Das mit dem versetzten chkdsk werde ich probieren, ich denke du willst ausschließen das der Fehler im regulären lfd. Betrieb entsteht?
    Auf die beiden LUNs greift nur ein bzw. der selbe Server zu.

    Keine Einträge im Log ist immer blöd. Mit dem QNAP Diagnostic Tool (APP-Center) kannst was prüfen oder richtg mittels Memtest (USB Stick, Maus+Monitor+Tastatur dran).
    Korrekt es könnte ja sein, dass die Fehler vom Server, der NIC (Treiber?) kommen. Parallel würde ich ein Ticket aufmachen. Welche Firmwareversion ist im Einsatz?

    Firmware vom NAS ist 4.2.2 und ein Ticket habe ich parallel schon eröffnet.
    Der QNAP Diagnostic Mem Test hat keine Fehler gebracht bzw. sieht das Diagnostic Tool über dessen ganze Palette gut aus ...


    Ich werde nun mal zusätzlich in 2-3 Tagen wieder chkdsk laufen lassen, irgendwo muss der Fehler doch begraben sein.

    Auf das Ticket habe ich noch immer keine Antwort bekommen, nachdem ich mein Konzept die Tage nocheinmal umgeworfen habe glaube ich das Problem nun wie folgt gelöst zu haben (erste Tests mit einem reboot bzw. dem aktuellen Firmware Upgrade waren erfolgreich)


    Schlüsselpunkte Aufbau alt:

    • RAID5 5x 6TB als Volume konfiguriert
    • Einzeldatenträger 8TB als Volume konfiguriert
    • darauf haben sich jeweil 2 ISCSI Ziele mit je einem (Thin) LUN befunden
    • 4kB Sektoren
    • CRC Head/Daten OFF
    • Flüchtigen Schreibcache melden & FUA-Bit OFF


    Schlüsselpunkte Aufbau neu:

    • RAID5 5x 6TB als Speicherpool
    • Einzeldatenträger 8TB als Speicherpool
    • 2 ISCSI Ziele mit je einem (Thick) LUN
    • 4KB Sektoren
    • CRC Head/Daten OFF
    • Flüchtigen Schreibcache melden & FUA-Bit ON


    Der einzige Wermutstropfen ist das sich die Speicherpools ordentlich Kapazität (in Summe 400GB) für was auch immer reservieren ...


    Ich werde nun die nächsten Tage noch ein paar Tests machen aber bisher sieht es sehr gut aus :)