Nach Update bei Freenas 9.10 fehlt ein Dataset und alle Daten

[4styler]

Hallo liebe Forengemeinde,

ich würde dringends euere Hilfe benötigen. Mir ist bei einem Update (Update und Neustart waren eigentlich druch) innerhalb von V9.10 mein System-Volume gestorben. Der Server hat sich aufgehängt und ich musste
ihn resetten.

Nun habe ich meinen Pool wieder importiert und stelle fest das er Leer ist. Hier waren alle wichtigen
Daten enthalten. Der unwichtige Pool ist witzigerweise noch vorhanden.....

Die ausgaben von zpool status zeigen folgendes:
[root@freenas] /# zpool status TB3x4
pool: TB3x4
state: ONLINE
scan: scrub repaired 0 in 3h25m with 0 errors on Sun May 29 03:26:18 2016
config:

NAME STATE READ WRITE CKSUM
TB3x4 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
gptid/26058608-d885-11e3-8dbf-002511a48a47 ONLINE 0 0 0
gptid/26f62d11-d885-11e3-8dbf-002511a48a47 ONLINE 0 0 0
gptid/27e28743-d885-11e3-8dbf-002511a48a47 ONLINE 0 0 0
gptid/28cfe43f-d885-11e3-8dbf-002511a48a47 ONLINE 0 0 0

errors: No known data errors

also eigentlich unauffällig.

Ein zfs list zeigt folgendes:
[root@freenas] /# zfs list -r TB3x4
NAME USED AVAIL REFER MOUNTPOINT
TB3x4 2.87T 4.78T 2.65M /TB3x4
TB3x4/.system 1.32M 4.78T 151K legacy
TB3x4/.system/configs-c4a93aaf1c9442ea828ddc7efa630359 140K 4.78T 140K legacy
TB3x4/.system/cores 140K 4.78T 140K legacy
TB3x4/.system/rrd-c4a93aaf1c9442ea828ddc7efa630359 140K 4.78T 140K legacy
TB3x4/.system/samba4 453K 4.78T 453K legacy
TB3x4/.system/syslog-c4a93aaf1c9442ea828ddc7efa630359 331K 4.78T 331K legacy
TB3x4/jails 140K 4.78T 140K /TB3x4/jails

also er weiß das die 2TB belegt sind. Diesen wären in /TB3x4/gemeinsam belegt, welches sich aber in wohlgefallen aufgelöst hat. Jetzt kommt meine Frage:

Welche möglichkeiten habe ich und was benötigt Ihr noch? Ich habe immer Regelmäßige snaphots gemacht
diese scheinen noch vorhanden zu sein.

Der Pool wurde mit Version 9.3 erstellt und einmal (ich glaub auf V28) upgegradet. Soll ich vieleicht V9.3
einmal Probieren?

Ich hoffe sehr das mir geholfen wird.
Viele Grüße
Stefan

 

[MrToddsFriends]

Der Pool wurde mit Version 9.3 erstellt und einmal (ich glaub auf V28) upgegradet. Soll ich vieleicht V9.3
einmal Probieren?

FreeNAS 9.3 hatte (genauso wie 9.10) bereits ZFS v5000. Laut älterer Doku (Seite 50) gab's ZFS v28 bei FreeNAS 8.3.x
http://doc.freenas.org/9.2.1/freenas9.2.1_guide.pdf

Wenn Dein Pool nicht entsprechend alt ist, kommt eine ZFS Versionsproblematik als Grund nicht in Frage.

 

[4styler]

Hey, danke für die Antwort.
Ich habs eben mit nem Downgrade auf 9.3 versucht. Hier zeigt sich der selbe Fehler.
Kann ein Scrub helfen? Oder würde mir der die nicht angezeigten Daten löschen?

Kann ich die Snaphots für etwas gebrauchen? Bzw. kann man soetwas mounten das man
reinsehen kann ob da alles wieder da wäre?

