Vous n'êtes pas identifié.
Un merveilleux w-end ensoleillé qui passe... une magnifique occasion de sortir, admirer les montagnes qui surplombent le lac, les petits oiseaux qui gazouillent... fort bucolique tout ca.
Hélas, tout ceci n'est pas pour le geek qui je suis, venant de passer mon week-end enfermé, pianotant frénétiquement sur mon petit clavier pour essayer de terminer dans les temps ce maudit article sur la sécurité informatique que j'avais accepté d'écrire, et non les délais n'attendent pas, et oui c'est urgent, il faut le terminer pour lundi. Youpie.
Ce dimanche, j'ai cru voir la lumière au bout du tunnel.. toutes les corrections terminées après des heures de bouffage de LaTeX, les jolis diagrammes xfig tout propres tous jolis... pour une fois, j'allais terminer un travail dans le délai imparti, soirée tranquille en perspective avec ma geekette... j'étais un geek heureux.
Hélas, c'était sans compter l'esprit tordu et malade des auteurs de GNU tar....
Satisfait de mon travail terminé, mes doigts guidés par un long conditionnement linuxien composent rapidement la commande habituelle
qui va transformer le fruit de mes efforts en joli fichier prêt a être mailé.
tar cvzf Fichier_super_important.tex Figure*.eps
Et voila, une belle petite archive que je vais pouvoir envoyer tranquilou a l'éditeur. Travail terminé.
Oops...
Ai-je oublié de donner a tar le nom de l'archive de destination ?
Oui.
Tar a-t-il remarqué que le premier argument, supposément le nom de l'archive, ne contenait pas de ".tar" ?
Non.
Tar a-t-il remarqué que le fichier existait déja ?
Non.
Tar a-t-il joyeusement écrasé la dernière version de mon article peiniblement écrit par une archive incomplète ?
Evidemment, il s'appelle tar !
JE DETESTE TAR !!!
Hors ligne
Règle 1 : pour les documents importants, faire des sauvegardes. Beaucoup, souvent, partout. Et lire la règle 2.
Règle 2 : lire la règle 1.
C'est super pas chouette pour toi. C'est même extra-chiant. Les auteurs de tar mériteraient d'être pendus. Mais que ça serve de leçon à tout le monde : faites des backups !
Hors ligne
Règle 1 : pour les documents importants, faire des sauvegardes. Beaucoup, souvent, partout. !
...
Et les sauvegardes, tu les fait avec.... ? aaaargh.
/me prend tar, le pend par les pieds et le trempe dans une marmite d'huile bouillante, et le mange avec de la sauce bourguignone
Hors ligne
J'étais trop crevé pour poster hier soir, mais j'ai pu tout récupérer ! Petit howto pour ceux que ca intéresse:
1) Dès constatation de l'erreur:
mount / -o remount,ro ; sync ; sync
suivi d'un power-off matériel
2) Boot sur un livecd approprié (j'ai utilisé un CD d'install gentoo). J'avais une box juste a côté avec plein d'espace libre, donc j'ai fait une image de ma partition pour pouvoir travailler dessus, histoire que tout soit pas perdu en cas de crash:
dd if=/dev/hda6 |ssh 192.168.1.2 'cat >disk_image'
3) Essai d'utilisation d'un outil de récupération, en l'occurence reiserfsck puisque j'utilise reiserfs. On monte l'image en loopback :
losetup /dev/lo0 disk_image reiserfsck --rebuild-tree -S -l recovery.log /dev/lo0
Pas de bol, ca donne rien... alors allons-y bourrin. On démonte:
losetup -d /dev/lo0
Je cherche un fichier texte d'a peu près 20ko, soit environ 5 blocs (la taille de bloc par défaut de reiserfs est de 4ko). Jouable.
Je cherche un éditeur hexadécimal qui puisse faire des recherches, qui gère les gros fichiers (mon image fait 20Go), qui ne demande pas d'interface graphique, et qui soit utilisable depuis mon livecd. Je n'en trouve pas. Tant pis, on y va bourrin:
4) J'utilise grep en mode binaire pour rechercher un mot clef de mon texte (en l'occurence le début du chapitre TeX. -a pour forcer grep a ignorer le fait que le fichier est binaire, et -b pour afficher l'offset de l'occurence:
grep -ab 'begin{Chapitre 7: blahblah truc}' 1234567:begin{Chapitre 7: blahblah truc}
5) un petit coup de bc (calculatrice en mode texte) pour diviser l'offset par 512 (taille d'un bloc par défaut pour les block devices), dans mon exemple: 2411.
reiserfs fait des blocs de 4k, je décide de prendre un fragment de 8k de données, soit 16 blocs de 512, en prenant un bloc d'avance par rapport a mon début de chapitre. Ca sera assez petit pour être exploré a la main:
6)
dd if=disk_image of=fragment-1 skip=2410 count=16
7)
vim fragment-1
et copier-coller pour ne récupérer que la partie qui mintéresse, et retour au 4 pour les morceaux qui manquent, jusqu'a ce que tout soit complet.
PS: c'est pas moulte intéressant comme texte... ca parle de l'implémentation des mots de passe (hashing, salting, attaques dictionnaire, tradeoffs temps-mémoire, OTPs) mais ca s'adresse plutôt a des étudiants en premier cycle d'informatique... [/list][/list]
Hors ligne
Et les sauvegardes, tu les fait avec.... ?
Pour un cas comme ça :
cp mon_fichier_sur_disque1 mon_fichier_sur_disque 2
et si c'est vraiment important, encore 1 copie sur ftp, et pourquoi pas sur cd 8-)
Hors ligne
Merci pour la marche à suivre de la restauration.
intéressant
Hors ligne
BOFH a écrit:
Je cherche un éditeur hexadécimal qui puisse faire des recherches, qui gère les gros fichiers (mon image fait 20Go), qui ne demande pas d'interface graphique, et qui soit utilisable depuis mon livecd. Je n'en trouve pas. Tant pis, on y va bourrin:
hd (hexdump) combiné avec grep.
Hors ligne