Block Storage impossible à remonter après augmentation de capacité

[MaxenceC11]

Bonjour à tous,

J'ai entre autres une instance public cloud B2 Linux avec un disque additionnel "Block Storage" de 250 Go.
Jusque là, pas de problème ;-)

Il y a 2 jours le disque est arrivé à saturation et j'ai donc naturellement eu la bonne idée de vouloir en augmenter la capacité.
C'est là que les problèmes commencent...

Comme un bon petit soldat j'ai suivi les instructions suivantes : https://docs.ovh.com/fr/public-cloud/augmenter-la-taille-dun-disque-supplementaire
Le disque a bien été repartitionné mais la vérification "sudo e2fsck -f /dev/sdb1" renvoie une l'erreur suivante :
e2fsck 1.44.5 (15-Dec-2018)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1
[...]

La commande "e2fsck" a été testée sur tous les superblocks identifiés via "mke2fs -n /dev/sdb", sans plus de succès.
Du coup, impossible à présent de monter le disque !!

J'ai identifié que lors du montage initial du disque dur, il n'avait pas été partionné par fdisk mais par le biais de parted.
Je ne sais pas si cela peut expliquer le dysfonctionnement actuel...

Il ne s'agit que d'un disque dur de stockage (mais bien entendu tout son contenu n'a pas été sauvegardé). J'ai fait un snapshot mais je doute que cela serve à quoi que ce soit.

HELP !!

Merci beaucoup par avance pour votre aide !

[FabL]

Bonjour @MaxenceC11,

Avez-vous trouvé une solution à votre problématique ?

Si c'est le cas, je vous invite à la partager avec la communauté afin d'en faire profiter le plus grand monde. Dans le cas contraire, je vous inviterai dans ce cas à partager les tests effectués depuis afin que les membres puissent vous faire un retour.

Hello @Jalinn 👋, as-tu déjà été confronté à cette situation ?

^FabL

[Jalinn]

Salut @FabL et @MaxenceC11.

J'ai eu ce type de cas il y a un petit moment oui.
En gros, c'est très certainement un fail lors du repartionnement du FS...

Dans mon cas j'avais fais des backup avant, donc je ne me suis pas trop pris la tête et j'ai directement restore mes data !
Faudrais voir ce que disent les log systeme et autre, mais a mon avis, c'est mort :/

Je crois que je ne rappellerais jamais assez qu'il faut absolument faire des backup AVANT toute manip sur les filesystem... car une fois tout peter, ça peut être ultra complexe (voir impossible) de revenir en arriere !

Jalinn

[FabL]

Merci beaucoup pour ton retour @Jalinn !

@MaxenceC11, j'espère que cette réponse vous permettra d'avancer dans vos investigations.

Bonne journée à vous deux,

^FabL

[MaxenceC11]

Bonjour @FabL, @Jalinn,

Merci pour vos réponses !
Je suis désolé, je n'ai eu une notification de réponse qu'aujourd'hui ;-(

J'ai réglé en effet mon problème, mais clairement pas avec l'aide du support OVH...
Au moment où j'ai compris que tout commençait à devenir critique et que le Filesystem était complètement corrompu, avant d'aller plus loin, j'ai tout de même fait un Snapshot du disque en question.

Sur ce Snapshot, un scan via testdisk a montré que testdisk était en mesure de trouver des fichiers.

Puis (avec l'aide d'un ami qui maîtrise beaucoup mieux que moi ;-)), nous avons (en mode rescue) :
* Reformaté puis remonté le disque défectueux
* Monté le Snapshot sur la même VM
* Restauré via testdisk toujours (en excluant les fichiers cachés / effacés) les fichiers perdus depuis le snapshot vers le disque nouvellement formaté

Voilà !
J'espère que cette mésaventure pourra en aider d'autres mais, si vous arrivez là... c'est que peut être il est déjà trop tard.