Eine Geschichte voller (eigener) Fehler, einiger Inkompatibilitäten und Hürden und am Ende (noch offen) eventuell noch einem Datenverlust :handbuch:​

  • Hallo zusammen,


    bin hier bereits einige Jahre angemeldet, aber war nie sonderlich aktiv bzw. nur lesend hier.

    Habe momentan mein drittes oder viertes QNAP NAS in Folge im Einsatz und im Großen und Ganzen laufen die Systeme auch einfach ohne weitere Eingriffe oder Probleme.


    In in den früheren Jahren sah ein Wechsel von einem zum anderen NAS in etwa so aus:

    WENN: eine der Platten Probleme bereitete oder der Datenspeicher nicht mehr ausreichend war

    DANN: kaufe ein neues NAS mit neuen Platten, kopiere die Daten rüber und alles läuft.


    Bei den ersten Systemen (glaube 4x1TB = 3 TB RAID5 und danach 4x3TB = 6 TB RAID6) war das alles kein Problem.

    Vor etwa 5-6 Jahren ist mein Plattenbedarf beruflich stark angestiegen und der Wechsel zu 4x6 TB = 12 TB RAID6 wäre nicht ausreichend gewesen.

    Habe daher etwas mehr in ein TVS-871 mit 16GB RAM investiert und bin zu 6x6 TB = 24 TB RAID6 gewechselt.

    Die zwei freien Slots habe ich mit 2x 500GB Caching SSDs bestückt, damit die Leseraten auch bei vielen kleinen Dateien konstant blieben. Dazu habe ich mir dadurch erhofft, später ggf. auch 7 bis 8 x 6 TB aufrüsten zu können.


    Nun sind einige Jahre vergangen und das System war bereits mehrfach ziemlich voll. Konnte mir dann durch die Kompression alter Daten und dem löschen bzw. hardlinken von Dupes helfen.

    Nachdem dann vor etwas über einer Wochen eine meiner 6 TB Platten SMART-Probleme meldete, und auch bei einer zweiten Platte I/O-Errors im Log zu sehen waren, wurde es höchste Zeit zu reagieren.


    Mein üblicher Wechsel zu einem komplett neuen NAS und neuen Platten war mir diesmal zu teuer. Auch bin ich eigentlich recht zufrieden mit meinem System und sehe keinen großen Vorteil für mich bei den neueren Systemen.

    Hätte ich es doch besser gemacht wie früher :/

    Stattdessen habe ich mir einen "tollen" Schlachtplan einfallen lassen wie ich das System wieder produktiv bringe und zugleich auch noch den Speicherplatz erweitern kann.


    Im Laufe dieser versuchten Migration habe ich jedoch einige Fehler gemacht, die mir erst jetzt bewusst sind.

    Gerne würde ich euch diese Schritte/Fehler berichten. Vielleicht lernt ja zumindest noch jemand daraus wie man es nicht macht ;)

    Oder vielleicht fällt sogar einem von euch noch etwas ein, wie mir noch etwas geholfen werden kann. Beantworte gerne Fragen und nehme Ratschläge entgegen.


    Dazu eignet sich die Vorstellung solcher Probleme eventuell auch um künftige "best practices" auszutauschen, zu diskutieren und dabei auch noch etwas zu lernen.

    Zumindest habe ich einiges gelernt, was ich in Zukunft gerne besser machen möchte.


    Zwar habe ich meine Story (in mäßigem englisch) schon im englischen qnap-forum gepostet (https://forum.qnap.com/viewtopic.php?f=11&t=155444), jedoch gingen eventuell aufgrund der Sprachbarriere ein paar Details und Hintergründe/Überlegungen unter.

    Wenn ein solches Cross-Posting nicht erwünscht sein sollte, dann werde ich diesen Thread hier auch gerne wieder löschen...


    Anbei kurz in Stichpunkten welche ersten Schritte ich als erstes unternommen habe und was passiert ist:

    1.1.) habe zwei neue WD RED 14TB Platten bestellt und die 6TB Platte mit den SMART-Errors gegen eine der 14 TB Platten getauscht. Das RAID-Recovery war nach 13-14 Stunden abgeschlossen und zumindest die Gefahr eines Ausfalls dieser Platte war gebannt.

    1.2.) Nach dem Resync habe ich die zweite 6 TB Platte gegen eine der beiden neuen 14 TB Platten getauscht.

    Noch wärend der Resync von Schritt 2 lief hatte ich Zweifel an meiner Vorgehensweise.

    Soll ich jetzt alle restlichen 6TB Platten auch gegen 14 TB Platten austauschen und danach eine RAID-Expansion durchführen? Brauche ich wirklich so schnell 56 TB? Hätte ich vielleicht besser zu günstigeren 10-12 TB Platten greifen sollen? Genügen mir für den Anfang eventuell auch erstmal 4x14TB = 28TB RAID6/RAID10?

    Die Preise für die 14 TB Platten sind ja auch nicht gerade niedrig...

    Bin dann blöderweise zu dem Entschluss gekommen mich mit erstmal 4 x 14 TB zufrieden zu geben. Die weiteren zwei Platten waren schnell bestellt. Nur wie komme ich am NAS zu diesem Ziel?

    Eine RAID (6) Migration von 6 Festplatten zu 4 Festplatten größeren Typs scheint nicht vorgesehen zu sein...
    Die Hinweise im qnap-forum gingen ebenfalls in diese Richtung; NAS neu aufsetzen und Daten einspielen :(


    Eigentlich wollte ich dies nicht, da ich auch die AD-Funktionalität (mit einem mühevoll ausgearbeitetem Rechtesystem usw.) von dem NAS genutzt habe und bereits in Vergangenheit die Erfahrung machen musste, dass sich ein Backup des ADs leider nicht fehlerfrei einspielen lässt. Die Erfahrungen bleiben übrigens bis heute bestehen. Irgendwie scheint dieses Backup nicht sonderlich zuverlässig zu sein.


    Backups der Daten daruf hatte bzw. habe ich. Zumindest habe ich mir vor etwa 3-5 Wochen eine externe 12 TB Platte ans NAS geklemmt und die wichtigsten Daten per rsync rüberkopiert. Einige Daten musste ich (wegen des begrenzten Plattenplatzes auf der Backup-Platte) weglassen.

    Ich denke (hoffe!) es sollten nur Archivdaten gewesen sein. Aber um ganz ehrlich zu sein weiß ich es nicht mehr. Und irgendwie traue ich mich gerade auch nicht nachzuschauen. Zumal diese eine externe Backup-Platte keinerlei weitere Redundanz hat und ich - sollte sie plötzlich auch defekt sein - ganz schön mit dem Ausfall zu kämpfen hätte.

    Man lernt daraus: häufiger Backups, besser dokumentieren was/wann gesichert wurde, und die Backups auch redundant vorhalten. Auch wenn das bei der Datenmenge schnell teuer werden kann :/


    Also habe ich stattdessen nach anderen kreativen Lösungswegen gesucht und damit den ersten Schritt in Richtung Abgrund getätigt...

    Meine Idee war:

    6X6 TB im RAID 6 = 24 TB Speicher und 2 Platten dürfen ausfallen

    5x6 TB im RAID 5 = 24 TB Speicher und 1 Platte darf ausfallen.

    Also könnte ich mein aktuelles System doch "ganz einfach" zu einem RAID5 umwandeln und könnte es (bei minimal reduzierter Redundanz) mit 5 statt 6 Platten weiterbetreiben.

    Ich hätte dann noch 3 Slots von dem 8-Bay NAS frei um 3 x 14 TB = 28 TB im RAID 5 zu erstellen.

    Könnte dann die 24 TB rüberkopieren, danach die alten Platten entfernen und das RAID 5 zu einem RAID 6 (mit dem selben Speicherplatz aber mehr Redundanz) expandieren.

    Wenn das nur alles so einfach wäre...


    Den Wechsel vom RAID6 zum RAID5 stellte ich mir dabei leider viel zu leicht vor. Naiv betrachtet klingt das doch eigentlich nach nicht sonderlich viel Aufwand. Das RAID6 lässt sich ja auch so (degraded) mit 5 Platten betreiben. Kann doch nicht sonderlich kompliziert sein das zu einem RAID5 umzuwandeln...

    Weit gefehlt! :(


    Habe folgende Schritte unternommen um meinen Plan umzusetzen:

    2.1.) der Resync auf die zweite 14 TB-Platte (Schritt 1.2) musste gestoppt werden. Ich wollte ja in Summe nur 5 Platten und brauchte diese 14TB Platte schließlich noch für meinen künftigen Plan.

    Dies habe ich gestoppt, indem ich die 14 TB Platte - auf die gerade gesynct wurde - als fehlerhaft markiert und sie aus dem RAIDSet entfernt habe:

    Code
    mdadm --manage --fail /dev/md1 /dev/sdh3
    mdadm --manage --remove /dev/md1 /dev/sdh3

    Spoiler: eine Platte auf diesem Weg als fehlerhaft zu markieren scheint sich das NAS wohl zu merken :/

    Die Platte wurde mir danach überall auf dem System als fehlerhaft (I/O Fehler) angezeigt und konnte (auch in einem anderen Slot) nicht mehr für die Erstellung eines neuen Speicherpools ausgewählt werden.

    Zwar gab es die Möglichkeit über die GUI einen "Badblock"-Scan mit anschließender Markierung als fehlerfrei durchzuführen, nur dauert dieser Scan bei einer 14 TB Disk mehrere Tage :ziped:

    Nachdem es auch nicht half die Platte (zumindest die ersten TB) und den Superblock des Raids mit Nullen zu überschreiben, half bei mir am Ende nur eine Neuinstallation des Systems.

    Wenn ihr einen Rat habt um die Platte auch bei einem laufenden System wieder als Fehlerfrei zu markieren, dann nur zu ;)


    2.2) Den Wechsel zum RAID5 habe ich wie folgt gestartet:

    Code
    mdadm --grow /dev/md1 --level=raid5 --raid-devices=5 --backup-file=/mnt/HDA_ROOT/RAIDBackup/mdadmbackupfile

    Auch dies war ein Fehler. Denn irgendwie lief dieser "grow" nur mit weniger als 1 MB/s (und ich konnte das auch nicht durch das Tuning diverser min/max-Werte beschleunigen) und würde 60 Tage (90-100k Minuten) zur Durchführung benötigen.

    War wohl nix mit meiner Annahme, dass das schnell erledigt wäre =O

    Zu dem zweiten (und evtl. dritten) Fehler dieser verhängnisvollen Zeile komme ich später noch...


    Aber wie hätte ich sonst den nötigen Plattenplatz auf einem System mit "nur" 8 Slots schaffen können?

    Wenn ich das RAID 6 mit nur 5 Platten im degraded Modus betrieben hätte, dann würde das NAS umgehend ein recovery starten, sobald ich eine neue/leere Platte angeschlossen wird.

    Kann man dies bei QNAP eigentlich auch unterbinden?

    Also ein 6x6 TB RAID6 mit nur 5x6 TB (degraded) betreiben, und dann trotzdem 3x14 TB Platten hinzufügen und darauf einen neuen Speicherpool anlegen?

    Wenn ja, dann hätte es mir sehr geholfen, wenn ich es früher gewusst hätte. Wenn nein, dann wäre es ein Feature Request für QNAP.


    Habe dann meinen Plan aufgegeben und mir einen neuen Plan ausgedacht:

    3.1) entfernen aller alten Platten mit meinen Daten

    3.2) einbau von 3x14 TB "neue"/leere Platten

    3.3) Neuinstallation des NAS-Systems. Kann dann auch ein Recovery meiner AD-Daten probieren. Notfalls muss ich das halt alles wieder von Hand einrichten.

    3.4) Nachdem das System läuft, die 5 Platten als degraded RAID6 anschließen und dann auf den Datastore zugreifen und alles kopieren.

    3.5) wenn dann alles kopiert ist, dann kann ich die alten Platten entfernen und das RAID5 zum RAID6 migrieren


    Auch der Plan hatte leider einige Lücken und ging aufgrund von einem meiner früheren Schritte leider mächtig schief. Gerne dazu mehr in meinem nächsten Post - nach ein paar Stunden Schlaf ;)


    Viele Grüße

  • Dann will ich hoffen, das Du die wirklich wichtigen Daten auch auf der extern Platte hast.

    Wenn Du vorher in den QTS Handbüchern gesucht hättest, hättest Du gefunden, das ein Raidmigration nur in folgender Richtungen möglich ist:

    Einzeldisk -> Raid 1

    Raid 1 -> Raid 5

    Raid 5 -> Raid 6


    Aber von einem "höheren" zu einem "niederigen" Raidlevel ist nicht möglich.

    Das ginge tatsächlich nur über den Weg eines zweiten Raids mit anderem Raidlevel und umkopieren der Daten.

    Die Wertung hoch/niederig ist nur nummerisch gemeint und soll keine Aussage über die Qualität eines Raidlevels sein, daher die Hochkommata.


    Erschwerend käme aber bei einer zweiten Raidgruppe hinzu, das QTS die Systemdaten immer auf der ersten Raidgruppe bzw. dem ersten Volume installiert. Also selbst wenn Du die Daten auf ein zweites Raid kopierst hättest, müsste die erste Raidgruppe im NAS verbleiben.

    Um mehr Kapazität zu erhalten, bleibt tatsächlich nur der "Schweineweg" über 1.) entweder Tausch aller HDDs nach und nach, rebuilds abwarten, Kapazität erweitern, oder 2.) Backup, Backup, nochmals Backup :)und das NAS komplett neu aufsetzen.

    Im Fall 2.) nutzt es nichts, die NAS Konfig zu sichern und wieder einzuspielen wenn man den Raidlevel ändern will.

    Der Raidlevel ist mit in der Config und wird dann auch wieder hergestellt.


    Und ich bin mir auch sicher, das ich einmal den Fall hatte, eine "testweise" in NAS gesteckte HDD ein viertel Jahr später nach einem Plattenausfall als Ersatz in das NAS geteckt zu haben. Die "neue" HDD wurde sofort als "broken" gekennzeichnet.

    Nach etwas Überlegung warum fiel mir ein, das diese HDD vor einigen Wochen im NAS war, als "Gut" befunden wurde, dann gezogen und als Ersatz auf die Seite gelegt wurde.

    In der /mnt/HDA_ROOT/.conf habe ich dann in die Seriennummern der HDDs gefunden. Soweit ich mich erinnere, habe ich die s/n gelöscht, alle Partitionen am PC entfernt und die Platte wieder ins NAS gesteckt, und diesmal wurde sie sauber integriert und der Rebuild startete.

    Aber das ist ziemlich lange her und war auch noch ein CAT1 NAS.

    Bei einem CAT2 NAS stehen dort die Device WWPNs, aber ich habe die Zurodnung von WWPN zur HDD nicht gefunden. Ob man sich tatsächlich darauf verlassen kann das die Ziffer am Ende der Zeile die Reihenfolge der Disks angibt!?

    QNAP ist hier immer für Überraschungen gut :P!

    Und ohne Backup würde ich nicht experimentieren :mcup:.


    Gruss

  • burgerkind

    Erst mal Danke für Deinen spannend Bericht. Ich finde es interessant auf welche Ideen die Leute kommen. In Deinem Fall hat es jetzt leider nicht funktioniert. Aber Du musst schon zugeben, Deine Projektansätze sind schon ein wenig hardcore. Und das Ganze ohne mehrfaches und vor allem komplettes Backup zu machen... ultra-hardcore. Ähm, da hätte ich während der Umsetzung Schweißausbrüche im Wasserfall-Ausmaß. Ich installiere ja nicht mal ein kleines Update ohne komplettes Backup, inkl. aller Einstellungen. Als alter Hase stehe ich nicht mehr auf solchen Nervenkitzel, vor allem wenn es sich auch noch um geschäftliche Daten handelt. Ich muss inzwischen auf meine Gesundheit achten. :) Wenn die private Musiksammlung flöten geht, ärgerlich aber verschmerzbar. Aber ich schätze Dein Backup-Defizit dürfte Dir nun bekannt sein.


    Dann solche Experimente mit einen Produktiv-System. =O Für so etwas eignet sich ein Test-System, bei dem man ausreichend Zeit für die Experimente hat, denn - wie Du selbst festgestellt hast - es kommt immer anders als man denkt. Und wenn ich eines in all den Jahren IT gelernt habe, es dauert immer länger als man plant.


    Wenn ein solches Cross-Posting nicht erwünscht sein sollte, dann werde ich diesen Thread hier auch gerne wieder löschen...

    Wieso denn, dass hier ist ein anderes unabhängiges Forum.

  • Finde das auch mega gewagt, aber ok du haftest vermutlich selber dafür, wenn was fehlt, was benötigt wird und dann auf einen finanziellen Schaden der Firma hinaus läuft.


    Eines habe ich bei QNAP gelernt, Backup und noch ein Backup.

    Ich sichere hier Ständig Versioniert meine Contis und wichtigen Daten/Dokumente weg, dazu Fullbackup aller Daten auf HDs über eine USB 3 Dock.

    Zudem über einen VPN Tunnel alles auf ein anderes NAS, welches 15min entfernt steht, min 2 mal die Woche automatisch.


    Ein QNAP platzt beim Update schon mal, dann noch am Raid zu schrauben, was auch bei einem Update, wie hier nach zu lesen ist, bereits mehrfach auseinander geflogen ist, mega hardcore.


    Da muss jetzt eine Backup Strategie her, vor allem wenn es um so eine Datenmenge geht, da ist auch die Wiederherstellungszeit ein Problem.

    4 * 14TB Raid 5, Sync dauert 24-30h, dann Daten von HD drauf, 14TB 12-16h, das dann 2 mal wenn du Singel Disks nimmst und das aufteilen kannst.


    Denke auch an ein Offside Backup, also wenn die Bude brennt ist sonst wieder alles weg, so hast du noch Stand von vor 1-7 Tagen.


    Ist ja schön das du ein Raid 6 fährst, aber das bringt dir nix, wenn es platzt, hast ja jetzt selber erfahren.

    Selbst bei 8 HDs halte ich ein Raid 5 noch für vertretbar, ein Backup ist eh das einzige was im Fall der Fälle hilft.

    Ist Verfügbarkeit alles, ok dann Raid 6.


    Und ja eine Migration zwischen Raidmodi würde Tage bis Wochen benötigen, das ist total normal, weil im Betrieb alles freigeräumt werden muss, dann muss es auf neu organisiert werde und neu geschrieben werden.

    Das sind 2 + 2+ 1 + 2 IOs pro Sektor.


    Also Lesen des Blocks + Parität, wegschreiben + Parität, Nullen, Einlesen und Wegeschreiben + Parität.


    Alles Random IOs, wenn dann noch mit den Daten gearbeitet wird, hat das vermutlich noch Vorrecht und dann gurkt der Raiddeamon mit 100-200Kb/s rum, dann sind locker auch mal 30Tage+ drin.

    Wenn dann noch SMR HDs ins Spiel kommen, kannst vermutlich Jahre rechnen.


    Bei Storage mit HDs ist Geduld und dann noch mal sehr sehr viel mehr Geduld wichtig, bei SSDs reicht eine einfache Ladung Geduld, die sind halt Faktor x schneller.

  • Hallo nochmal und vielen Dank für eure Hinweise und Ratschläge.


    Ihr habe mit allem absolut Recht und auch mir ist bewusst, dass meine "Spielereien" ein Spiel mit dem Feuer waren und ich vor der ersten Aktion sofort mein Backup auf dessen Aktualität und Vollständigkeit hätte prüfen müssen.

    Hätte ich vielleicht dazusagen sollen: nicht nachmachen ;)


    Ich kann euch auch versichern: bei meinen Kunden hätte ich das definitiv anders gehandhabt.

    Entweder über ein verschlüsseltes Backup über einen VPN-Tunnel zu einer entfernten Lokation, oder über täglich rotierende (meistens 6-7 Stück) externe Disks, von der jeweils nur eine lokal gelagert wird.

    Nur haben meine Kunden glücklicherweise auch selten Datenmengen > 4 TB.


    Bei mir wird das NAS zu großen Teilen genutzt um Backups (von der Buchhaltung angefangen, über Projektdokumentationen, Mailarchiv, usw.) darauf abzulegen.

    Die aktuelleren Daten befinden sich auch immer noch auf den jeweiligen Quellsystemen.

    Aber es gibt halt auch Archivdaten. Jene, von denen man nie genau weiß, ob sie jemals wieder gebraucht werden.

    Und dann gibt es Daten, deren Wiederbeschaffung (teilweise sehr) zeitaufwändig, aber möglich sind.

    Von einem Archiv aller ISO-Files aus dem MS Action Pack, über ISOs gekaufter Software aus dem letzten Jahrzehnt, ISO-Images aller erdenklichen Linux-Distributionen in den jeweiligen Versionen, usw.

    Kopfschmerzen bereiten mir nur die Sachen, an die ich gerade nicht denke. Alles was auf den Laptops keinen Platz mehr gefunden hat und an deren Auslagerung ich mich nicht mehr erinnern kann.

    Da wird sicherlich noch was kommen. Es wird weh tun, aber mit einem finanziellen Schaden muss ich vermutlich nicht rechnen.

    @Mavalok2 vergleichbar mit der privaten Musiksammlung oder dem privaten Bilderalbum. Wenn diese Daten weg sind, dann entsteht kein finanzieller Schaden und das Leben geht weiter. Wenn man die letzten 20 Jahre daran gesammelt hat, dann schmerzt es trotzdem :/


    So ist es halt im Leben: Mensch macht Fehler und Mensch lernt (hoffentlich) daraus.

    "Fehler machen klug, deshalb ist einer nicht genug".


    Inzwischen steht die Erarbeitung eines gescheiten Backupkonzeptes recht weit oben auf meiner TODO-Liste.

    Ein tägliches Komplettbackup aller Daten wäre vermutlich nicht wirtschaftlich. Aber vielleicht schaffe ich es ja die Daten so zu strukturieren und voneinander zu trennen, dass bestimmte Teile täglich/stündlich off-site gesichert werden, manche Daten auf lokalen/wechselnden Platten und manche - weil temporär und einfach zu ersetzen - auch garnicht.


    @FSC830: danke auch für den Hinweis zu der "/mnt/HDA_ROOT/.conf". Vermutlich hätte ich dort tatsächlich nur die Seriennummern/ID (z.B. "pd_dev_wwn_5000CCA26XXXXX") der als "defekt" angezeigten Platte entfernen müssen.

    Das mit den Systemdaten auf dem ersten Volume war mir anfangs auch nicht so bewusst und ich wurde auch im englischen Forum darauf hingewiesen. Eventuell hätte sich die Volumegroup bzw. das logical Volume auch auf das andere Raid verschieben lassen. Aber es stimmt schon: alleine deshalb ist bereits eine Neuinstallation zu empfehlen.


    Okay, dann setze ich mal meinen Bericht über die weiteren durchgeführten Aktionen fort. Wer bisher schon ein leichtes Kribbeln verspürt hat, der sollte sich jetzt eventuell gut festhalten. Es kommt noch schlimmer :/

    Mehr dazu gleich in einem eigenen Post.

    EDIT: kann den Rest gerade nicht posten. Für einen Post waren die 10.000 Zeichen überschritten und einen zweiten kann ich gerade nicht abschicken:

    Code
    Die letzte Antwort in diesem Thema stammt bereits von Ihnen, Sie können erst in 172.760 Sekunden erneut auf dieses Thema antworten.
  • Dann ist das ein Dummy Post, damit Du die spannende Geschichte weiter schreiben kannst ;). Dann brauchst Du nicht zu warten - und wir auch nicht :P.


    Gruss

  • FSC830: dankeschön :)


    Der Plan beim ersten Post hier sah eigentlich so aus:

    Mod: Zitat ohne Quellenangabe ... korrigiert! :handbuch::arrow: Die Zitat Funktion des Forums richtig nutzen

    3.1) entfernen aller alten Platten mit meinen Daten

    3.2) einbau von 3x14 TB "neue"/leere Platten

    3.3) Neuinstallation des NAS-Systems. Kann dann auch ein Recovery meiner AD-Daten probieren. Notfalls muss ich das halt alles wieder von Hand einrichten.

    3.4) Nachdem das System läuft, die 5 Platten als degraded RAID6 anschließen und dann auf den Datastore zugreifen und alles kopieren.

    3.5) wenn dann alles kopiert ist, dann kann ich die alten Platten entfernen und das RAID5 zum RAID6 migrieren

    Bis Punkt 3.3 war alles kein Problem. Okay, das AD konnte (wie vermutet) natürlich nicht wiederhergestellt werden. Keine Ahnung wo da das Problem liegt. Aber damit hatte ich mich bereits abgefunden.

    Punkt 3.4 war dagegen deutlich schwieriger als erwartet...

    Als erstes war mir folgendes nicht bewusst:

    direkt nachdem ich die Platten der früheren Installation in das System der neueren Installation eingeschoben habe, wurden sofort die ganzen RAID1-Sets mit dem System (md9, md13, usw.) synchronisiert und auf den alten Platten überschrieben =O

    Nicht nur, dass es danach keinen Weg mehr zurück gibt - es wird mir auch im späteren Verlauf noch zu schaffen machen.


    Habe im Nachgang nämlich folgende Fehler erkannt:

    Fehler 1: ich habe den reshape (also die Migration von RAID6 zu RAID5) nur gestoppt und nicht rückgängig (mdadm --assemble --update=revert-reshape --backup-file=...) gemacht. Hätte ich es rückgängig gemacht, dann hätte das Einbinden vermutlich funktioniert und ich hätte keine großen Schwierigkeiten im weitern Verlauf gehabt

    Fehler 2: ich habe die Backup-Datei für den Reshape unterhalb des Ordners "/mnt/HDA_ROOT/RAIDBackup/" abgelegt. Aben jener befindet sich auf dem RAID1, welches gnadenlos mit dem neuen System durch einen Sync überschrieben wurde.


    Fehler 3: Zwar habe ich mir ein Backup dieser Datei auf mein Laptop gezogen, aber mir war in dem Moment nicht klar, dass die Datei nicht nur einfache Daten über die Struktur des Raids, usw. enthält, sondern kontinuierlich mit dem Status des reshapes aktualisiert wird. Ein Backup, welches bereits am Anfang des Reshapes erstellt wurde ist damit so gut wie nutzlos.

    Um das Raidset im neuen System einzuhängen (über --assemble) wird das Backup-File in der aktuellsten Form benötigt.


    Habe dann doch noch das RAID mit dem Backup von meinem Laptop "assembled" bekommen. Eine andere/aktuellere Datei war nicht vorhanden und mir blieb keine Wahl.

    Umgehend wurde der Reshape-Prozess fortgesetzt. Auch wenn ich ihn sehr schnell "gefreezed" habe. Die Volume-Groups darauf habe ich aber erst wiedergefunden, nachdem ich den Prozess über "revert-reshape" (dauerte 2-3 Stunden) rückgängig gemacht habe. In Wirklichkeit wurde vermutlich nur der Status des Reshape rückgängig gemacht und in diesen 2-3 Stunden aufgrund der veralteten Backupdatei Daten im RAID vernichtet. Da der Prozess sehr langsam war werden das vermutlich 10-30 GB an Daten sein.

    Trotzdem habe ich danach meine Volumegroup wieder gesehen:

    Sogar das Webinterface des QNAP hat nach einem Neustart wieder etwas erkannt. Auch wenn das alles sehr merkwürdig ausgesehen hat:

    Extern verlinktes Bild entfernt! Bitte im Beitrag hochladen


    Als ich das Logical Volume mit meinen Daten jedoch über SSH (über /dev/mapper/cachedev5 als auch über /dev/vg2/lv5) mounten wollte, habe ich lediglich die Fehlermeldung "no superblock found" bekommen.

    Dump2fs hat mir jedoch noch etwas Hoffnung gemacht:

    Mein Verdacht: ich habe mir die ersten 10-30 GB an Daten über das Reshape und das anschließende Revert zerschossen. Aber vielleicht lässt sich das Dateisystem ja noch soweit reparieren, dass die restlichen TBs noch irgendwie zu retten sind.


    Und nun kommt Fehler 4: Ich habe das fsck von der Qnap-shell genutzt und damit versucht das Dateisystem zu reparieren.

    Kann schlecht sagen ob ich mir auch damit etwas kaputt gemacht habe.

    Ist das wirklich dazu geeignet? irgendwie wirkt mir das gnadenlos veraltet und nur für ext2 geeignet.

    fsck.ext4 existiert auf dem NAS jedoch nicht.


    Auf der früheren Installation hatte ich dafür noch ein debootstrap eines Debian-Systems liegen, aber das ist nun nicht mehr da.

    Das neu zu erstellen war auch etwas schwieriger als damals. Scheinbar gibt es das "Optware" Package nicht mehr :/

    Habe dann auf einem anderen System ein debootstrap eines Debian 10 Systems erstellt und das dann auf das NAs rüberkopiert.

    Es funktionierte und ich konnte ein aktuelles fsck.ext4 innerhalb dem per chroot laufendem Debian 10 auf dem QNAP ausführen.

    Ohne superblock ist der Check natürlich fehlgeschlagen. Habe daher über mkfs.ext4 mit dem "-n" Parameter (ganz wichtig um das System nicht zu überschreiben!) die vermutlichen Positionen der Superblöcke in Erfahrung gebracht:

    Code
    mkfs.ext4 -n /dev/mapper/cachedev5
    Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
    102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
    2560000000, 3855122432

    Fehler 5: mit dem Parameter "-b 32768" war es möglich fsck.ext4 zu starten. Ich konnte dort einige vermeintliche Fehler korrigieren aber frage mich im Nachgang warum ich einen so früheren Superblock verwendet habe?!?

    Warum nicht den letzten von der Liste. Besonders wenn ich den Verdacht habe, dass die ersten GB vom dem RAID defekt sind?!?

    Die Fehlermeldungen sahen übrigens wie folgt aus:

    Code
    Inode 523910 block 513 conflicts with critical metadata, skipping block checks.
    Inode 523910 block 1435 conflicts with critical metadata, skipping block checks.
    Inode 523910 block 513 conflicts with critical metadata, skipping block checks.
    Inode 523910 block 1281 conflicts with critical metadata, skipping block checks.
    Inode 523910 block 2807 conflicts with critical metadata, skipping block checks.
    Inode 523910 block 513 conflicts with critical metadata, skipping block checks.
    Inode 523910 block 1429 conflicts with critical metadata, skipping block checks.
    Inode 523910 block 1 conflicts with critical metadata, skipping block checks.
    Inode 523910 block 1 conflicts with critical metadata, skipping block checks.


    Gut 20 Stunden später war der fsck jedoch noch immer nicht durch.


    Mehr kann ich gerade nicht schreiben. Das 10.000 Zeichen Limit schlägt wieder an ;)

    Spoilter: der RAM war voll und fsck konnte deshalb nicht zu Ende durchgeführt werden.

  • Zitat von burgerkind

    ...Scheinbar gibt es das "Optware" Package nicht mehr...

    Entware ist wohl der Nachfolger, bietet das nicht auch diese Option?

    Und wieder die nächsten 10.000 ;).


    Gruss

  • burgerkind

    Wenn Du mehr Platz zum Schreiben benötigst, wäre der Blog hier im Club eine Alternative. Da gibt es so viel ich weiß keine Limite. Ist schade wenn Du im Schreibfluss gehindert wirst. Schließlich wollen wir alle wissen wie der Krimi in allen Details ausgeht.

  • Spannende Story, aber die Fehler die aktuell kommen, würde ich dem Stress der Situation zuordnen und sind damit nicht vermeidbar, vor allem hast du sicherlich noch kein QTS System so tief technisch wieder zusammen stecken müssen.

    Glaube fast jeder andere hätte sich ein :beer: geholt und einfach alles gekillt und bei 0 angefangen.

  • Aufgeben ist nicht ;)


    Der fsck-Prozess belegte inzwischen gut 14,5 GB RAM und einige GB Swapspace.

    Es war sinnlos das noch weiter laufen zu lassen. Statt 10 Zeilen pro Minuten brauchte der Prozess im Swap etwa 10 Minuten für eine Zeile.

    Ich war mir sicher, dass der fsck nie zu Ende laufen wird. Also habe ich ihn abgebrochen.


    Deshalb mein Fehler Nr. 6: erstelle kein Filesystem auf einem NAS, dessen RAM nicht ausreicht um es zu prüfen!

    Vermutlich einer der wenigen Fehler, die ich vorher nicht direkt wissen konnte und für den ich mir mal keine Schuld gebe.

    In Zukunft werde ich auf dem NAS nur noch Volumes mit maximal 6-10TB erstellen.


    Habe mir dann ein externes Gehäuse von QNAP bestellt (ein TL-D800C) und darin die Platten verbaut.

    Mein Ziel war es das Gehäuse mit den Platten an mein Laptop (mit 128 GB RAM) anzuschließen und dort den fsck.ext4 erneut laufen zu lassen.

    Aber auch das ist fehlgeschlagen. Konnte die Volume-Group (das Volume war ein "Thick"-Volume) nicht aktivieren.

    Code
    WARNING: Unrecognised segment type thick

    Habe hier zum ersten Mal feststellen müssen, dass QNAP ein gepatchtes LVM2 verwendet. Diese Info hätte ich auch hier im Forum finden können...

    Eigentlich ist soetwas ein k.o. Kriterium für mich. Ein System, welches mich an einen Hersteller bindet und patches an kritischer Infrastruktur.

    Kann man dem NAS eigentlich auch beibringen ein standardkonformes LVM zu verwenden? Oder von mir aus auch ganz auf das LVM zu verzichten. Die fehlenden Snapshots könnte ich verschmerzen.


    Habe dann noch probiert LVM2 aus den GPL-Sourcen von Qnap unter einem LUbuntu 20.04 zu kompilieren. Es ist fehlgeschlagen. Bei einem 18.04er LUbunutu hat es dann geklappt.

    Nur ist es mir dort noch nicht gelungen den 14.4er Kernel zu kompilieren.

    Habe es dann aufgegeben und einen anderen Weg gesucht.



    Auf meinem TVS-871 läuft derzeit die initialisierung eines neuen RAID6 mit nun 5x14 TB. Habe mir noch zwei weitere (in der Summe inzwischen sechs Stück) von den 14TB WD Reds gekauft.

    Daran habe ich nun die alten Platten in dem externen TL-D800C Gehäuse angeschlossen und kann darin auch die volume-group aktivieren.


    Meine Idee war jetzt das (aktiviert) logical Volume per DD in ein Raw-Image auf dem NAS zu sichern, und dann per SMB/NFS auf das Image zuzugreifen um fsck.ext4 von meinem Laptop laufen zu lassen.

    Auch diese Idee war leider nicht zu Ende gedacht. Nach fast 24 Stunden ist der DD abgebrochen, weil die maximale Dateigröße für ext4 (16 TiB) erreicht war :X

    Code
    root@NAS:/share/HDDImage# dd if=/dev/vg2/lv6 bs=4096 conv=notrunc,noerror | pv -tpreb -s 20890720927744 | dd of=/share/HDDImage/image.ext4
    dd: writing to '/share/HDDImage/image.ext4': File too large
    34359738361+0 records in
    34359738360+0 records out
    17592186040320 bytes (18 TB, 16 TiB) copied, 86220.7 s, 204 MB/s
    
    
    16.0TiB 23:57:00 [ 194MiB/s] [==============================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================>                                                                                               ] 84%

    Auch daran hätte man denken können. Noch ein Grund mehr, der dafür spricht kein Volume über 16TB anzulegen. Man nimmt sich dann die Möglichkeit eines DD-Images...


    Mit den bisher gesicherten 16TiB kann ich über SMB (per "losetup -r" auf meinem Laptop auf loop0 verbunden) nichtmal ein dumpe2fs anzeigen. Auf dem QNAP (direkt auf dem Device) klappt es.

    Ich hoffe nicht, dass dies noch an Qnap-spezifischen Änderungen des ext4 Filesystems liegt. Denn dann gebe ich komplett auf.


    Inspiriert durch den Post von Sumpfdotter (Versuch: Datenrettung zerstörter Directories) bin ich noch auf das Tool "xmount" gestoßen.

    Zum einen würde sich dieses Tool verwenden lassen um mehrere DD-Images hintereinander zu hängen und darauf zuzugreifen.


    Aber noch besser wäre jedoch folgende Zugriffsmöglichkeit:

    auf dem NAS das Device /dev/vg2/lv6 per xmount (inkl. Cache-File für Veränderungen) auf ein über ein SMB-Share erreichbares Verzeichnis mappen, und dann über das Netzwerk auf dieses Image darunter zuzugreifen.


    Dann könnte man sich den dd-dump sogar komplett schenken und stattdessen über das Netzwerk auf eine virtuelle Datei zugreifen, welche das Gerät repräsentiert.


    Mal schauen ob das klappt. Habe noch so meine Zweifel :/

    Soweit der aktuelle Stand von heute...


    EDIT: soviel vorab... xmount scheint zu funktionieren.

    Mit diesem Befehl konnte ich ein virtuelles Verzeichnis "xmount" innerhalb meines Shares erstellen, in dem sich zwei Dateien befinden:

    Code
    xmount --cache /share/HDDImage/cache --in raw /dev/vg2/lv6 --out raw /share/HDDImage/xmount
    root@NAS:/share/HDDImage# ls -als xmount/
    total 4
    0 drwxrwxrwx 2 root root              0 Jan  1  1970 .
    4 drwxrwxrwx 5 root root           4096 Jun 20 19:06 ..
    0 -rw-rw-rw- 1 root root 20890720927744 Jan  1  1970 lv6.dd
    0 -r--r--r-- 1 root root            269 Jan  1  1970 lv6.info

    Auf diese Dateien kann ich per SMB zugreifen.


    Habe auf meinem Laptop nun (aus Performance-Gründen, damit nicht das Cache vom Qnap geschrieben wird) ebenfalls xmount gestartet:

    Code
    xmount --cache /root/qnap.cache --in raw /mnt/qnap/HDDImage/xmount/lv6.dd --out raw /root/qnap-xmount
    losetup /dev/loop2 /root/qnap-xmount/lv6.dd


    Danach konnte /dev/loop2 sogar read-only mounten und sehe einen Teil meiner Ordner und Dateien:mcup:


    Wenn auch noch mit vielen vielen Fehlern "Structure needs cleaning".

    Deshalb läuft jetzt nochmal fsck auf dem loop2. Bin gespannt. Vermutlich wird das wieder 1-2 Tage dauern.

    Hoffe die 64 GB von dem Computer sind ausreichend. Bräuchte mein Laptop momentan und kann es gerade nicht für den fsck blocken.

  • Diesmal lag es weniger am Platz als daran, dass mein letztes Posting der aktuelle Fortschritt (Stand gestern Abend) war.

    Danke auch für den Hinweis mit dem Blog. Das wäre vermutlich ein besserer Ort gewesen. Sehr viel gibt es eventuell eh nicht mehr zu schreiben... :/


    fsck.ext4 läuft noch immer auf meinem PC (mit lesendem Zugriff über xmount auf die aktive VolumeGroup im QNAP und schreibendem Zugriff auf eine lokale Cache-Datei), aber meine Hoffnungen gehen gegen Null.

    fsck belegt nach etwa 15 Stunden bereits wieder knapp 50G RAM

    Code
    root@test:~# free -h
    total        used        free      shared  buff/cache   available
    Mem:            54G         54G        373M         79M        139M        2,0M
    Swap:          975M        143M        832M
    
    
    # top
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    36334 root      20   0 49,254g 0,048t    696 D  21,7 89,7 192:52.73 fsck.ext4


    Und der aktuelle Fortschritt ist minimal:

    Code
    Inode 1080925 block 16777392 conflicts with critical metadata, skipping block checks.
    Inode 1080925 block 79167888 conflicts with critical metadata, skipping block checks.


    Laut dumpe2fs habe ich einen Inode count von 318767104. Selbst wenn ich davon die 291766261 free inodes abziehe, dann bleiben noch immer 27000843 inodes übrig.

    (Gedanke am Rande: warum eigentlich diese extrem hohe Zahl an free inodes? Das Filesystem kann doch nicht zu 91,5% leer sein? Hmm, vielleicht spiegelt das auch nur ein wenig die Anzahl der theoretisch möglichen Dateien wieder...)

    Wenn ich gerade mit dem fsck bei Inode 1080925 bin, dann wären das gerade mal 4% Fortschritt - nach 15 Stunden. Könnte dann also in frühstens 15 Tagen mit einem Ende des Checks rechnen.

    Zumindest wenn die Geschwindigkeit beibehalten werden kann und diese nicht (aufgrund des deutlich langsameren Swappings) in die Knie gehen sollte.

    Werde heute Abend/Nacht nochmal einen Blick auf den Fortschritt werfen.


    Mehr als 128 GB RAM kann ich zuhause nicht ohne weiteres bereitstellen. Und selbst das keine 2 Wochen ununterbrochen am Stück.

    Hätte in meinem Keller-Testlab zwar noch einen älteren FSC-Server mit 144 GB RAM, aber das wäre auch nur minimal mehr und ich bekomme den Server auch nicht so einfach stabil mit Gigabit an das NAS angebunden.


    Hätte alternativ eventuell noch die Möglichkeit die Platten (inkl. dem externen QNAP Gehäuse) im Rechenzentrum an ein Testsystem mit 1-2 TB RAM zu klemmen und dort für einen Check in eine VM durchzureichen.

    Nur dann bräuchte ich erstmal eine VM, die dazu in der Lage wäre das properitäre LVM VolumeGroup von QNAP zu aktivieren.


    Also doch noch einen Versuch starten den QNAP Kernel aus den Quellen zu bauen? Bin hier nur Extern verlinkte Datei entfernt! Mehr dazu siehe in den Forenregeln! weitergekommen. Hat das hier schonmal jemand mit einem aktuellen Kernel geschafft? Oder doch lieber versuchen einen Dump von dem installierten (ist ja x86 bzw. amd64) NAS zu ziehen und das komplette NAS irgendwie in einer VM zum Laufen zu bekommen?

    Weiß momentan nicht was einfacher wäre... entsprechende Tools zum extrahieren der img-Dateien scheint es ebenfalls zu geben.


    Oder doch noch schauen, ob ich mit dd einen zweiten Dump ziehen kann, der (muss dann aber auf das Byte genau sein!) an der Stelle fortsetzt, an der mit dem ersten Dump das 16TB Limit erreicht war? In dem Fall könnte ich mir die zwei (Teil-)dumps auf ein WD MyBook Duo Gehäuse mit einem RAID0 aus 2x10 TB (mehr habe ich leider momentan nicht greifbar) kopieren und so ins RZ bringen. Weiterer Aufwand, weitere Kosten. Dabei sind bereits die bisherigen Aufwände nicht mehr wirtschaftlich zu rechtfertigen...

    Es geht inzwischen fast mehr um das "nicht aufgeben" wollen, als um die Sache selbst.


    Weitere Ansätze:

    Parallel habe ich übrigens noch ein zweites Loop-Device an die Quellen geklemmt (das ist das schöne bei xmount. Echt cooles Tool!) und mir das mit Testdisk und dem Sleuthkit (bzw. autopsy) angeschaut. Viel mehr als bei einem regulären mount sehe ich darauf aber auch nicht. Tools wie "r-explorer" und noch ein anderes (optisch fast identisches) Tool habe ich in der Demoversion ebenfalls probiert. Auch nicht mehr Erfolg als ein regulärer Mount.

    Photorec und Co. brauche ich bei der Datenmenge erst garnicht probieren.


    Sonst noch Ideen? Kann man fsck eventuell irgendwie beschleunigen bzw. den Inode-Check übergehen? Sehe beim Mount einen Teil der Ordner, aber kann sie nicht öffnen. Ein paar wenige Ordner lassen sich öffnen, aber die Dateien darin nicht lesen. Vermutlich hätte ich damals keinen "so frühen" (und vermutlich defekten) Superblock für den ersten fsck Versuch wählen sollen. Bei einem hinteren Block wäre das Ergebnis eventuell besser gewesen. Who knows?


    Schalte jetzt erstmal etwas ab, mache einen Ausflug aufs Land und ein paar Kilometer Spaziergang mit meiner Partnerin.

    Vielleicht wird der Kopf dann wieder etwas klarer ;)


    EDIT:

    Okay, brauche nicht länger warten. fsck wurde wegen Speichermangel abgebrochen:

    Edit:

    Habe jetzt ein zweites dd-image für die restlichen 4 TB erstellt. Mit xmount lassen sich beide dd-images (16+4 TB) zusammen nutzen und über diverse dd-dumps (mit skip in die Nähe der Grenze der beiden Dumps und dann eine sha1sum über 1GB Daten) konnte ich nachweisen, dass xmount und der vg identisch sind.

    Kopiere gerade das dd-image über usb 3.1 auf ein externes Gehäuse mit einem RAID0 aus 2x10 TB WD Platten. Die original-Platten archiviere ich dann mal für die nächsten 3-4 Wochen.

    Code
    root@NAS:/share/HDDImage# dd if=image.ext4 of=extern/image.ext4 bs=4096 status=progress
    3120753426432 bytes (3.1 TB, 2.8 TiB) copied, 7795 s, 400 MB/s

    in etwa 10 Stunden sollte er mit der großen Datei fertig sein. Mal schauen wann ich dann das nächste Mal ins RZ komme...


    PS @admins: sorry für die Verlinkung zu Pastebin. Die Kernelausgaben hätten sonst zu schnell das 10.000 Zeichen Limit gesprengt. Deshalb der Umweg zur externen Seite. Kommt nicht wieder vor.

  • Danke für die Geschichte.


    Im Prinzip ist die Frage schon interessant: Kommt man noch an die Daten, wenn man die Platten in einem anderen Gehäuse verwendet (z. B. weil das NAS selbst abgeraucht ist).


    P. S.: Ich hätte die Geschichte gestern Abend lesen müssen. Da hätte ich viel besser mitfühlen können. Da hatte ich nämlich gerade (scheinbar) das public-html Verzeichnis meines auch beruflich genutzten Webservers gelöscht. Der Hetzner-Support konnte das heute früh allerdings schnell beheben.

  • Eigentlich wollte ich dies nicht, da ich auch die AD-Funktionalität (mit einem mühevoll ausgearbeitetem Rechtesystem usw.) von dem NAS genutzt habe und bereits in Vergangenheit die Erfahrung machen musste, dass sich ein Backup des ADs leider nicht fehlerfrei einspielen lässt. Die Erfahrungen bleiben übrigens bis heute bestehen. Irgendwie scheint dieses Backup nicht sonderlich zuverlässig zu sein.

    • Heißt dies, da kommt noch ein Follow-Up zu diesem Thema mit AD?
    • Was hast Du in diesem Zusammenhang wo eingerichtet und konfiguriert, als AD-Client oder -Server?
    • Was hast Du fürs Backup unternommen (und was vergessen)?
    • Und welche Symptomatik hattest Du beim Zurückspielen, die Du als fehlerhaft oder unvollständig gewertet hast?


    Habe damit noch nicht experimentiert und auch noch nicht entschieden, ob ich dies einrichten will. Gehe eher davon aus, dies weiterhin nicht zu wollen.


    Meine Vermutung ist, dass Du bei Deinem NAS AD als Server eingerichtet hast, und Dein Backup ausschließlich mit QNAP-Diensten versucht hast. Aber dabei bleibt m.W. der Systembereich unberührt, und somit wenigstens die Dienstkonfiguration nicht gesichert. Dafür gibt es im Kontrollzentrum die Möglichkeit der Sicherung. Könnte daher sein, dass wenn Du diese zusätzliche Sicherung angelegt und restauriert hättest, Dein Backup umfangreich genug und Dein Restore dann erfolgreich geworden wäre. Aber wie @FSC im Posting #2 bereits schrieb (Stichwort: NAS Konfig), bringt ein (direktes) Restore nichts, wenn gleichzeitig ein Wechsel des RAID-Levels durchgeführt wurde. Habe zwar schonmal eine solche Sicherung durchgeführt aber noch nicht zurückgespielt. Daher weiß ich noch nicht, in wie weit es möglich ist, nur Teile (manuell) zurückzusichern. Wenn ich Deine Postings gelesen habe, traue ich Dir auch solche Wege zu.


    Deine erste Idee (Plan 3.1- 3.5) aus Deinem 1.Posting diesen Beitrags ist ja vernünftig, wobei ich nicht weiß, unter welchen Randbedingungen ein Wechsel von RAID6 nach RAID5 (ohne Umwege) funktionieren kann. Es fehlte noch der Abschnitt mit Vollbackup in Deinem Plan. Und nachdem Du das Erweiterungsgehäuse hattest, wäre noch eine Variation zur ersten Idee möglich geworden, mit neuen Festplatten (ohne alte) neu aufsetzen, anschließend alte einsetzen und dann kopieren, aber ebenfalls mit Vollbackup und Systemsicherung.


    Habe gerade erst gelesen, dass Du auch Erfahrung mit OpenBSD hast. Da dürfte ja auch die Vielfalt an Dateisystemen enthalten sein, die mit dem letzten Update von BSD heraus kam. Überblicke nicht, welche davon Jahre später auch in Linux Einzug gehalten haben, und welche nicht. Dies hätte Dir eventuell auch noch Optionen eröffnet. Kenne dieses Werkzeug xmount nicht. Aber es scheint wohl nicht so flexibel zu sein, wie die Vielfalt, die BSD der Welt beschert hat, und in OpenBSD übernommen sein sollte. In dem von Dir referenzierten Beitrag zu xmount wird auch Knoppix erwähnt. Dieses arbeitet mit seinem eigenen Treiber cloop (Open Source) für Overlays. Kann sein, dass dies etwas einfacher ist als die Teilschritte mit xmount. Kennst Du eine Aufstellung zu den Unterschieden zwischen Loop-Device unter Linux und Union-Dateisystem unter BSD (samt seinen Nachfolgern)?

    Einmal editiert, zuletzt von chef1 () aus folgendem Grund: Ergänzung um Abschnitt zu BSD, OpenBSD und Knoppix.