Du 30 mai au 17 juin dernier, ce blog, ainsi que d'autres sites hébergés sur ce même serveur étaient inaccessibles. C'est l'occasion de revenir sur cet incident, le pourquoi et le comment.

Résumé de l'histoire

En bref, il s'agit tout simplement d'une panne du serveur physique hébergeant mon serveur web. Celui-ci s'est arrêté, et ne restait pas allumé plus de 10 minutes sans être bloqué. Lorsque j'ai contacté mon hébergeur, le diagnostic fut sans appel : panne matérielle, il faut remplacer la machine. Mais ce n'est que le début. En effet, le modèle de serveur étant en rupture de stock, il me faut alors prendre une autre machine. Cette nouvelle machine n'est d'ailleurs pas très stable, et dans un premier temps il est envisagé de la remplacer de nouveau. J'ai fini par installer l'OS ainsi que les machines virtuelles et restaurer le contenu des sites.

Et donc, 2 semaines pour restaurer des sauvegardes ?

Pas totalement. D'abord, il s'est écoulé plusieurs jours durant la phase de diagnostic et de mise à disposition de la nouvelle machine. D'ailleurs je considère que celle-ci n'a pas l'air totalement fonctionnelle. Ensuite, il m'a fallu du temps pour réinstaller l'hyperviseur ainsi que les machines virtuelles, puis restaurer le contenu (j'en ai profité pour glisser une mise à jour de PHP). Enfin, j'ai du faire face à certains impératifs, comme mon travail, et un évènement familial (joyeux, heureusement).

La morale de l'histoire

Je retiens surtout de cette histoire que je pourrais mieux gérer mes sauvegardes. Je me concentre sur les données et les configurations, mais une sauvegarde complète de mes machines virtuelles me permettrait sans doute de gérer ce genre de désagrément plus rapidement. Ma solution de sauvegarde actuelle est rsnapshot, et suite aux recommandations d'un collègue, j'envisage Burp (à ne pas confondre avec le logiciel de sécurité).

La suite

Comme indiqué plus tôt, la nouvelle machine ne me semble pas très stable, j'ai encore eu des difficultés liées probablement au disque dur ce matin. J'espère, d'ici peu, pouvoir changer de machine.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Maxim Dužij (sans titre).

Commentaires

le 07/07/2019 11:01 par philpep

Hello,

J'utilise burp et des snapshot lvm (thin) pour mes backup, justement pour pouvoir restaurer toute la VM facilement. L'idée est de lancer un "backup_script_pre" qui crée les snapshot et monte les partitions des VM dans /mnt/bup/ sur l'hôte (un savant mélange de lvcreate, kpartx, mount).

Burp fait le backup des filesystem dans /mnt/burp/, ainsi on a un backup fichier incrémental et on peut facilement voir / restaurer un seul fichier par exemple, et vu que c'est un snapshot, ce backup est aussi valide pour les base de données type postgresql. Ensuite un "backup_script_post" qui umount, kpartx -d, lvremove le snapshot.

Pour restaurer toute une VM, j'ai juste à lvcreate, kpartx, mkfs.ext4, mount, burp -a r -b 1 -r '^/mnt/burp/' -d /mnt/, un coup de grub-install et modifier /mnt//etc/fstab et /mnt//boot/grub/grub.cfg pour changer l'UUID de la partition donné par blkid et ça démarre bien.

Une autre solution, pour restaurer encore plus simplement, serait de faire un backup du block device de la VM, burp sait le faire, même en incrémental, par contre tu perd la possibilité de restaurer simplement juste un seul fichier, répertoire.

Mon script pre/post est assez portable (supporte lvm thin et non thin et se configure via un fichier de conf), ça tourne bien sur mes debian depuis plusieurs années, si ça t'interesse je peux le partager quelque part.

Le 08/07/2019 09:37 par Nils

Merci pour ton commentaire philpep ! Bravo pour ton script, il ne me servira pas forcément pour mes machines NetBSD, mais je suis certain qu'il pourra en intéresser d'autres, alors n'hésite pas à le partager et à indiquer l'URL ici :-)

Le 15/07/2019 13:24 par philpep

Ah oui pour NetBSD ça doit être un autre filesystem et d'autres commandes.Mon script pour lvm est ici: https://philpep.org/wiki/soft:burp