Pourquoi votre processus de backup ne vous sauvera pas (toujours)

Julien
Get news

Julien

Ingénieur de production
Backpacker quand la prod n'est pas down.
Curieux de nature, j'aime bien "faire des trucs" tech-related avec mes amis.
Si tu m'embêtes je t'automatise en Bash.
Julien
Get news

Vous savez quand est-ce qu’on commence à se soucier des sauvegardes ?

En début de projet ? Quand on construit notre infrastructure ? Presque toutes les semaines ?

Non, c’est vraiment quand on subit sa première perte de données. La multiplication des solutions de sauvegarde de fichier sur l’ordinateur de quelqu’un d’autre dans le cloud permet de minimiser la perte pour les particuliers.

Mais quand c’est le serveur de production qui casse sa pipe, comment on fait ?

Aie, c’est là que le bât blesse.

unix-1Dans le monde de la production informatique, on entend parler de sauvegarde, quoti-hebdo-mensuelle etc.
Le sujet est très « trendy ». Pour s’en rendre compte il suffit de voir le poids du marché de la sauvegarde et prochainement celui de la « reprise après sinistre » as a Service.

Mais l’impact est positif : les professionnels portent un intérêt aux sauvegardes. Ils savent que c’est un facteur clé du business.

Du coup c’est quoi le problème avec les sauvegardes ?

Souvent, dans le secteur de l’IT, on multiplie les serveurs et une problématique de volumétrie se pose. Afin de répondre à la question, certains décident de ne pas tout sauvegarder. La démarche n’est pas infondée, par exemple sur un serveur base de données, pourquoi devrait-on faire une sauvegarde totale du système, de « / » ?

Il suffirait de sauvegarder ce qui est important : le moteur de la base et les données.

Si on applique ce raisonnement sur tout le système d’information, on peut résoudre le problème de volumétrie. D’autant plus que des fichiers de configuration, ça ne prend pas beaucoup de place et ça n’a pas vocation à être modifié chaque mois …

C’est facile de dire de sauvegarder ce qui est important, comment j’identifie ces éléments ?

speaking

Dans le doute, mieux vaut tout sauvegarder, je ne le cache pas. Si vous avez des experts, exploitez-les. Ils ont souvent les mains dans le cambouis, ils auront plus d’idées que vous. D’une manière générale, communiquez, échangez avec vos collaborateurs, expliquez leur la démarche. Mais surtout, ne faites pas des sauvegardes partielles si vous ne savez pas ce que vous sauvegardez, c’est le pire cas de tous.

Mais chez moi on sauvegarde tout, régulièrement. On a un problème dans notre processus ?

Juste avec ces informations, je ne peux pas le dire. Mais la règle du pouce m’amène à dire plutôt oui.

Avoir des sauvegardes c’est super. Mais avoir des sauvegardes restaurables c’est mieux.

Restau-quoi ?

Restaurables ! Savoir si quand les problèmes arriveront (car oui, ils arriveront) la sauvegarde permet de remettre le système dans l’état pré-problème.

cat
Vous connaissez l’expérience de Schrödinger ? Si non : résumé.

 

On peut faire un parallèle avec nos sauvegardes et leur état de vie ou de mort : on ne saura si une sauvegarde est restaurable ou non que lorsqu’on la testera, quand on regardera ce qu’il y a dans la boite ! 🙂

Ça paraît simple, voire simpliste, mais c’est un fait : on ne teste pas les sauvegardes. Et se rendre compte que nos sauvegardes ne sont pas restaurables quand on tente de sauver la production post-incident, c’est dur.

Il faut bien se rendre compte que tester ses sauvegardes ça prend du temps, ça demande des ressources. Mais il faut bien comprendre : it takes what it takes. 

Faites ce que je dis, ne faites pas ce que je fais !

C’est vrai que je me pose en bien-pensant. Vous vous demandez peut-être comment sur mes serveurs je fais ?

Bon déjà, hors du travail je ne m’occupe que d’un seul serveur. Avec un ami on s’en sert de fourre-tout, Mail, Web, Stockage …

Dès qu’on a commencé à travailler dessus, on a mis en place une référence où on enregistre chaque paquet qu’on installe, où se trouvent les fichiers de configuration clé d’un service, … Grâce à ce référentiel, on sait ce qui est installé sur notre machine.

Comme outil de sauvegarde pour les fichiers critiques, on utilise Borg car il est simple à utiliser tout en restant efficace.

Ok, un référentiel, un outil, mais le reste ?

Un accès SSH et python ! Notre serveur étant relativement minimal, on a fait le choix de l’Infrastructure as Code (IaC) avec Ansible.

industrial-robot-5
C’est-à-dire que plutôt que d’essayer de réparer à chaud une machine qui est devenue défectueuse, on part d’une fresh-install. Le système est reconstruit comme on le définit par Ansible (IaC). Une fois que la configuration est prête, tout se fait tout seul. Il y a un petit temps d’adaptation à l’outil mais la documentation est complète.

Et pourquoi Ansible ?

Très simplement parce que la solution est efficace. Il existe d’autres outils d’IaC : Puppet, Chef, SaltStack… À vous de trouver celle qui correspond à vos attentes.

Mettre à jour régulièrement notre configuration Ansible nous permet de faire face aux problèmes à venir.

En tout cas, si vous faites des sauvegardes, faites des restaurations.
Vous ne voulez pas faire la moitié du travail. 🙂

Références :

  1. Wikipédia : Chat de Schrödinger
  2. Borg : BorgBackup
  3. Ansible : Ansible

Icons made by Freepik from Flaticon is licensed by CC 3.0 BY

_______________________
Sharing is caring😜
Share on FacebookTweet about this on TwitterShare on LinkedIn


Comments

Cette entrée a été publiée dans Unix. Sauvegarder le permalien.