Dummer Anfängerfehler


43 posts in this topic Last Reply

Recommended Posts

Ok, ich habe nun für @Baumberger die disk.cfg so abgeändert und per PN gesendet:

cacheId="Samsung_SSD_980_PRO_1TB_xxxxx"
cacheFsType="btrfs"
cacheComment=""
cacheSpindownDelay="-1"
cacheSpinupGroup="nvme0"
cacheUUID="f4a403ee-c94c-45ec-8f94-xxxxx"
cacheExport="e"
cacheFruit="no"
cacheCaseSensitive="auto"
cacheSecurity="public"
cacheReadList=""
cacheWriteList=""
cacheVolsizelimit=""
cacheExportNFS="-"
cacheSecurityNFS="public"
cacheHostListNFS=""
cacheExportAFP="-"
cacheSecurityAFP="public"
cacheReadListAFP=""
cacheWriteListAFP=""
cacheVolsizelimitAFP=""
cacheVoldbpathAFP=""
cacheId.1="Samsung_SSD_980_PRO_1TB_xxxxx"


 

Die UUID habe von seinem blkid Ergebnis.

 

Außerdem habe ich ihn gebeten in der Datei /boot/config/ident.cfg den Wert von "SYS_CACHE_SLOTS" auf "2" zu stellen.

 

Danach soll er das Array runterfahren und schauen ob die zweite NVMe nun wieder dem 2. Slot zugeordnet wurde. Mal sehen was passiert ^^

 

Was ich leider nicht weiß wie wichtig "cacheSpinupGroup" bzw wo dieser Wert gespeichert ist. Bei meiner Recherche fand ich dort "host3", "host4", usw.

 

Link to post
6 minutes ago, Jojo1965 said:

Bitte kurze Anleitung wo ich die Datei finde... 🙈 

 

In der Disk-Übersicht ist rechts beim USB Stick ein Ordner-Icon. Da drauf klicken und du siehst die Dateien auf dem Stick. Dann zu /boot/config gehen und auf disk.cfg klicken zum Runterladen. 

Link to post
4 hours ago, mgutt said:

 

In der Disk-Übersicht ist rechts beim USB Stick ein Ordner-Icon. Da drauf klicken und du siehst die Dateien auf dem Stick. Dann zu /boot/config gehen und auf disk.cfg klicken zum Runterladen. 

Alles klaro, danke.

disk.cfg

Link to post

Ok, dann hat sich bei 6.9.0 was geändert. Vermutlich gibt es jetzt zusätzliche Config-Dateien dafür. Ok, das hilft uns aber jetzt leider nicht, weil er 6.8.3 verwendet. Warten wir also erst mal ab was sein Test ergibt.

Link to post

Hallo Jungs, heute nur ein kurzes Statement.

Leider haben die Änderungen in disk.cfg und /boot/config/ident.cfg zu keinem Erfelg geführt. Dies habe ich eigentlich auch erwartet.

image.thumb.png.59ff37c46fe11990e73074ebb1febc92.png

Wenn ich nur wüsste wie ich am besten an meine wichtigen Dateien von NVMe SSD 1 Cache gelangen kann.🤦‍♂️

Link to post
19 hours ago, mgutt said:

Ok, dann hat sich bei 6.9.0 was geändert. Vermutlich gibt es jetzt zusätzliche Config-Dateien dafür. Ok, das hilft uns aber jetzt leider nicht, weil er 6.8.3 verwendet. Warten wir also erst mal ab was sein Test ergibt.

...äh...in seinem Bild hier oben drüber ist die 6.9beta35 eingeblendet 🤐

Link to post
13 minutes ago, Baumberger said:

Leider haben die Änderungen in disk.cfg und /boot/config/ident.cfg zu keinem Erfelg geführt

 

Du musst schon mehr Input geben. Hast du damit den Server neu gestartet oder was? War die zweite MVMe bereits in dem 2. Cache Slot oder hast du sie manuell hinzugefügt?

 