Angeblich sind die 2 TB in Snapshots:

Viele Grüße
Stefan

 

[4styler]

Hey,

der Snapshot hat mich gerettet.... Hatte noch einen von gestern und hab den wiederhergestellt. 2 Minuten später war alles wieder da :).

Danke euch.

 

[MrToddsFriends]

der Snapshot hat mich gerettet.... Hatte noch einen von gestern und hab den wiederhergestellt. 2 Minuten später war alles wieder da :).

Prima. Ich nehme an dies ist per Rollback gelungen. Ich wäre vermutlich an Deiner Stelle sehr vorsichtig gewesen und hätte zunächst versucht einen Clone des letzten Snapshots zu erstellen, wohl mit einem extra Pool auf mindestens einer zusätzlichen Platte.

Ein wenig schleierhaft ist mir der dank Snapshot doch nicht eingetretene Datenverlust beim Update mit Hänger aber doch. Würde es Dir etwas ausmachen, Deine Hardware zu nennen (Mainboard, CPU, RAM)?

 

[4styler]

Hi,
jop über Rollback der Freenas Web Oberfläche. Ich hab auch lange überlegt ob ich das machen soll. Bei nem Clone hätte ich nicht gewusst wohin.... hab nämlich nichts da.
Jetzt ziehe ich erst mal alle Daten die ich brauche als Backup und muss mir da noch was überlegen.

Mainboard ist das ASRock C2550 mit nem Avoton als Prozessor. RAM ist ein Kingston ECC ich muss jetzt aber passen welcher genau.

Ich habe folgende vermutung: Ich hab das Update wie gewohnt über die Weboberfläche gemacht. Das System hat neugestartet und lief wieder. Ich hab dann meinen 2. Pool entschlüsselt. Kurz danach
waren die CIFS freigaben nicht mehr erreichbar. Die Weboberfläche hat beim benutzen komische Fehler angezeigt. Also habe ich mich auf die Management Console aufgeschalten.
Hier stand ein Fehler mit Irgendwas: Gerät ?/tt? reagiert zu schnell. 30 Sekunden warten. Ich konnte das System nicht herunterfahren und musste einen Reset machen.
Danach kam der Grub nicht mehr hoch. Ich habe dann versucht über die cmd den Grub wieder herzustellen. Allerdings waren überhaupt keine Daten mehr vorhanden.

Ich habe dann eine neuinstallation mit V9.10 gemacht und bin dem Initial Wizard gefolgt. Danach habe ich festgestellt das die Daten des einen Pools komplett weg waren (Das waren der Pool der
direkt mit CIFS verbunden war und ncht erst entschlüsselt werden musste). Die Daten des anderen Pools der verschlüsselten Platten waren komplett da.

Es schaut so aus das nur die Daten im Pool gelöscht wurden die im CIFS Dienst eingebunden waren. Alles andere hat gepasst.... Deswegen bin ich davon ausgegangen das es ein Normaler
löschvorgang war und hab den Snapshot nach langem überlegen wieder Hergestellt.

Ich habe im Internet gesehen das ich bei V9.10 wohl nicht der erste Fall mit genau diesem Problem war...

Nun ja ich mach jetzt ein Backup und werde dann Version 9.3 komplett durchupdaten und nicht mehr auf V9.10 gehen. Irgendwann mach ich dann eine Neuinstallation auf eine neue Version.

Konnte dir das Helfen?

Viele Grüße
Stefan

 

[MrToddsFriends]

Danke für die ausführliche Beschreibung. Ich werde mich am Wochenende doch nochmal ein wenig mit 9.10er Fallstricken befassen, auch wenn der Umstieg 9.3.1 -> 9.10 bei mir problemlos geklappt hat.

 

[4styler]

Vielleicht sei noch erwähnt das ich ein Update innerhalb von 9.10 gemacht habe. Das Update von 9.3 auf 9.10 ging Problemlos.

 

[4styler]

