Nach Firmware Update Datenverlust.

Wir haben unsere Datenschutzerklärung zum 22.05.2018 aktualisiert.
  • Versuche meine kleine Welt mit photorec zu retten.

    Photorec hat 1.5 Tage benötigt und mir dabei

    eine externe Festplatte gut gefüllt („Füllhorn“).

    Nun muss ich „Sterntaler“ spielen und schauen was

    es taugt.

  • Kannst du vielleicht mit Testdisk was finden?

    Oder Dateisystem/Bad Sector Scan?

    Hallo Revan, danke der Nachfrage und für die Tipps. Testdisk kenne ich auch, echt super cooles Tool! Glücklicherweise scheinen nur die Verzeichnisse kaputtgegangen zu sein, und zwar auf eine Art und Weise, wo man sie wieder Herstellen kann. Ich hab jetzt 2 Wochen rumrepariert und werde heute Anfangen, die geretteten Daten wieder zurückzuspielen. Dann weiß ich mehr, ob's geklappt hat.

  • Hallo,


    wäre bitte hier Jemand so freundlich die Nutzung der Filesystemprüfung zu beschreiben....

    Von der üblichen Benutzeroberfläche schaffe ich das. Aber nicht mittels Terminal ("SSH").

    Bin mir mittlerweile ziemlich sicher, dass QNAP´s-Frickelzeugs mein ext4 beschädigt hat.

    Freigabeordner (nebst Unterordner und Daten) sind verschwunden. Photorec bringt aber die

    Daten zumindest zurück ("Ochsentour"). Testdisk deutet teilweise die verlorenen Verzeichnisse

    an (in Farbe rot), hat aber wohl keine Reparaturfunktion (nur Kopieren, aber warum ?).

    Extundelete bekomme ich bisher auf dem NAS noch nicht in Funktion ("make fehlt")


    fsck.ext4 ........ ?????? oder e2.fsck.....????



    EDIT: Damit der Neuling hier nicht rumnervt...

    Evtl.muss es so aussehen....


    umount /dev/LAUFWERK --> Erst Platte aushängen

    e2fsck -f /dev/LAUFWERK --> -f, falls Platte clean ist


    Gruß

    4 Mal editiert, zuletzt von Ernie01 ()

  • QNAP hat am ext4 und am e2fsck rumgefummelt. Soweit hab ich die Sourcen schon verglichen. Wenn du das interne e2fsck benutzt, dann unbedingt den Schalter "-n" verwenden, wenn Du nur analysieren willst. Die haben tatsächlich reingepatcht, dass das e2fsck keine Nachfragen an den Benutzer stellt, ob er reparieren mag, sondern es repariert einfach ohne nachzufragen!


    Ich persönlich hab erstmal alle Platten aus dem QNAP rausgerissen und mit nem original Linux gespiegelt und dort gefixed. Ich glaube, ich konnte alles retten. Werden noch ein Verify machen, und mir dann das Ergebnis anschauen.

  • Hi Ernie,


    genau, erst aushängen mittels unmount dev/<dein zu testendes blockdevice> und dann:

    Code
    1. e2fsck -f -y /dev/<dein zu testendes blockdevice>

    Das -y beantwortet automatisch alle Fragen von e2fsck mit yes. Bitte nur nutzen wenn du weist was auf dich zukommt (manpage lesen: man e2fsck auf der shell oder google) oder keine Zeit hast auf alle Fragen händisch zu reagieren.


    Generell wäre es vielleicht ratsam, sofern es die Konfiguration zulässt deine komplette Platte mittels dd auf eine externe Platte >= des aktuellen Fassungsvermögens.


    Gruß & Viel Erfolg,


    Gunna

  • Vielen Dank für eure Unterstützung/Tips.


    Nebenher bleibt die Frage, wie man eine oder beide verschlüsselten Platten des Raid an einen Linux-PC (z.B. Knoppix) bekommt ????

    Hatte meine beiden Festplatten aus dem NAS mit "dd" kopiert.

    Bekomme die jedoch nicht an einen Linux-PC ("Raid 1 DRBD !") und das NAS selber nimmt die Kopie nicht an....

    Das QNAP möchte wegen der Kopie auf Werkseinstellung auf "Dauerschleife"....

    (Start Werkseinstellungen --> Werkseinstellungen erfolgreich --> Start Werkseinstellungen --> .....)

    Angst ......

    D.h. die kopierte NAS-Festplatte MUSS die gleiche Grösse wie das Original haben ?????

    Daher evtl. die Dauerschleife Werkseinstellungen ????

  • Das -y beantwortet automatisch alle Fragen von e2fsck mit yes.

    Das Google-Wissen hilft Dir hier leider überhaupt nix!



    Wie man hier schön sieht wäre nach Google-Wissen ohne "-y" eine Nutzerfrage gekommen. Aber bei QNAP ist das einfach auf "-y" gepatched ("answer=1"). Also immer brav "-n" angeben, wenn man nur testen will. BTW macht das original e2fsck auch ohne "-n" leichte Aufräumarbeiten, AFAIK, z.B. Jorunal aufräumen. Deshalb ist "-n" sowieso immer gut, wenn man erstmal nur analysieren will.

    Bekomme die jedoch nicht an einen Linux-PC ("Raid 1 DRBD !") und das NAS selber nimmt die Kopie nicht an....

    Das schaue ich mir jetzt gleich auch mal an. Ich hatte die RAID-Platten noch nicht dran, sondern die Backup-Platte, denn mit QTS hatte ich mir ja praktischerweise beides zerschossen: RAID + Backup. Jetzt hab ich alle geretteten Daten zurück auf's RAID gebracht (0551) und schaue mir das nun mal mit Linux an. Hoffe, ich schaffe das mit dem mounten.

  • Mit umount (nicht unmount) ist es leider nicht getan ("drive is busy").

    Für das Problem gibt es unzählige Lösungen ("alle Dienste stoppen"), die jedoch meist

    älteren Datums sind und zumindest bei mir nicht funktionieren....


    So wird dank QNAP aus dem NAS als "Mittel zum Zweck" eine echte 100%-Vollbeschäftigung....

    Fürchte nur, QNAP schätzt seine Kundschaft hier ziemlich falsch ein....


    Meine Idee mit dem NAS-Selbstbau (Raid 1 ohne DRBD und Verschlüsselung mit z.B. Vera Crypt, ggf.

    sogar unter Windows, geringer Stromverbrauch) nimmt Fahrt auf. Mehr Zeit als mit dem QNAP

    verbringe ich da auch nicht.

    Vorteil: Bei Problemen kann ich mir selber in den Ar.... treten.

  • Mit umount (nicht unmount) ist es leider nicht getan ("drive is busy").

    Für das Problem gibt es unzählige Lösungen ("alle Dienste stoppen"), die jedoch meist

    älteren Datums sind und zumindest bei mir nicht funktionieren....

    Also bei mir hat neulich noch das hier getan:


    Code
    1. /etc/init.d/services.sh stop
    2. /etc/init.d/opentftp.sh stop
    3. /etc/init.d/Qthttpd.sh stop
    4. sudo umount /dev/mapper/ce_cachedev1
    5. sudo e2fsck_64 -fn /dev/mapper/ce_cachedev1


    Disclaimer: Ohne Gewähr!

    So, jetzt bin ich restvoll bedient! QNAP hat nicht nur am ext4 rumgepatcht und gepfuscht, sogar der Logical Volume Manager ist proprietär! Das heißt ich kann das interne Volume (Thin-Provisioning) nicht mit Linux mounten!


    Code: sudo pvdisplay
    1. WARNING: unrecognized segment type tier-thin-pool
    2. LV tp1, segment 1 invalid: does not support flag ERROR_WHEN_FULL. for tier-thin-pool segment.
    3. Internal error: LV segments corrupted in tp1.

    Danke QNAP. (Weitere Diskussion -->hier)


    Wer übrigens sein RAID1-Laufwerk mounten will und nicht wie ich Trottel Thin-Provisioning genutzt hat, hier ein paar Tipps:


  • Danke Meister Holger,


    Deine Tips bzgl. e2fsck teste ich mal bei mir....


    Bzgl. RAID 1 an Linux kommen mir deine Tips aus meinem „Neuling forscht“ bekannt vor....

    Bei mir lief das RAID 1 dann mit einer der beiden Platten an und beschwerte sich auch gleich

    mit nicht mountbar wegen DRBD......( blieb dann als RAID 1 degraded 1 out of 2).

    Also mdadm war ok, aber die Partition wurde nicht gemounted weil DRBD-Laufwerk...


    Und dann kommt ja noch die Verschlüsselung ins Spiel („LUKS“) oder ....?

  • Ok. Qnap hat in letzter Zeit ganz schön viel Mist gebaut und ich bin wahrlich der letzte der das schön reden will. Aber man sollte die KIrche im Dorf lassen. Schon mal daran gedacht das Qnap sein geistiges Eingentum schützen möchte ? Ich kann auch nirgends einen Verweis finden der besagt das QTS unter der GNU GPL (?) zur freien Verfügung steht.

  • Also mdadm war ok, aber die Partition wurde nicht gemounted weil DRBD-Laufwerk...

    Welche Art der Provisionierung hast Du denn gewählt? Ich hatte Thin-Provisioning, d.h. das ist eine LVM-Partition (bzw. wie ich jetzt weiß eine "Q"VM?). Was helfen kann ist ein "hexdump -C -n 4096 /dev/md<z>", dann sieht man evtl. die Header-Daten und kann ein bissl. g**geln, ob das LVM oder was anderes ist ...

    Schon mal daran gedacht das Qnap sein geistiges Eingentum schützen möchte ? Ich kann auch nirgends einen Verweis finden der besagt das QTS unter der GNU GPL (?) zur freien Verfügung steht.

    Hallo Jagi. Dich verstehe ich jetzt nicht wirklich. Hier sind doch die Sourcen:


    https://sourceforge.net/projects/qosgpl/


    Vorm Kauf hab ich nicht in die Sourcen reingeschaut, sondern auf die Werbeseite. QNAP macht groß Werbung, dass sie ext4 verwenden. Siehe hier. Muss ich erst die Sourcen runterladen und mit den original-Kernel-Sourcen vergleichen um zu erkennen, dass das - sagen wir mal vorsichtig - ein Werbegag ist? QNAP weicht meines Erachtens vom ext4-Standard ab: QTS definiert eigene Features neu, andere um. Ich trau mich z.B. jetzt garnicht mehr, in QTS in einem Ordner, der vielen Dateien enthält, mal zwei Dateien anzulegen, deren Namen sich nur in Groß-/Kleinschreibung unterscheiden. Nachdem ich den Source-Code gesehen habe, würde ich das nur noch unter Laborbedingungen machen.


    Und wenn ich nun sehe, dass sogar in noch tiefer liegenden Schichten (LVM) gepatched wurde, dann verliere ich jegliches Vertrauen in die Stabilität. Denn nur QNAPs sind mit diesen Kernelpatches ausgestatet, d.h. die Testabdeckung ist vergleichsweise gering. Wir reden hier von der Testabdeckung des Datenspeichersystems. Und wir reden von einem NAS, also einem System was primär zum Datenspeichern da ist.


    Wer testet nun diese Kernel-Patches?


    Und der Datenverlust der 0537 gibt mir recht! Ich bin felsenfest der Überzeugung, dass QNAP seine HTrees im Dateisystem durcheinandergezwiebelt hat. Diese "???"-Attribute, die viele hier hatten, zeigen mir das.


    Ich denke: Wir hier, unter anderem wir testen die Patches. Aber hat mich einer gefragt, ob ich das möchte? Nein. Ich will ein robustes Datenspeichersystem. Keine Banane. Nicht hier. Das ist kein Smartphone.


    Welche Kirche meinst Du nun? :-)

  • Hallo,


    von wegen Kirche im Dorf lassen.....


    Was QNAP bei seinem "Frickelzeugs" völlig vergessen hat ist das hier Kundenvertrauen grob

    fahrlässig verspielt worden ist.........

    Ich habe keinerlei vertrauen mehr in QNAP und werde diese Produkte auch nicht empfehlen.


    P.S. Vom QNAP-Support habe ich bis heute - außer einer Vertröstung - keine Rückmeldung erhalten.

    ("Störfaktor Kunde, diese ewigen Plagegeister")


    Versuche noch einige Zeit weiter meine Daten bestmöglich zu retten. Dann bin ich raus....

  • Hallo Jagi. Dich verstehe ich jetzt nicht wirklich. Hier sind doch die Sourcen:

    Ups. Das wusste nicht. Hab bis jetzt nirgends einen Verweiss gefunden. Vielleicht habe ich die auch nur übersehen.


    Edit: Das die Abfrage rausgenommen worden ist ob repariert werden soll kann ich nachvollziehen. Zu den anderen Sachen die du erwähnt hast und was das für Konsequenzen nach sich zieht, kann ich mangels Wissen nix zu sagen. Man müsste vielleicht in Erfahrung bringen warum sie solche Änderungen gemacht haben.

    Einmal editiert, zuletzt von Jagi ()

  • Was QNAP bei seinem "Frickelzeugs" völlig vergessen hat ist das hier Kundenvertrauen grob

    fahrlässig verspielt worden ist.........


    Hallo,


    sehe ich genauso, plane auch schon meinen Abschied von Qnap. Siehe auch mein anderes Posting zu dem Thema:


    Backup auf externe Datenträger mit 4.3.4 weiterhin nicht möglich

  • Was QNAP bei seinem "Frickelzeugs" völlig vergessen hat ist das hier Kundenvertrauen grob

    fahrlässig verspielt worden ist.........


    Da bin ich ganz deiner Meinung. Ich bin zur Zeit auf der Suche nach einem Backup NAS und so viel kann ich schon sagen, es wird nicht aus dem Hause Qnap sein.

  • Jeep, so mache ich das auch gerade....(Produktwechsel bzw. Selbstbau)

    Das Vertrauen ist hin.....

    Was sollte ich da mit einem „Oh sorry...“-Schreiben von QNAP.....

  • Dito... bin ebenfalls dabei mir das Synology Lineup anzusehen.


    Ich fand die Entfernung des Twonky Servers damals schon grenzwertig aber mit dieser Aktion ist Qnap einen Schritt zu weit gegangen. Der Fehler an sich war schon übel aber die Kommunikation, Aufarbeitung und Fehlerbereinigung schießen den Vogel einfach ab. In meinen Augen (und scheinbar auch vieler anderer, wenn man sich die Rankings nach NAS Beliebtheit auf Idealo oder Geizhals ansieht) kann man Qnap als NAS Hersteller einfach nicht mehr ernst nehmen.


    Angefangen hat es mit der "Internet of Bockmist" Hysterie bei der auf einem einstmals verlässlichen NAS dutzende Multimedia Features hinzu geflanscht und dabei die Grundpfeiler (verlässlicher Datenspeicher, Backup, Restore) komplett aus den Augen verloren wurden.


    Ebenfalls ziemlich übel ist, in welchen Maße Qnap propretiäre Anpassungen im Filesystem und Volume Manager (siehe Sumpfdotters Hinweise weiter oben) macht ohne die man später keine Chance mehr hat direkt über die Festplatte an seine Daten zu kommen.


    Bisher hatte ich immer ein schlechtes Gewissen, weil ich keine Verschlüsselung auf meinem Qnap sowie der externen Backupplatte aktiviert hatte. Heute kann ich wohl sagen, dass genau das meine Rettung war.

    Einmal editiert, zuletzt von Thesta ()