Time Machine

Il avait tout perdu : ses musiques, ses films, ses données. Bref tout. Son système de sauvegarde l’avait abandonné. Son système de réplication de données basé sur un DLink 320 était tombé. Plus rien ne pouvait en être tiré. Brancher les disques sur un PC : rien. Forcer le montage de disque à la main : rien. Tout ce à quoi il pensa ne fut qu’échec sur échec.

Alors il était perdu, sans vie numérique, sans souvenirs. Car au-delà de sa musique retéléchargeable, de ses vidéos qu’ils pouvaient revoir sur YouTube, il avait surtout perdu ses photos et les Raw de celles-ci. Il y avait bien Flickr, mais tout n’y était pas. Alors il erra dans les rues et les avenues, pensant à une solution.

Il en parla à son ami Qwant qui lui répondit : « Il y a bien Photorec. Essaye. » Alors il se dit : « Mmmmm, pourquoi pas ».

Photorec

PhotoRec est un logiciel libre de récupération de données conçu pour récupérer les fichiers perdus des mémoires des appareils-photo numériques (dixit Wikipédia). Pas mal, se disait-il. Justement ce dont il avait besoin. Alors il acheta sur Amazon un boitier externe. Il attendit pour le recevoir et le brancha à son second Raspberry. Et après s’être connecté en SSH :

sudo apt-get install testdisk.

Et puis il lut sur le site le tutoriel :

« Donc d’abord un sudo testdisk et puis un photo… Oh ! il y a un mode parano :-D. Lançons-le ». Et il le lança. Après quelques écrans, le logiciel commença à récupérer les données. Cela prit longtemps, très longtemps, trop longtemps. Il y avait des milliards de clusters sur le disque dur et le logiciel les vérifiait un à un. Il y en avait pour des jours. Alors il trouva une autre technique. Quelques recherches plus tard, il apprit qu’il existait un logiciel nommé nohup et ce logiciel n’avait qu’une seule utilité : que l’utilisateur ne regarde pas dans les yeux le programme. Alors il l’utilisa avec Photorec et plein de paramètres.

sudo nohup Photorec/log/debug/d /media/Disk1/Recovery/2/cmd/dev/sdb wholespace, options, keep_corrupted_file, 2, search &

Le plus important dans tout cela, c’était le 2 : cela représentait la partition sur le disque. Celle que l’application testdisk lui a donnée, celle où toute sa vie était. Il n’y avait plus qu’à attendre et sa vie serait de retour.

1 semaine, deux semaines. Quelque chose clochait. En allant voir dans le log (cat nohup.log), les mêmes chiffres tournaient en rond. Les clusters allant de 4 888 888… à 510… étaient parcourus en boucle. Pourquoi ? Impossible de le savoir. Ses recherches furent infructueuses. Il dut se résigner à demander sur le forum officiel. Et la réponse fut cinglante, pas la bonne version. « Bon ! ben si c’est juste un problème de version… ».

Pour mettre à jour, quelques lignes suffisaient

wget https://www.cgsecurity.org/testdisk-7.1-WIP.tar.bz2

tar jxf testdisk-7.1-WIP.tar.bz2

sudo apt install build-essential e2fslibs-dev libncurses5-dev libncursesw5-dev ntfs-3g-dev libjpeg-dev uuid-dev zlib1g-dev qtbase5-dev qttools5-dev-tools pkg-config dh-autoreconf

cd testdisk-7.1-WIP/

./configure && make && sudo make install

Puis, il relança et même chose. Après des jours et des jours, Photorec s’arrêtait toujours à un tiers. Alors « Tanpis » se disait-il. Au moins, il avait déjà récupéré un tiers. Mais comment faire pour que cela ne se reproduise plus ? Comment faire pour que cela ne se reproduise plus ? Alors il se mit à rechercher une solution.

NextCloud, WebDav et TimeMachine.

Il se renseigna, longuement. Il essaya beaucoup de choses, mais peu fonctionnèrent. Puis quelque chose lui trottait en tête. Comment faire pour éviter un cryptovirus ? Il fallait un moyen de récupérer les données de NextCloud sans que le serveur soit au courant. Chez lui, c’était comme cela.
export

  • Deux Raspberry
    • Le serveur NextCloud (avec une mémoire de 128 G)
    • Kodi et Rétropie qui sont sur un Raspberry sur lequel sont connectés les deux disques durs de 1 T.
  • Tous les deux sont connectés à mon boitier.
  • Mon nom de domaine redirige vers le serveur NextCloud.
  • NextCloud n’a accès qu’à un des deux disques durs (via le réseau). Celui où il y a la musique, les films, etc.

