Voir :

• recup_de_donnees
• https://wiki.archlinux.org/index.php/file_recovery
• monter_une_partition_d_un_disque_qui_a_ete_clone_entierement_via_dd_ou_ddrescue
• https://www.redhat.com/sysadmin/linux-delete-file-rm
• TestDisk / PhotoRec
• ext4magic, scalpel.
• ddrescue
• https://linuxfr.org/users/siltaar/journaux/apres-photorec

Voir aussi :

• notes_partition_mbr_dd

Voir aussi :

• Notes Récupération de données CD DVD

Il peut être intéressant de jeter un œil avec un éditeur hexadécimal

Si presque que des zéros partout, inutile d'aller plus loin.

strings image.dd

EFI PART
"PV6
MSDOS5.0
13hNO NAME    FAT32   3
fXfXfXfX
3f;F
f@Iu
BOOTMGR
Disk error
Press any key to restart
RRaA
rrAa
MSDOS5.0
13hNO NAME    FAT32   3
fXfXfXfX
3f;F
f@Iu
BOOTMGR
Disk error
Press any key to restart
RRaA
rrAa

Source : https://unix.stackexchange.com/questions/567849/how-to-fix-if-i-received-mount-dev-vgname-lvname-cant-read-superblock-for-th

If the logical volume exists and is active, it may be that the superblock is somehow corrupted. If the filesystem is an ext2, ext3 or ext4, there are backup superblocks available. To find them:

dumpe2fs /dev/vgname/lvname | grep superblock

You will get some output like:

$ sudo dumpe2fs /dev/sdb1 | grep superblock
dumpe2fs 1.45.4 (23-Sep-2019)
  Primary superblock at 0, Group descriptors at 1-25
  Backup superblock at 32768, Group descriptors at 32769-32793
  Backup superblock at 98304, Group descriptors at 98305-98329
  Backup superblock at 163840, Group descriptors at 163841-163865
  Backup superblock at 229376, Group descriptors at 229377-229401
  Backup superblock at 294912, Group descriptors at 294913-294937
  Backup superblock at 819200, Group descriptors at 819201-819225
  Backup superblock at 884736, Group descripmount sb=32768 /dev/sda2 /mnttors at 884737-884761

You can probably mount the filesystem with:

# the 32768 being the first backup superblock from the previous output
mount sb=32768 -o ro /dev/vgname/lvname /mnt

If that works, you can backup some important files and/or start a repair:

fsck -b 32768 /dev/vgname/lvname

You could try fsck -y if you don't want to acknowledge all repair.