1 juil. 2019

Retour d'expérience sur la récente indisponibilité

Lire la suite...

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).

21 déc. 2017

rsnpashot, le robot de sauvegarde

Lire la suite...

Suite au commentaire de Xate dans un récent billet, aujourd'hui un billet sur rsnapshot, un logiciel de sauvegarde incrémentale basé sur rsync. Si j'en fais un billet, c'est tout simplement car c'est ce que j'ai mis en place pour sauvegarder mon infrastructure.

J'avoue ne pas trop savoir quoi raconter sur ce logiciel, car de nombreuses documentations existent déjà, quasiment pour chaque distribution :

Je vais donc parler de quelques points de ma configuration en particulier. La première particularité de celle-ci est que j'ai choisi d'installer rsnapshot sur une machine (en fait une jail FreeBSD sur mon NAS FreeNAS) et de l'utiliser en mode "robot de sauvegarde", c'est-à-dire qu'il va se connecter sur toutes les machines à sauvegarder via SSH pour effectuer les sauvegardes. J'y vois l'avantage que je n'ai qu'une seule configuration à modifier, et un utilisateur à configurer sur mes serveurs (accompagné, bien entendu, de sa configuration sudo et de la clé SSH).

Par exemple, pour la sauvegarde du Raspberry Pi qui fait des bulk builds :

backup rsnapshot@netpi2:/etc/                                          netpi2/         +rsync_long_args=--rsync-path='/usr/pkg/bin/sudo /usr/pkg/bin/rsync'
backup rsnapshot@netpi2:/usr/pkg/etc/                                  netpi2/         +rsync_long_args=--rsync-path='/usr/pkg/bin/sudo /usr/pkg/bin/rsync'
backup rsnapshot@netpi2:/var/log/                                      netpi2/         +rsync_long_args=--rsync-path='/usr/pkg/bin/sudo /usr/pkg/bin/rsync'
backup rsnapshot@netpi2:/srv/sandbox/pkgsrc-current/usr/pbulk/etc/     netpi2/         +rsync_long_args=--rsync-path='/usr/pkg/bin/sudo /usr/pkg/bin/rsync'

On peut aussi noter que j'ai choisi d'ajouter des options à rsync selon mes machines, car celles-ci peuvent être de différents OS, ce qui fait que rsync et sudo ne se trouvent pas toujours au même endroit.

Du côté de la rétention et des intervalles de sauvegarde, j'ai fait très simple :

  • une sauvegarde par jour (daily);
  • 370 jours de rétention.

370 jours peut sembler un peu abusé, mais la force de rsnapshot est dans son utilisation des liens (hardlinks) combinée à celle de rsync, qui rend les sauvegardes rapides, mais aussi moins consommatrices en espace disque car dédupliquées. Par exemple pour le serveur web de ce blog :

# du -csh daily.0/vhost2/ daily.1/vhost2/                                                                                                                                                                       
 17G    daily.0/vhost2/
2.3G    daily.1/vhost2/
 19G    total

La restauration se fait très simplement aussi, puisqu'il s'agit de fichiers tout ce qu'il y a de plus classiques, ou de liens.

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

Crédit photo : Ritva Pirinen - Spare Parts.

Propulsé par Dotclear