OpenMediaVault, SSD, Datenrettung

[proxnewbie1]

Hallo zusammen,

bei mir war auf einem Proxmoxserver VE 7.4.19 OpenMediaVault als VM. Es waren zwei 1TB SSD eingebaut die nur OMV benutzte.
Dann ist OMV nicht mehr gestartet wenn beide SSD eingehängt sind. Wenn ich eine der beiden SSD mit detach rausnehme startet OMV wieder.

Die Daten dieser „felerhaften“ SSD habe ich dann auf einer usb Festplatte gesichert.
1. vm-104-disk-0 + vm-104-disk-0-part1
2. ddrescue -f -d /dev/sdb /mnt/pve/usb2gb/backup/sicherung.img /mnt/pve/usb2gb/backup/logdatei.log

Dann habe ich versucht diese Sicherung wieder zu mounten

A. auf meinerm zweiten Proxmox VE 8.4.1 Server zu mounten.

mount /mnt/pve/usb2gb/backup/sicherung.img /mnt/temp
mount: /mnt/temp: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.

B. mounten auf einem Linux mint PC
sudo mount /media/familie/4e47e03b-69dc-43f5-b4c3-8c1fb2a26ba9/backup/sicherung.img /mnt/temp
mount: /mnt/temp: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /dev/loop0 ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.
dmesg(1) may have more information after failed mount system call.

dmesg | tail -20
[260262.018905] usb 2-2: Manufacturer: JMicron
[260262.018910] usb 2-2: SerialNumber: 0000AB12349D
[260262.025564] scsi host3: uas
[260262.026085] scsi 3:0:0:0: Direct-Access HUH72121 2ALE601 8101 PQ: 0 ANSI: 6
[260262.028782] sd 3:0:0:0: Attached scsi generic sg1 type 0
[260272.029989] sd 3:0:0:0: [sdb] Spinning up disk...
[260275.035151] .ready
[260280.620757] sd 3:0:0:0: [sdb] 23437770752 512-byte logical blocks: (12.0 TB/10.9 TiB)
[260280.620767] sd 3:0:0:0: [sdb] 4096-byte physical blocks
[260280.621111] sd 3:0:0:0: [sdb] Write Protect is off
[260280.621119] sd 3:0:0:0: [sdb] Mode Sense: 53 00 00 08
[260280.621514] sd 3:0:0:0: [sdb] Disabling FUA
[260280.621518] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[260280.645379] sd 3:0:0:0: [sdb] Preferred minimum I/O size 4096 bytes
[260280.645395] sd 3:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)
[260280.677772] sdb: sdb1
[260280.677963] sd 3:0:0:0: [sdb] Attached SCSI disk
[260281.087978] EXT4-fs (sdb1): mounted filesystem 3028ea54-ce5d-4c33-a7f4-80c315cf186a r/w with ordered data mode. Quota mode: none.
[261812.631347] workqueue: delayed_fput hogged CPU for >13333us 32 times, consider switching to WQ_UNBOUND
[262274.957513] loop0: detected capacity change from 0 to 1953525168

Da ich mich zu wenig mit Linux auskenne kann ich mit diesen Infos nichts anfange und brauche eure Hilfe.
Wie kann ich die Daten meiner „felerhaften“ SSD wiederherstellen.
Macht es Sinn die SSD oder die Sicherung auf der USB Festplatte zu benutzen.
Und wo macht es Sinn? Auf Proxmoxserver VE 7.4.19 oder Proxmox VE 8.4.1 oder Linux Mint PC?

Liebe Grüße und ich hoffe es war verständlich.

 

[UdoB]

mount /mnt/pve/usb2gb/backup/sicherung.img /mnt/temp
mount: /mnt/temp: wrong fs type, bad option,

Die Imagedatei enthält eine Festplatte, keine einzelne Partition. Die Partitionstabelle ist daher im Weg.

Es mag verschiedene Ansätze geben, damit umzugehen. Ich verwende für so etwas:

$ apt show kpartx

Source: multipath-tools

Homepage: http://christophe.varoqui.free.fr/

Description: Erzeugt Gerätezuordnungen für Partitionen
 Kpartx kann verwendet werden, um Gerätezuordnungen für die Partitionen
 eines beliebigen partitionierten, blockorientierten Geräts zu erzeugen.
 .
 Es ist Teil der »Linux multipath-tools«, aber nützlich für jedes System,
 das einen Device Mapper verwendet.

 

[proxnewbie1]

Danke für den Hinweis. Folgendes Ergebniss.

kpartx -av /media/familie/4e47e03b-69dc-43f5-b4c3-8c1fb2a26ba9/backup/sicherung.img
add map loop0p1 (252:2): 0 1953505280 linear 7:0 2048
add map loop0p9 (252:3): 0 16384 linear 7:0 1953507328

mount /dev/mapper/loop0p1 /mnt/temp
mount: /mnt/temp: unbekannter Dateisystemtyp „zfs_member“.
dmesg(1) may have more information after failed mount system call.

mount /dev/mapper/loop0p9 /mnt/temp
mount: /mnt/temp: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /dev/mapper/loop0p9 ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.
dmesg(1) may have more information after failed mount system call.

 

[UdoB]

mount: /mnt/temp: unbekannter Dateisystemtyp „zfs_member“.

OMV verwendet ZFS? Cool!

Dann ist "zpool import" - erst ohne, und dann sicher mit Parameter nötig. man zpool-import erläutert -n / -f / -F usw. Eine man-page ist allerdings kein Tutorial, das wird du "draußen" suchen müssen.


((
Ich selber habe bisher extrem wenig Probleme mit meinen Pools gehabt, darum habe ich mit "Recovery" glücklicherweise wenig konkrete Erfahrung.
))

 

[Johannes S]

OMV verwendet ZFS? Cool!

Ja, aber nur als Plugin, dass dann die nötigen Kernelmodul mit dkms baut.
Ein Grund, warum ich als NAS dann lieber was mit nativen Support genommen habe

Ist das Plugin nicht installiert, fehlt envtl. das Kernelmodul oder die zfs Tools.