Hallo Nochmal :)
eine Frage hab ich noch. Mir wird das Dataset "gemeinsam" nicht mehr angezeigt. Es gibt aber wieder im Pool TB3x4 den Ordner gemeinsam. Jetzt meine Frage:
Da das früher ein Dataset war, was passiert wenn ich da nen Scrub drüber laufen lasse? Bzw. ich verstehe einfach nicht so genau was ein Scrub eigentlich macht.
Ist das so wie chkdsk? Ich würde nächsten Monat eine Platte kaufen und mal ein Voll Backup machen. Sollte ich vorsichtshalber alles einmal platt machen und
die Daten neu draufziehen? Bzw. wie ist das allgemeine richtige vorgehen?

Danke schon mal
Viele Grüße
Stefan

 

[MrToddsFriends]

Mir wird das Dataset "gemeinsam" nicht mehr angezeigt. Es gibt aber wieder im Pool TB3x4 den Ordner gemeinsam.

Zum besseren Verständnis: Liefert einerseits zfs list | grep gemeinsam keinen Output, "gemeinsam" kommt also weder in der NAME noch in der MOUNTPOINT Spalte des Outputs von zfs list vor?
Und andererseits zeigt Dir ein Kommando wie ls -al /mnt/TB3x4/ einen Ordner bzw. ein Dataset "gemeinsam"?

Oder wolltest Du damit sagen, dass Dir "gemeinsam" in der FreeNAS GUI unter Storage -> Volumes -> View Volumes nicht angezeigt wird?

Bzw. ich verstehe einfach nicht so genau was ein Scrub eigentlich macht. Ist das so wie chkdsk?

Besser, ein Scrub repariert falls notwendig bei vorhandener Redundanz (Mirror, RaidZ) Metadaten, also Verwaltungsinformationen des Dateisystems, sowie Nutzerdaten. Insbesondere Letzteres beherrscht ein chkdsk oder fsck auf einfacher gestrickten Dateisystemen nicht.

Bin mir aber nicht sicher, ob Dir ein Scrub in der gegenwärtigen Situation helfen würde. Schaden sollte ein Scrub nicht, außer beim Vorliegen schwerwiegender Hardwareprobleme.

 

[MrToddsFriends]

Hilft https://bugs.freenas.org/issues/15691 oder ist die Sachlage bei Dir doch ganz anders? Sprich: Wurde (per Wizard oder per Hand) ein neues Dataset "gemeinsam" erzeugt?

Nachtrag: Scrubs (und SMART Tests) lässt man am Besten per Zeitplan gesteuert automatisch laufen, etwa so:
https://forums.freenas.org/index.php?threads/need-help-setting-up-smart-zfs-scrubs.16182/#post-82403

 

[4styler]

Hallo MrToddsFriend,
die Ausgaben sind folgendermaßen:

Erstellt habe ich ganz am Anfang mal ein Dataset gemeinsam welches den entsprechenden "Ordner" angelegt hat. Nach dem Update innerhalb von 9.10 haben sich alle Datasets im Pool TB3x4 aufgelöst und der
Pool war jungfreulich. Witziger weiße ist dem Pool Server nichts passiert.

Der Sachverhalt aus dem anderen Thread ist ein anderer. Bei mir ist der Fehler durch das sich auflösende Filesystem vom System passiert und nicht einfach so durch das auflösen der Share Names usw.
Bei mir kamen die Daten ja durch den Snapshot auch wieder und sind absolut ok und nicht beschädigt. Habe auch inzwischen fast alles weggesichert. Wenn ich ein neues Dataset anlege und die
Daten in dieses Dataset verschiebe dürft nichts passieren oder? Mir geht es darum alles wieder gerade zu ziehen. Ich werde das neue Dataset nicht "gemeinsam" nennen ;)