Können wir sicher sein, dass die beiden in der richtigen Reihenfolge sind?

Link to post
5 minutes ago, mgutt said:

Hast du damit den Server neu gestartet oder was?

Ja

 

6 minutes ago, mgutt said:

War die zweite MVMe bereits in dem 2. Cache Slot oder hast du sie manuell hinzugefügt?

Die habe ich versucht hinzuzufügen, was aber zur Unmountbarkeit der ersten SSD geführt hat. 

Habe Dir vorhin eine PN geschickt!

Link to post

Baumberger hat mich nun offiziell beauftragt das zu regeln. Wen es interessiert: Er hat ZeroTier installiert und ich bin nun Remote mit seinem Server verbunden. Aktuell lasse ich Images von den beiden SSDs erstellen und dann versuche ich das Dateisystem zu reparieren bzw Daten dort zu retten. Wir werden sehen ob das von Erfolg geprägt sein wird ;) Aktuell setze ich meine Hoffnungen in ein btrfs check + repair bzw falls eine noch als RAID1 konfiguriert ist in eine Konvertierung in eine Single Disk. Die letzte Möglichkeit wäre eine Datenrettung mit btrfs restore.

 

Seine disk.cfg.bak war übrigens von vor dem Upgrade auf die Beta35. Die aktuelle sieht nun aus wie bei Jojo. Keine Ahnung wo die SSD Info nun bei der 6.9.0 abgespeichert wird. Das checke ich dann, wenn es soweit ist.

 

Link to post

Also ich konnte zwar eine NVMe lesend mounten und habe auch schon rsync ausgeführt, aber das Ergebnis ist ernüchternd, von 9137 Quelldateien nur 4646 übertragen wurden. Ich kann sie nicht schreibend mounten, weil ich dann diese Fehlermeldung erhalte:

writable mount is not allowed due to too many missing devices

 

Laut Dokumentation passiert das nur, wenn zB eine Disk aus einem RAID0 fehlt:

   degraded
       (default: off)

       Allow mounts with less devices than the RAID profile constraints
       require. A read-write mount (or remount) may fail when there are
       too many devices missing, for example if a stripe member is
       completely missing from RAID0.

 

Was mich erstaunt, dass trotz RAID0 trotzdem so viele Dateien verfügbar waren. Ich ging immer davon aus, dass die vollständig gestriped werden?!

 

Da die zweite NMVe bereits als einzelne Cache SSD zugewiesen worden war, hat sie kein korrektes Dateisystem mehr. Da normalerweise nur die Partitionen gelöscht bzw angelegt werden, besteht allerdings Hoffnung, dass auf der zweiten eigentlich noch alles fehlende drauf ist. Nun die Frage: Wie bekomme ich die Partion auf der zweiten wieder so hin wie sie früher waren? Dann könnte ich sie ja evtl mounten und eine Reparatur starten.

 

EDIT: Nein es muss ein RAID1 sein, aber warum kann ich nur die Hälfte der Dateien auslesen und warum kann ich das nur ro degraded mounten?!

btrfs fi df /mnt/nvme0n1p1
Data, single: total=134.00GiB, used=112.50GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=87.02MiB
GlobalReserve, single: total=78.56MiB, used=0.00B

 

Link to post

...hier stehen ein paar interessante Dinge/Befehle, welche man in der Standard Doku wohl nur schwer/nicht findet: https://ownyourbits.com/2019/03/03/how-to-recover-a-btrfs-partition/

 

Wenn Du die Disks raw mit dd erstmal gesichert hast, kannst Du ja bis zur TBW-Grenze durchprobieren...schnell genug sollten die ja sein ;-)

Ist latünrich schice sowas.

Sind die die wichtigen Daten in dem Teilbereich, den Du rausholen konntest schon dabei?

Edited by Ford Prefect
Link to post
29 minutes ago, Ford Prefect said:

Sind die die wichtigen Daten in dem Teilbereich, den Du rausholen konntest schon dabei?

Teilweise, Ordner ja, aber die Dateien in den Ordnern sind nicht vollständig. 

 

Bin so froh über die spezielle Hilfe von mgutt, er hatte echt drauf!

Link to post

@Ford Prefect

Danke. Die Befehle aus dem Link sind mir bekannt. Die Reihenfolge halte ich auch ein. scrub kann ich aber leider vergessen, weil ich nicht schreibend mounten kann. Was ich noch herausgefunden habe und was wohl durch den Wechsel auf Single passiert sein muss, dass "data" auf Single steht und nicht auf RAID1:

btrfs fi us /mnt/nvme0n1p1
Overall:
    Device size:                   1.82TiB
    Device allocated:            136.06GiB
    Device unallocated:            1.69TiB
    Device missing:              931.51GiB
    Used:                        112.67GiB
    Free (estimated):              1.71TiB      (min: 884.98GiB)
    Data ratio:                       1.00
    Metadata ratio:                   2.00
    Global reserve:               78.56MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,single: Size:134.00GiB, Used:112.50GiB (83.96%)
   /dev/nvme0n1p1         67.00GiB
   missing        67.00GiB

Metadata,RAID1: Size:1.00GiB, Used:87.02MiB (8.50%)
   /dev/nvme0n1p1          1.00GiB
   missing         1.00GiB

System,RAID1: Size:32.00MiB, Used:16.00KiB (0.05%)
   /dev/nvme0n1p1         32.00MiB
   missing        32.00MiB

Unallocated:
   /dev/nvme0n1p1        863.48GiB
   missing       863.48GiB

 

 

Und der Fehler mit der Missing Disk kommt wohl durch den erste Chunk-Fehler:

Jan 23 12:02:06 nas kernel: BTRFS warning (device nvme0n1p1): chunk 360832827392 missing 1 devices, max tolerance is 0 for writable mount
Jan 23 12:02:06 nas kernel: BTRFS warning (device nvme0n1p1): writable mount is not allowed due to too many missing devices

 

Durch rsync wurde quasi jede 2. Datei in jedem Ordner gesichert. Es ist also nicht ein Ordner vollständig wiederhergestellt worden.

 

Der nächste Versuch ist nun btrfs restore. Dummerweise kann ich dieses Kommando wohl nicht unbeaufsichtigt ausführen lassen. Das wird zwar bei manchen Seiten behauptet, aber das ist nicht der Fall, da man zwischenzeitlich Fragen beantworten muss:

btrfs restore -i /dev/nvme1n1p1 /mnt/disk2/nvme1n1p1_restore
No valid Btrfs found on /dev/nvme1n1p1
Could not open root, trying backup super
We seem to be looping a lot on /mnt/disk2/nvme1n1p1_restore/domains/Win10/vdisk1.img, do you want to keep going on ? (y/N/a)

 

Da dies aber eine unwichtige Datei ist, habe ich den restore davon abgelehnt, was den Vorgang etwas beschleunigen dürfte.

 

Wenn das durch ist, mache ich noch einen restore von der ersten SSD. Dann habe ich die erste mit rsync und btrfs restore und die zweite nur mit btrfs restore wiederhergestellt. 

 

EDIT: Ok schon fertig. Also alle Dateien wurden wiederhergestellt. Witzigerweise von der zweiten SSD, die kein gültiges Dateisystem mehr besaß. Die erste hat auch beim BTRFS Restore nur Fehler produziert. Ich habe dann abschließend mit rsync dry-run die gemountete SSD1 (konnte ich ja noch mounten) mit dem BTRFS restore von SSD2 verglichen und alle Dateien sind mit der gleichen Dateigröße noch da, nur das Dateidatum ist nicht mehr gleich. Aber damit kann man denke ich leben ;)

 

  • Like 3
  • Thanks 1
Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.