Récupérer des trucs depuis un tar.gz corrompu

Bonjour, aujourd'hui c'est une triste nouvelle qui me fait écrire ce post.

En effet, j'ai perdu des photos. Je m'explique : je prends régulièrement plein de photos, et arrive forcément un moment où il faut penser à backuper tout ça. J'aime pas trop payer ni filer gratuitement mes photos ni les programmes/sites web qui appartiennent à des entreprises de pub, alors j'utilise un disque dur à la maison, et mon ordi (on a déjà 2 supports sur les 3 de la règle, mais ils sont stockés quasiment au même endroit, je me dis qu'au pire j'en perds un sur les deux et ça va aller).

Copier des fichiers entre mon ordi et le disque dur se révèle être atrocement long (on parle de plusieurs heures pour copier 30k photos plus ou moins triées (200-300 photos par dossier).

Pour améliorer un peu tout ça, j'ai décidé tout seul comme un grand (et sans réfléchir) de compresser mes dossiers par année, puis de les copier comme ça sur mon disque dur externe.

Récemment je me suis dit que j'allais remettre un peu d'ordre dans tout ça, et lancer un ptit jpegoptim sur mes vieilles photos (j'avais à l'époque un galaxy S 5 un peu pété au niveau du focus, j'ai des milliers de photos floues qui pèsent 5Mo chacune, et j'ai jamais pris le temps de tout trier).

Du coup j'allume mon ordi, et je lance une extraction de tous les dossiers (correspondant aux années 2008 à 2018). Tout se passe bien, tout prend 50 ans, je passe à autre chose, pis je reviens quelques heures plus tard.

Je vois tous mes dossiers, je décide de supprimer les archives pour économiser de la place (on parle de plus de 50 Go qui sont arrivés d'un coup sur mon ordi là), mais avant ça je vérifie bien les noms des dossiers ;

Okay pour 2008, 2009, 2010, 2011, 2012, 2013, 2015, 2016, 2017, 2018.

Vous l'avez ? Il manque 2014.

Je me dis "oué j'ai du oublier, allez je relance, heureusement que j'ai pas supprimé l'archive ahah sinon j'aurais du aller la chercher sur mon dde et ça aurait pris 50 ans", et je relance l'extraction.

tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

Oh.

Les problèmes

J'ai un petit problème, mon archive semble corrompue, et seuls quelques mois ont pu être extraits.

Je me dis "okay c'est pas grave j'ai mon dde bon ça va prendre des heures à copier mais bon osef à ce niveau allez je branche", et je branche mon disque dur externe.

La led s'allume, ne clignotte pas, le disque se met à tourner, puis c'est tout. Pas de nouveau périphérique de stockage détecté dans le gestionnaire de fichier de Xubuntu, rien dans gparted, et j'ai la flemme d'aller me renseigner sur les commandes style lsusb pour savoir ce qu'il faut que je cherche.

Le dde est hors d'usage, d'accord. Je cherche comment réparer mon souci avec l'archive sur mon ordi, ça doit pas être trop dur à réparer, au pire je perds une photo ou deux.

J'ai utilisé tar.gz. Ça utilise l'ensemble des données précédentes pour compresser la suite (oué comme la blockchain oué), du coup s'il manque un maillon au milieu impossible de suivre et de trouver le reste (enfin c'est ça que j'ai compris des explications glânées sur stackoverflow). Alors que zip yaurait eu aucun problème, il compresse chaque objet un à un, pas de liaison, pas de grosse merdasse si une erreur de copie arrive.

Une solution ?

Alors je cherche un peu plus comment je pourrais faire pour récupérer un maximum de données de cette archive. Je tombe sur ce magnifique post, qui au final se révèle assez cryptique pour un néophyte comme moi, et les commandes que j'y lis ne font pas grand chose, à part afficher un petit texte rigolo dans le même style que celui du dessus.

Une autre solution ?

Je tombe sur le repo de gzrt, qui se présente de la sorte :

gzrecover - Recover data from a corrupted gzip file

Jle sens bien. Je clone le repo, j'utilise la magnifique commande make dans le dossier et ça me build un exécutable en moins d'une seconde (j'avais déjà zlib sur l'ordi, pas besoin d'installer la dépendance :P), et je lance la commande :

$ git clone https://github.com/arenn/gzrt.git
$ cd gzrt && make
$ cd ..  && ls
2014.tar.gz  gzrt
$ ./gzrt/gzrecover -o aaa 2014.tar.gz
$ ls
2014.tar.gz  aaa  gzrt
$ file aaa
aaa: POSIX tar archive (GNU)

J'essaye d'ouvrir l'archive en utilisant Engrampa (le truc par défaut pour gérer les archives sur Xubuntu) :

tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

Heureusement je suis pas une bille moi, j'ai lu presque tout le readme, et cette partie a attiré mon attention :

If your .gz file is a tar archive, it is likely the recovered file cannot
be processed by the tar program because tar will choke on any errors in 
the file format. Fortunately, GNU cpio will extract tar files and will
skip any corrupted bytes.
[...]
To extract files, use the following cpio options:

cpio -F <filename from gzrecover output> -i -v

Okay, je lance cpio sur mon fichier :

$ cpio -F aaa -i -v
2014
2014/11 - novembre
2014/11 - novembre/2014-11-02 15.25.50.jpg
2014/11 - novembre/2014-11-11 18.53.27.jpg

Ça commence à chier des noms de fichiers, c'est bon signe ça non ?

Pis ça commence à ramouiller sur février. Puis ça se relance, et ça extrait décembre. Puis ça s'arrête quelques secondes, puis ça reprend sur janvier.

C'est flippant, je sais pas du tout comment fonctionne cpio. Après dans le readme de gzrt la personne a indiqué clairement que cpio risquait de galérer un peu parfois et que c'était normal.

Je prends mon mal en patience, et je m'attèle à copier/coller la partie suivante :

2014/01 - janvier/2014-01-02 01.02.12.png
2014/01 - janvier/2014-01-24 18.12.36.jpg
2014/03 - mars
2014/03 - mars/2014-03-15 18.22.27.jpg
2014/03 - mars/2014-03-08 16.25.29.jpg
2014/03 - mars/2014-03-05 11.57.29.jpg
[...]
2014/03 - mars/2014-03-05 12.10.30.jpg
2014/04 - avril
2014/04 - avril/2014-04-25 15.17.11.jpg
2014/04 - avril/2014-04-25 15.17.06.jpg
[...]
2014/04 - avril/2014-04-30 17.27.00.jpg
2014/04 - avril/soiree_xxx
2014/04 - avril/soiree_xxx/2014-04-13 00.14.46-2.jpg
[...]
2014/04 - avril/2014-04-28 14.18.20.jpg
2014/04 - avril/2014-04-25 15.15.46.jpg
2014/09 - septembre
2014/09 - septembre/2014-09-25 00.59.42.png
2014/09 - septembre/2014-09-06 12.07.42.jpg
[...]
2014/09 - septembre/2014-09-09 10.16.55.png
2014/07 - juillet
2014/07 - juillet/2014-07-11 20.53.48.jpg
[...]
2014/07 - juillet/2014-07-24 16.13.52.jpg
2014/06 - juin
2014/06 - juin/2014-06-03 06.55.01.jpg
[...]
2014/06 - juin/2014-06-14 17.01.07.png
2014/08 - aout
2014/08 - aout/2014-08-24 13.31.15.jpg
[...]
2014/08 - aout/2014-08-24 10.53.07.jpg
2014/08 - aout/la lance aout 2014
2014/08 - aout/la lance aout 2014/2014-08-24 13.31.15.jpg
[...]
2014/08 - aout/2014-08-24 10.52.58.jpg
2014/08 - aout/2014-08-24 13.31.08.jpg
cpio: fin de fichier prématurée

Flûte !

Je regarde quand même au cas où...

Comment ça s'est fini

J'ai presque tous mes dossiers, il manque 05 - mai. J'ai plein de photos dans les dossiers qui existent.

Pris d'un doute affreux, je retourne dans mon dossier 2014 (le premier, celui où j'ai eu l'erreur qui m'a fait flipper).

La même chose, plein de fichiers, tous mes dossiers sauf mai.

Je réalise soudain que j'avais ouvert mon explorateur de fichiers dans le dossier lorsqu'il était en cours d'extraction, ce qui avait affiché les dossiers présents à ce moment là.

Ensuite j'étais parti vaquer à mes occupation, puis lorsque j'étais revenu j'avais trouvé l'erreur et j'avais vu les 3 ou 4 dossiers dans l'explorateur de fichiers, et j'ai pris peur, et je me suis lancé dans la tentative de récupération de mes fichiers. Sans recharger l'explorateur de fichiers afin qu'il montre le contenu du dossier.

Du coup ya une fin prématurée et une vraie erreur, et je sais pas s'il me manque des fichiers ailleurs, mais ça me gène beaucoup moins d'avoir perdu quelques fichiers pour un seul mois plutôt que plusieurs centaines (voire milliers) sur une année complète.

Ma conclusion est la suivante : ne faites pas comme moi, vérifiez bien qu'il y a un vrai problème au lieu d'en inventer des fictifs !