Gzrecover sur une grosse archive

Bonjour,
Suite à une panne sur mon serveur, et une boulette de qualité sur le backup, j’ai dû faire une recupération de partition via testdisk.
5h plus tard, miracle j’ai ma partition (j’y croyais plus après un formatage). Je compresse/upload ma /home (environ 15go), l’archive en fait 7,5go.

De retour en mode normal, je décompresse comme par hasard, archive corrompue… Bon ça vient peut-être du transfert, je re-dl l’archive c’est toujours pas mieux.
Sauf que cette fois-ci testdisk ne trouve plus rien, je n’ai que mon home.tar.gz pour pleurer.
J’ai donc lancer gzrecover, voilà maintenant 3h que ça tourne… pour un super résultat:

...
Found error at byte 1048015 in input stream
Found good data at byte 1048015 in input stream
Premature end of stream at 1052696
Erreur de segmentation

Si quelqu’un aurait un retour d’expérience ou d’autres astuces sur une grosse archive corrompue ça me serait de la plus grand aide :frowning:

À sauvegarde pourrie restauration pourrie …
gzrecover fera un peu comme ddrescue, il sautera les éléments manquants sans se bloquer, il ne permettra toutefois pas de restaurer des éléments hors de sa portée.

Acharnement thérapeutique

Quelle boulette ?

S’agit-il de /home que testdisk vient de rétablir ou d’une ancienne sauvegarde ?
nature :
$ file sauvegarde.tgz

C’est quoi “mode normal” ? mode graphique à la souris ?
“Je décompresse” , quelle commande exacte s’il te plait ?

Tu nous dis que testdisk avait récupéré la partition, comment se fait-il qu’une archive tar+gzip décompressée puisse l’effacer ?
Ta sauvegarde était la compression d’une partition par dd et la restauration
s’est faite par une redirection à la $ gunzip > /dev/sd?? ?
Tu procèdes sur des disques de machines virtuelles ?

Dis nous en plus , montre nous explicitement tes commandes et décris nous le contexte d’origine et la procédure de restauration.

Si tu restaures directement sur les disques, l’alternative prudente (et dispendieuse en espace disque) serait
de restaurer sur fichiers à la
$ tar xvz sauvegarde.tgz > fichier
puis de monter “fichier” en loop pour tester.

A la base je voulais installer squeeze, le backup journalier venait de se terminer sans soucis apparent et plutôt débordé par le travail j’ai lancer l’installation.

Et c’est en me connectant au ftp pour recup les backups que je découvre que ma home n’a pas été up. :075
je me suis pas inquiéter de l’espace disponible sur le ftp de backup, backup-manager ne nettoyait pas les sauvegardes antérieures, bref je me suis retrouver avec une home vielle d’un mois (!) tandis que les autres répertoires et bases de données sont nettoyés et up correctement…

testdisk a rétabli la partition entière, j’ai compresser /home (tar -cf…) puis up sur le ftp pour être sûr d’avoir une copie.

Étant donner que testdisk a écraser l’installation fraiche de squeeze, j’ai donc dû réinstaller. Suivi de la restauration (tar -zxvf) qui ne fonctionne pas, l’archive est corrompue.
Après plusieurs tentative de re-téléchargement/décompression, ça échoue toujours au même byte.
donc je re-scan avec testdisk pour re-up ma home mais il ne trouve plus la partition.

Si je comprend bien tu as installé par dessus une vieille installation, ce faisant tu as effacé l’ancien partitionnement puis l’as récupérée par testdisk pour à nouveau l’effacer et tu veux maintenant retrouver le partitionnement d’origine ?

Plus tu fais/défais les partitions plus ce sera difficile pour testdisk.
Il y a malgré tout un espoir, insister sur testdisk.“search deeper”.

Pour tes données compressées, gzrecover fera son possible rien de plus. (“À l’impossible nul n’est tenu”).

Un tar de /home est indépendant de la partition .
Faire un tar de /home c’est compresser les données qui s’y trouvent, rien à voir avec
la partition (table des partitions,primaire/étendue, fs, blocs n° X, fragmentation … ne sont pas contenus dans /home mais le périphérique /dev/sd??).

Comment tu passes de la sauvegarde des données de /home en tar à l’effacement/restauration de la partition /dev/sd?? ? Tu utilises tar couplé à partimage/dd ?
Tu rediriges (>)la sortie de tar ou gunzip vers un périphérique de bloc (/dev/sd??) ?

Montre nous les commandes intégrales de création d’archive et de restauration.

[quote]
Comment tu passes de la sauvegarde des données de /home en tar à l’effacement/restauration de la partition /dev/sd?? ? Tu utilises tar couplé à partimage/dd ?[/quote]

/home n’est pas une partition,
j’ai juste fait un banal tar -czf home.tar.gz pour le recuperer via tar -zxvf.

voilà 3 testdisk en search deeper et toujours rien à l’horizon, idem pour gzrecover.

Bon l’essentiel dans l’histoire c’est que j’ai pu récupérer mes mails (le plus important). Le reste n’est que configuration en masse…

OK, laissons donc de coté le partitionnement, testdisk et les périphériques.

Tu laisses tourner gzrecover en lui ayant spécifié un fichier en sortie (option -o)

$ gzrecover archive.tgz -o archive.tar

Tu détares le fichier (pas besoin de l’option z, gzrecover l’a fait précédemment)

$ tar xvf archive.tar

c’est en route, mais mes dernières tentatives se sont terminées par un segfault de gzrecover

edit: j’ai le même segfault que dans mon premier post

l’archive de destination se remplie jusqu’à 2,8go ensuite j’ai les “found error” “found good data” pendant + de 2 heures puis segfault

Je pense que l’archive est vraiment HS