Zur letzten Frage von dir: Meinst du beim ersten installieren oder aktuell? Ich habe immer alles über die WebGUI gemacht. Ausser bei diesem Fehler jetzt. Das Dataset wurde damals von mir glaube ich per Wizard angelegt.
Ich kann es dir aber echt nicht sagen.

Den Scrub und die SMART Tests lass ich normalerweise einmal die Woche laufen. Ich bin mir nur grad nicht sicher ob das so Clever ist ;)

Mir fällt auf das mein Speicher immer voller wird, auch wenn ich was Verschiebe. Kann es sein das ein
Scrub auch die allokierten Blöcke wieder freigibt?
EDIT: Habs gefunden. Liegt im Papierkorb :D

Viele Grüße
Stefan

 

[MrToddsFriends]

Zur letzten Frage von dir: Meinst du beim ersten installieren oder aktuell?

Meine Frage nach einem neu erzeugten Dataset "gemeinsam" war auf aktuell gemünzt, im Zusammenhang mit dem von mir verlinkten Bugreport #15691. Ist aber nach Deiner Aussage hier irrelevant.

In https://forums.freenas.org/index.php?threads/pool-importing-with-empty-datasets.43396/ scheint jemand ein sehr ähnlich gelagertes Problem gehabt zu haben, bei der Diskussion dort ist aber auch nichts Brauchbares herausgekommen. Bleibt schleierhaft für mich.

Ich denke nicht, dass die Ursache bei Scrubs an sich zu suchen sind (und würde auch nicht auf Scrubs verzichten wollen). Frage am Rande: Welche SATA-Ports an Deinem ASRock C2550 sind in Verwendung?

 

[4styler]

Guten Morgen :)

ich meine das es 0-5 ist. Ich müsst im Bios aber genauer nachschauen. 4 Platten hängen an einem Raid Controller und 2 auf nem anderen. Sind getrennte pools. Ich habe folgende vermutung über den Ablauf:
Ich habe das Update gemacht und das NAS hat neu gestartet. Als es wieder da war habe ich meinen einen Pool entschlüsselt und alle Dienste druchgestartet. Ich nehme an das die Entschlüsselung nicht
fertiggeworden ist. Aus diesem Grund blieb dieser pool von dem Ausfall verschont. In diesem Zeitraum (der Entschlüsselung) hat sich das Dateisystem von meinem Boot device ins Nirvana verabschiedet.
Der CIFS Dienst der mit meinem Rechner bereits verbunden war (Win 10) hat sich nicht sauber beendet und auf dem Pool blödsinn gemacht was irgendwie zu einem löschen des Pools geführt hat.

Ich hab den Thread gelesen und das klingt schon verdammt ähnlich. Jetzt ist die Frage wenn es das gleiche verhalten war wie in dem Thread dann irre ich mich und gemeinsam war kein Dataset sondern nur ein
angelegter Ordner? hmm ich muss tatsächlich grad passen....
Ich glaube auch nicht das der Fehler von nem Scrub kommt. Ich wollte nur mal wissen was der eigentlich macht ;)

Was ich lustig finde ist das der Speicher noch allokiert bleibt. Das heißt für mich das ja eigentlich nur ein Verwaltungsteil der Platte gelöscht wird (Die Tabelle die die Files enthält). Geht das überhaupt? Das
müsste ja dann über einen Scrub repariert werden können?

Viele Grüße
Stefan

 

[MrToddsFriends]

Ein Scrub repariert nicht

• versehentliche (oder wie auch immer entstandene) Verwechslungen bzw. Überdeckungen von Datasets und Verzeichnissen,
• versehentlich im aktuellen Zustand eines Datasets gelöschte Daten, die nur noch in Snapshots vorhanden sind.

Es wäre inakzeptabel und kontraproduktiv, wenn ein Low-Level Mechanismus wie ein Scrub dem Server-Admin an solchen Stellen in die Quere käme.

Ein Scrub repariert Bit-Rot (auch als "silent data corruption" bekannt).
https://en.wikipedia.org/wiki/Data_scrubbing
https://en.wikipedia.org/wiki/Data_corruption#SILENT

 

