Datenverlust auf iSCSi LUN nach Shutdown/Reboot

  • Bereits im Thread der 5.0.1.2277 Firmware erwähnt, mache ich hierzu einen eigenen Thread.


    Auf meinem TS-473A habe ich seit Beginn an iSCSI LUNs zu Windows und Linux, die ich aber eher selten benutze.

    Nach einem FW Update teste ich i.d.R. immer den Zugriff, aber meist nur lesend auf die vorhandenen Daten.

    Diese Woche habe ich aber eine unschöne Erfahrung gemacht, ich habe die LUN als Speicherplatz für eine VMware VM benutzt, die ich für andere Tests benötige.

    Das NAS fährt seit einigen Monaten abends herunter und bootet am nächsten morgen. So stellte ich heute fest das meine VM verschwunden war!? :X


    Deshalb habe ich einige Tests durchgeführt und festgestellt, dass das Verhalten bei mi jederzeit reproduzierbar ist. :cursing: Daten auf die iSCSi LUN kopiert -> NAS booten -> Daten weg!!!

    Allerdings nur auf der Windows 10 LUN, die Ubunt LUN behält die Daten.

    Gleichzeitig aber habe ich von einem anderes NAS, das ebenfalls nicht 24/7 läuft, eine iSCSI LUN zum selben Windows 10 Rechner gemappt, hier bleiben die Daten auch erhalten.


    Hier ein Screenshot, der links den (gecachten) Verzeichnisinhalt der LUN vor dem Reboot und rechts nach dem Reboot zeigt:


    TS473_iSCSI_01.png


    Das Verzeichnis VMware samt Unterverzeichnissen ist nicht mehr vorhanden.

    Das waren einige GB, dumm, wenn so etwas auf einem Produktivsystem passiert.


    Als Krönung ist dann noch die Wiederherstellung aus einem Snapshot nicht erfolgreich. Ich hatte extra Minuten vor dem Reboot einen Snapshot erstellt. Die Wiederherstellung wird zwar "erfolgreich" beendet, aber die Daten bleiben verschwunden.

    Ein Ticket ist eröffnet, ich bin gespannt auf die Antwort. :?:


    Gruss

  • Nachdem immer wieder (auch von mir) auf den QNAP Support geschimpft wird, jetzt eine gegenteilige Erfahrung:


    Aufgrund des o.a. Fehlers erbat der QNAP Support remote Zugriff auf mein System, dieser wurde auf meine Bitte per Teamviewer heute durchgeführt.

    Die Session dauert fast 2h, die meisten Zugriffe auf das NAS erfolgten per Putty.

    Ein durchweg professioneller und netter Kontakt.

    So wie es aussieht, war die Ursache wie vermutet ein Firmware Bug. In einem der Kernel-Logs gab es entsprechende Warnmeldungen.

    In welcher Firmware genau, liess sich auf leider nicht mehr feststellen.

    Da ich den Schreibzugriff nicht regelmäßig getestet habe (was ich in Zukunft machen werde ;) ), konnte das nicht näher eingegrenzt werden.

    Aktuell sind nun nach dem letzten Reboot jedoch keine Daten mehr verschwunden.


    Was auf alle Fälle hilfreich ist:

    Putty und GUI Sessions zu den beteiligten Geräten schon offen zu haben,

    Eine vorbereitete, kurze Skizze über die betroffene Umgebung. Die muss nicht High-end sein, eine Bleistiftzeichnung oder ein simples Bildchen reichen, helfen aber dem Support ungemein den Aufbau zu verstehen.


    Die Putty Session wurde im Laufe der remote Session übrigens auf Wunsch auf den "echten" admin umgeschaltet, dem alternativen admin fehlten mal wieder Rechte. :rolleyes:


    Fazit: alles in allem eine Top Leistung!


    Gruss

  • Danke für die tolle Rückmeldung.


    Das aber auch 23 noch der echte admin unersetzlich ist, schon irre das dann empfohlen wird den zu deaktivieren.

  • Im normalen Alltag braucht man den auch nicht mehr, auch nicht auf der Konsole. Habe den schon seit Beginn QTS 5.0.0 auf allen NAS deaktiviert. Bis jetzt ging alles damit. Musste allerdings bis jetzt auch nicht gröberes wieder gerade biegen. Außer ... die Testumgebung mal komplett neu machen und dies ging über "Zurück auf Anfang", auch ohne "admin". :)


    FSC830

    In diesem Fall ein Fehler in den Konfig-Files durch einen Bug in einer älteren Firmware verursacht? Habe ich dies so richtig verstanden. Ärgerlich.

  • Das ist leider ungeklärt. :( Ich hatte nach den FW Updates immer nur gesehen, das die iSCSI LUN wieder connected war und auf die vorhanden Daten lesend zugegriffen. Damit war es für mich ok. Auf eine Idee, schreibend zuzugreifen, bin ich nicht gekommen. Und es wäre evtl. auch nicht sofort aufgefallen.

    Ganz dumm wäre es gewesen, wenn das NAS 24/7 laufen würde und irgendwann nach Tagen (Wochen) rebootet wird, dann wären alle neu hinzugekommenden Daten weg gewesen :X .


    So ist es mir zumindest am nächsten Tag aufgefallen.

    Ich müsste mir die Logs noch einmal genauer anschauen, bei manchen Sachen konnte ich nicht so schnell mitlesen, wie die Ausgabe erfolgte.

    Im Chat haben wir uns aber nochmals darüber ausgetauscht und es war eine Sache mit configfs im memory, so wurde es bezeichnet.

    Er hat einiges mit qcli_ Befehlen ausgeführt, mit dmesg dann nachgesehen, den iSCSI Dienst mehrfach gestoppt und wieder gestartet.

    Es war aber sehr schnell klar, dass etwas nicht stimmte, den ich hatte die iSCSI LUN auch als "remote Disk" in der Filestation.

    Per Host in die LUN geschriebene Dateien waren in der Filestation nicht sichtbar. Die RD ausgehängt, eingehängt, keine Änderung.

    Irgendwann fragte er, ob er sie löschen darf (die remote Disk, nicht die LUN), durfte er natürllich ^^ .

    Es hat dann aber dennoch eine Weile gedauert, bis alles im reinen war.


    Wenn man natürlich jetzt noch hätte sehen können, ab welcher Firmware... hätte hätte Fahrradkette... :S


    Gruss

  • Man male sich die Situation mal bei einem richtig produktiven NAS aus. Dabei wird doch immer empfohlen, die virtuelle Maschine als LUN am Storage anzuhängen. OK, in diesem Fall vielleicht besser kein QNAP NAS. Ich finde solche Fehler doch schon richtig heftig. Ich glaube, bei Dir war es ja kein produktives LUN und so ist es Dir ja lange nicht aufgefallen. Auch wenn man bei produktiven Daten regelmässige Backups fährt, ein ganzer Tag der ganzen Firma ist trotzdem schnell mal verloren, denn meistens fährt man ja da das Backup über die Nacht.


    Es kommt leider immer wieder mal vor, dass nach einem Update ein Fehler unbemerkt herein schleicht. Deshalb ist es wichtig, alle wichtigen Funktionen durch zu testen.


    Déjà vu. Sitze noch am Rechner und teste die TS-873A durch. Gerade das Update von 5.0.0 auf 5.0.1 gemacht. Ist das erste produktive NAS, welches ich jetzt mit QTS 5.0.1 betreibe. Hoffentlich keine Fehler wie bei Dir drinnen. Gut, da sind keine LUNs drauf. Also alles safe. :)

  • Solche positive Erfahrung mit dem Fernzugriff hatte ich auch schon gemacht und kann es im Allgemeinen bestätigen. Hatte das schon sowohl per QNAP-Helpdesk - das aber in neuerer Zeit nicht mehr oder wirklich nur dann, wenn die Zugriffzeit eng eingegrenzt werden kann.


    Erfolge waren wechselweise. würde mal sagen 50/50. Mal war ich auch überrascht, wie sicher und zielstrebig ein Problem gelöst wurde, das Mal davor beim gleichen Problem wurde die Aktion nach einigen Stunden ohne Erfolg abgebrochen. Hängt natürlich eindeutig auch wieder etwas zusammen, welchen Supportmitarbeiter man erwischt.


    Es gilt halt auch hier wieder: Dass die Welt allgemein nun mal gemein ist und immer damit gerechnet werde muss, dass böse Menschen Sicherheitslücken ausnutzen, und man deshalb solche Zugriffe immer nur mit flauem Gefühl im Magen zulässt, hat ja nicht QNAP zu verantworten.

  • FSC830

    Du hast da was von Chat oder so geschrieben, vermutlich über Teamviewer. War der Support in deutsch oder englisch?

  • Das war alles in English. Der Support kam wohl auch aus Taiwan, so hatte es zumindest der deutsche Support Kollege mitgeteilt. Auch der Termin war nach fernöstlicher Zeitplanung. Es wurde ein Terminfenster zwischen 06:00 und 10:00 genannt, das wurde dann nochmals auf zwischen 07:00 und 09:00 eingegrenzt.

    Um ziemlich genau 08:57 wurde dann die Session gestartet, bis ca. 10:36 dauerte sie.

    Leider kann man im TV als "ferngesteuerter" die Aufzeichnung nicht starten, jedenfall habe ich diese Option nur gefunden, wenn ich der "fernsteuernde" bin.

    Da Putty bei mir aber per default ein Log schreibt, habe ich zumindest diese Befehle.


    Gruss

  • Das war alles in English.

    Das habe ich mir fast gedacht.

    Der Support kam wohl auch aus Taiwan,

    Oh, vermutlich die Entwicklungsabteilung. Da hast Du wohl etwas Staub aufgewirbelt. :)

    Leider kann man im TV als "ferngesteuerter" die Aufzeichnung nicht starten,

    Mit einem "normalen" Bildschirmaufzeichnungsprogramm wurde dies sicher auch gehen. In diesem Fall bist Du kein PC-Gamer, der alle sein Spiel-Sessions gleich bei YouTube hochlädt. ;)