J’arrive trop tard… Il ne fallait surtout pas forcer fsck et resize2fs dans cette situation, d’après mon expérience ils ne la gèrent pas bien.
Petit rappel : on doit réduire le système de fichiers (avec resize2fs ou équivalent pour le système de fichiers considéré) avant de réduire la volume ou la partition, sinon tout le contenu de la partie tronquée devient inaccessible. Et on doit agrandir le système de fichiers après avoir agrandir le volume ou la partition, sinon l’espace supplémentaire est inutilisable.
En fait la solution était a priori simple. La sortie de df dans le message initial montre que le système de fichiers du volume var a une taille de 3 Go, donc n’a pas été agrandi. On pouvait donc espérer que les données tronquées du volume home n’avaient pas été écrasées. D’autre part je suppose que les volumes n’avaient pas déjà été redimensionnés, car lvdisplay affiche que home est contigu et un fragment et var a deux fragments (allocation initiale + agrandissement dans l’espace libéré de home). Il aurait suffi de réduire le volume var à sa taille initiale exacte, puis d’agrandir le volume home à sa taille initiale, ce qui aurait récupéré les blocs libres initiallement alloués à home, et le tour était joué.
Mais maintenant, avec l’exécution de fsck, resize2fs et lvresize dans ces conditions, je crains que tout ce qui se trouvait dans la partie tronquée du volume home soit à peu près perdu. Certains fichiers peuvent être récupérés par des outils comme photorec (paquet testdisk) à condition de ne pas être fragmentés, mais pas leurs noms ni l’arborescence.
Par contre l’arborescence et les fichiers contenus dans la partie non tronquée du volumes devraient être récupérables, en rendant au volume home sa taille initiale.
Sinon, la vraie bonne réponse était : on réinitialise le système de fichiers endommagé et on restaure la sauvegarde.