Il voulait que la solution soit la suivante. Retropie se connecte à NextCloud d’une façon ou d’une autre et sauvegarde le tout sur le second disque dur. Alors il essaya tout ce qui était possible.

  • Owncloud-client-cmd : était un outil en ligne de commande
  • WebDav permet d’accéder aux données via un dossier monté à travers le réseau.

Mais deux choses ne lui plaisaient pas dans ces solutions.

  1. Il fallait passer par internet. Impossible de mettre une adresse interne (192 178 168…). Principalement un problème de certificat de sécurité.
  2. Une fois cela fait, il fallait faire la gestion des sauvegardes.

Car oui, une fois monté (ou bien rapatrié), il fallait encore sauver les données sur le disque dur (ça, c’était facile) et gérer les sauvegardes. Combien faut-il en faire ? (une par jour, une par semaine, une par mois), fallait-il faire des complètes ou bien des deltas ? Sans parler de RSYNC. Il sentait que cela serait compliqué, vraiment. Il y avait bien quelqu’un qui avait déjà pensé à cela. Non ? Un logiciel qui permettrait de faire automatiquement des sauvegardes et qui permettrait facilement de retourner dans le temps en cas de problème. Le temps ? « Ah oui, la TimeMachine d’Apple. » Se disait-il ? Depuis qu’il avait un MacBook pro. Comment cela fonctionnait-il ?

Un petit tour sur internet et déception. Il faut qu’un disque dur soit connecté. « C’est con comme truc. » Se disait-il. Pourquoi ne pas le faire via le réseau ? Ses disques durs étaient accessibles via Sierra. Où était le problème bon Dieu ?

Il y avait en fait moyen, mais c’était plus compliqué que prévu. La version dans l’App Store qui permettait de faire cela n’était pas à jour, mais bon nombre de sites tel celui-ci, expliquaient comment faire pour recompiler la toute dernière version.

« Allez, essayons », se dit-il en tapant ce qui suit.

mkdir code
cd code
git clone git://git.code.sf.net/p/netatalk/code netatalk
cd netatalk

Jusque là, tout allait bien.

sudo apt-get install build-essential \
libevent-dev \
libssl-dev \
libgcrypt11-dev \
libkrb5-dev \
libpam0g-dev \
libwrap0-dev \
libdb-dev \
libtdb-dev \
libmysqlclient-dev \
libavahi-client-dev \
libacl1-dev \
libldap2-dev \
libcrack2-dev \
systemtap-sdt-dev \
libdbus-1-dev \
libdbus-glib-1-dev \
libglib2.0-dev \
tracker \
libtracker-sparql-0.14-dev \
libtracker-miner-0.14-dev \
bison \
avahi-daemon

Et merde. « Aucun track, lib tracker, dans les dépôts » pensa-t-il. Et Qwant ne dit rien à ce propos. Il décida d’enlever toutes les lignes qui contenaient le mot tracker avant de relancer la commande. Cela marchait qu’elle était les conséquences.

Il continua quand même, mais le bootstrap non plus ne voulut passer. Un certain LIBTOOL était aux abonnés absents. En cherchant un peu, il fallait aller dans le fichier bootstrap lui-même et changer à la ligne 13 le

lib tool -- version.

par

libtoolize --version

Et là miracle. Tout marcha. Le Bootstrap, le./Configure, le make et le make install. Il y avait plus qu’à tout configurer les fichiers et tout lancer.

Il eut quand même à redémarrer son serveur (avec la peur au ventre, car la connexion SSH mit un certain… longtemps,… à venir.) Mais là miracle. Dans Sierra/Finder, un Screen Shot 2017-08-30 at 21.18.19.png apparu.

System Preference, TimeMachine et hop, c’était parti pour 20 heures et 67 Gigas. Quoi ? 67 Gigas ? qu’avait-il là dedans ? De la magie. Ou presque.

En conclusion, il avait retrouvé un peu le sourire, se sachant plus ou moins protégé contre les futures pertes.

 

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s