[4styler]

Hey,
Danke für die Erklärung mit dem Scrub.
jetzt hab ich aber noch ein interessantes Phänomen. Die Anzeigen des verfügbaren Speichers und des überhaupt vorhandenen Speichers sind um etwa 2 TB!!!, beim Belegten um 5 TB!!!, verkehrt.
Der Pool TB3x4 sind 4 x 3 TB HDDs im Raidz1. Das ergibt bei mir einen (ohne overhead usw.) maximalen speicher von ca. 8 TB (7,29 TB). Davon sind etwa 2,5 TB belegt.
Kann mir evtl noch jemand erklären wie diese Anzeigen entstehen können:

Vor allem woher diese Menge an belgtem Speicher kommen oO? Der .recycle ist leer.

Ich hab das gefühl ich sollte den ganzen Pool platt machen und nochmal neu Anfangen...
Viele Grüße
Stefan

EDIT: Laut anderen Threads ist es so: Wenn ein Ordner direkt im Root des Pools angelegt wird und
dort Daten abgelegt werden und wieder gelöscht werden wird der Speicher erst nach einem export/import
des Pools wieder freigegeben. Da ja mein "Dataset/Ordner" sich direkt im Root des Pools befunden hat
vermute ich das dies das "Problem" ist. Normalerweise wäre das kein Problem gewesen da die Daten
im Dataset "gemeinsam" waren und sich nun aber im Ordner "gemeinsam" befinden welcher vom
Snapshot wiederhergestellt wurde.
Ich werde dann noch einen Neustart probieren da hier ja ein export/import gemacht wird.
Falls das nicht geht mache ich das manuell.

 

[warri]

Wie viele Snapshots hast du momentan? Diese verbrauchen auch Speicher, besonders wenn es große Änderungen seit dem ersten Snapshot gab.

 

[4styler]

Hallo Warri,
die Snapshots sinds nichts. Sind vielleicht 20 Stk und 2 davon überschreiten überhaupt die MB grenze (30 MB).
Hab ich gestern nämlich auch gedacht und erst mal fast alle gelöscht. Hat aber überhaupt keine veränderung gebracht.
Im Scrub zeigt er die Pool größe richtig an. Warum das überall anders nicht klappt....???
Hat sonst noch wer eine Idee?

EDIT:
Ich hab mal alle Snapshots bis auf die letzten beiden gelöscht. Es war die Ref. Größe die was bewirkt hat:

Jetzt ist es zwar besser. Stimmt aber immer noch nicht...:

Ich frag mich wo die 900 GB differenz sind. Des weiteren komme ich oben immer noch auf 10.8 TB
was mindestens 3,5 TB zu viel sind. Wo kommen die her? Hängt das mit dem RAIDZ1 zusammen?

Viele Grüße
Stefan

 

[MrToddsFriends]

Ein Mosaiksteinchen zur Klärung dürfte folgende Info sein: zpool list zeigt bei raidz-levels im SIZE Feld die Brutto-Größe, inklusive dem Platz für die Redundanz, hier in der Oracle-Doku "inflated disk space" genannt:
https://docs.oracle.com/cd/E26502_01/html/E29007/gbbti.html#gentextid-11135

Also in Deinem Fall (inklusive Umrechnung von 10er auf 2er Potenzen): 3 TB * 4 = 2,728 TiB * 4 = 10,91 TiB

 

[4styler]

Guten Morgen,
jo dann schaut das so aus als wenn das "der Fehler" wäre. Das NAS läuft wieder, alle Daten sind da, Snapshots sind bereinigt und es schaut wieder so aus wie es sollte.
Ich wollte noch einmal ganz herzlich danke für die Unterstützung sagen. FreeNAS 9.10 ist für mich erst mal gestorben. Hatte genug Aufregung damit :)

Viele Grüße
Stefan