Acte 1
Mon aventure débute le vendredi 23/11/2018, il est environ 16h et je suis au boulot, mon instance Pleroma ne répond plus, ni mes emails, blog, calendrier, contacts et tout un tas de services. La connexion SSH avec ConnectBot ne fonctionne pas. En fait, mon VPS ne répond plus du tout.
Bon, ça ne presse pas.
Je rentre du boulot, je me connecte à mon manager, je configure le boot en rescue, je force le redémarrage et j'initie la connexion SSH avec les identifiants fournis par email.
La première commande que je tape :
# fdisk -l
Mon disque /dev/sda de 30 GiB est bien présent, tout va bien.
En fait non, mes partitions /dev/sda1 à 3 ont disparues.
Je réduis et bricole un peu la sortie, mais je devrais normalement avoir ceci :
Disk /dev/sda: 30 GiB
Disk model: QEMU HARDDISK
Disklabel type: gpt
/dev/sda1 -> 190M -> /boot
/dev/sda2 -> 28G -> / (chiffré)
/dev/sda3 -> 1.9G -> linux-swap
Bon, c'est vendredi soir et je paie 2.39 € TTC par mois. Je ne suis clairement pas un client premium, mais je tente tout de même d'ouvrir un ticket à 21h.
Il est 22h, pas de réponse. C'était prévu.
Heureusement que :
- J'utilise Docker pour tous mes services
- Je sauvegarde mes données avec le formidable BorgBackup
Comme toujours, je veux maitriser mon installation, donc j'installe mon OS et je le chiffre intégralement.
Au niveau de l'hôte, je replace mes règles iptables, mes quelques crons et autres optimisations.
Soucieux du minimalisme et de l'optimisation, mes images Docker sont fabriquées par mes doigts et le plus long est le docker-compose up -d avec les multiples compilations.
Entre temps, il est 23h et j'ai une réponse à mon ticket dont je corrige les fautes par respect pour les yeux :
Bonjour,
Notre dernier backup pour ce vps date du 09/11/2018
Cordialement,
Bon écoute, non merci, ça compile et ça repart.
Acte 2
Nous sommes le dimanche 25/11/2018 à 17h20, tout est rétabli depuis longtemps, mais à nouveau, mon VPS ne répond plus.
Bordel, c'est reparti pour du rescue boot.
La première commande que je tape :
# fdisk -l
Je réduis et bricole un peu la sortie, je n'avais peut-être pas fait attention la première fois, je ne le saurais jamais, mais je constate ceci :
Disk /dev/sda: 30 GiB
Disk model: QEMU HARDDISK
Disklabel type: unknow
Unknow ? que dit TestDisk ? il voit bien mes partitions.
La suite est simple :
- Je lance
gdisk /dev/sdaet je répare ma table de partition GPT - Je réécris gptmbr.bin dans les 440 premiers octets du disque pour Syslinux
- Je déchiffre mon /dev/sda2 puis je mount et chroot le tout
Que disent les logs ? rien à part que la dernière entrée date du 09/11/2018 14:20:01, un sacré bon dans le passé.
Mais attends, 09/11/2018 ? le support m'avait dit qu'ils avaient une sauvegarde à cette date, vous restaurez 2 jours après comme ça, sans prévenir ?
Bref, je reboot, je restaure mes sauvegardes et c'est terminé (encore).
Morale
En 6 ans, il m'est arrivé à 2 reprises de perdre un disque dur, chez 2 hébergeurs différents. La première fois il s'agissait d'un dédié (ça peut arriver) et la seconde d'un VPS (étonnant non ? et pourtant). Je n'ai perdu aucune données.
- Ne faites pas confiance en vos hébergeurs, ni aux sysadmins qui pourrait avoir la curiosité d'aller voir vos données
- Chiffrer toujours votre système, que ce soit dans un datacenter ou à la maison
- Faites des sauvegardes automatisées de façon journalière