Stratégies de sauvegardes des données

L'informatique ça tient du chaos, plus vous avez besoin que ça marche, plus cela augmente les chances que ça plante

Actuellement , nous n'avons aucune stratégie de sauvegarde sur le serveur, ce qui est, quand on y pense, un peu flippant (et je pense qu'il faudrait vraiment s'y interesser urgemment). Il faudrait corriger ce souci afin de garantir à la communauté que le contenu du site ne sera jamais perdu. Nous devons définir ensemble une stratégie de sauvegarde et de restauration pour limiter au maximum la casse.

Je rappelle que ZdS a essentiellement 3 types de sauvegardes à effectuer :

• Le code source de ZdS : Il est sur github, donc on peut le retrouver si besoin
• La base de donnée : Il s'agit d'une base de donnée MySQL
• Les données physiques (images, articles et tutoriels) : bien noter qu'ils sont liés à la base de données et donc lors de la restauration il faut s'assurer qu'elles restent synchro.

Nous avons estimés qu'en un an de fonctionnement, nous atteindrons les 8Go de données (non compressibles) sur notre serveur, donc en fonction de la stratégie de sauvegarde décidée (annule/remplace ? 5 dernieres sauvegarde ? delta ?) et de la fréquence de sauvegarde (1fois/jour ? 1 fois/semaine ?) il faudra calculer l'espace requis en terme de sauvegarde.

On en avait déjà discutté à un époque en interne sur notre Mailing list désormais fermée. Je vais reprendre ici un résumé des propositions, afin d'avoir des avis et des conseils de tout un chacun.

Amazon Glacier

Solution de type archivage.

Avantages

• Quasi gratuit
• On ne paye vraiment que quand on récupère les données

Inconvénient

• Ça n'a pas l'air très très simple à mettre en place à première vue

Plus d'infos

OVH Backup Storage

Avantages

• On est déjà chez OVH, un seul compte, une seule facture
• Montage NFS, donc très simple à mettre en place et sauvegarde en temps réel possible

Inconvénient

• 10€ HT / mois

Plus d'infos

Hubic (OVH)

Simple backup

Avantages

• 25Go gratuits (1€ TTC/mois jusqu'à 100Go, 10€ TTC/mois jusqu'à 10 To)
• une API documentée

Inconvénient

• Le dev peut devenir lourd

Dropbox

Avantages

• versionning des fichiers (pas besoin de stocker plusieurs archives par jours)
• synchronisation automatique

Inconvénients

• Scripts de sauvegardes
• Devient rapidement payant

Runabove (OVH)

Avantages

• Tarifs très bas

Voila en gros ou en est la réflexion à ce niveau.

Ajoute comme inconvénient à Dropbox que ça craint légèrement niveau sécu.

Plus sérieusement : la liste que nous avons ici ne nous permet pas franchement de prendre une décision comme ça. Il manque des éléments pour faire un comparatif et l'écrémer avant de présenter les alternatives au CA pour décision finale.

Commençons par définir précisément ce que nous voulons :

• Combien de snapshots comptons-nous garder en régime établi, a minima ?
• Avons-nous actuellement la certitude que nous sommes capables de déployer le site entièrement sur un serveur à partir du dépôt, from scratch jusqu'au démarrage des services après un reboot final ? (i.e., avons-nous versionné tous les scripts de déploiement nécessaires ?)
• Parmi les solutions citées : lesquelles sont capables de sauvegarder le site à chaud sans risque de corruption ?
  • Celles qui ne le permettent pas : pourquoi ? Avons-nous une solution pour les y aider a priori ?

Combien de snapshots comptons-nous garder en régime établi ?

Tout dépend du besoin et de la réactivité qu'on veut avoir, mais sauver entre 5 et 10 snapshots, sur une fréquence d'1fois/jour me parait déjà une bonne base.

Avons-nous actuellement la certitude que nous sommes capables de déployer le site entièrement sur un serveur à partir du dépôt, from scratch jusqu'au démarrage des services après un reboot final ? (i.e., avons-nous versionné tous les scripts de déploiement nécessaires ?)

ça fait justement partie de la stratégie de sauvegarde à mettre en place. Scripter le déploiement from scratch, sauvegarder les script de déploiement et s'asssurer qu'on puisse relancer la machine en cas de crash. Une sortie de dossier d'exploitation en somme.

Parmi les solutions citées : lesquelles sont capables de sauvegarder le site à chaud sans risque de corruption ?

Là faudrait l'avis d'un expert. On s'éloigne de mes compétences là.

Pour moi, le déploiement est indépendant de la stratégie de sauvegarde. Clairement sauvegarder un snapshot du code source est inutile et sale : on devrait pouvoir le redéployer proprement à partir d'un clone du dépôt sur github. Du coup, quelle que soit la stratégie employée, il faut que nous complétions ces scripts de déploiement.

Pour le premier point, ça me semble cohérent pour le départ : une sauvegarde par jour avec un rotate toutes les 5 ou 10 sauvegardes suivant l'espace disponible. Partons sur ça.

Pour le dernier point, mon raisonnement est en fait simple : soit la solution le permet intrinsèquement, soit il faut que l'on place le site en lecture seule le temps de la sauvegarde.

Vous deployez comment à l'heure actuelle ?

Parce que ce que tu décris là c'est assez standard comme façon de faire. Du coup, j'étais persuadé que vous fonctionniez comme cela. (donc je m'interroge).

Javier, on déploie simplement en mergeant les branches avec git, de façon classique.

Je parlais ici du déploiement "initial", qui contient notamment l'installation et la configuration de tous les services nécessaires : en principe on ne le fait qu'une fois, mais imaginons que nous devions migrer le site vers un nouveau serveur tout nu parce que le serveur de prod nous claque dans les pattes, il faudrait qu'on soit capables de le faire le plus rapidement et le plus automatiquement possible.

Clairement sauvegarder un snapshot du code source est inutile et sale

C'est bien pour ça que j'ai précisé dans mon premier post : "Le code source de ZdS : Il est sur github, donc on peut le retrouver si besoin".

Du coup, quelle que soit la stratégie employée, il faut que nous complétions ces scripts de déploiement.

C'est ce que j'appelle donc scripter la restauration qui englobe un script de déploiement. Il ne suffit pas de cloner le projet pour que tout marche, il faut installer tous les services qui gravitent autour (mysql, gunicorn, supervisor, solr, etc.).

Oui, on est en train de dire qu'on est d'accord depuis 5 messages, en gros.

@nohar

Question un peu naïve mais pourquoi ne pas gérer les sauvegardes vous même ? OVH vous fourni un ftp gratuitement il me semble quelque script qui vont bien pour faire le dump des bases de données, faire une archive des données physiques sauvegarder le tout sur le ftp de façon régulière

Le problème, selon moi, c'est de garantir que le snapshot que l'on sauvegarde est dans un état stable, i.e. que l'état de la BDD est cohérent avec celui des ressources sur le disque, donc qu'on ne risque pas d'importer un truc pété en cas de restauration. Si on se contente de faire une copie à l'arrache, on ne pourra pas obtenir cette garantie.

Après, on a certainement toujours moyen de ruser à coups de rsync et consorts, mais plutôt que nous rajouter un tel effort de conception et d'anticipation, ce serait pas mal si on pouvait employer une solution garantie stable et robuste, et qui fasse correctement le job à notre place.

Concernant la BDD, mysqldump avec les bonnes options garantit la fiabilité de la sauvegarde.

OK, donc en théorie on devrait pouvoir se contenter d'un mysqldump et de rsync incrémentaux avec les options-qui-vont-bien ?

Genre, faire un truc comme ça ? (|| désigne des tâches à réaliser en parallèle).

1
2
3
4
5

rsync disk_prod -> disk_dump         ||        mysql_dump bdd_prod -> bdd_dump
rm disk_save_oldest
rm bdd_save_oldest
cp disk_dump -> disk_save_DATE
cp bdd_dump -> bdd_save_DATE

Si on peut se contenter de ça, la stratégie de backup ne nécessite qu'un serveur ayant assez de stockage en fait.

Au passage concernant le fait de le faire manuellement comme en parle Angelo, cela pose des problèmes de fiabilité de tout stocker au même endroit. En gros, si quelqu'un nous pirate et efface tout, on perd tout.

Il vaut mieux multiplier les comptes je pense, pour éviter de tout confier a un seul prestataire. Même si ovh est sérieux, on ne sait jamais.

C'est vrai, au boulot, on sauvegarde sur le ftp ovh + sur un ftp loué ailleurs d'ailleurs

Pour mysql, j'espère que vous utilisé le moteur InnoDB

UP !

C'est quand même quelque chose d'important, et on commence à avoir beaucoup de données l'air de rien.

Peut être qu'une solution temporaire serait une grosse archive crypté qu'on met a disposition. La clé est gardé par 2-3 membres de confiance et on joue sur nos propres disque durs en attendant d'avoir une solution automatisés

Salut,

En espérant vous aidez dans cette stratégie de sauvegarde. J'ai fait quelques plans de sauvegarde pour plusieurs compagnies, mais en général pour des systèmes complets et toute l'infrastructure. Jamais pour un site. Mes questions et propositions seront peut-être un peu overkill pour le site.

Voici ce que cela donne :

• Quels éléments sont à sauvegarder ?
  • Dépôt GitHub
  • Données physiques du site (images, uploads…)
  • Base de données
  • Est-ce que le serveur Prod et PréProd sont des VMs ?
    • Oui: Backup des VMs ?

Afin de garantir un recouvrement rapide et sans pertes

• Quelle est la fréquence de Backup pour chaque élément ainsi que la rotation ?

Afin de garder l'intégrité des données sauvegardées

• Est-ce que l'on calcul des CheckSums (MD5 ou SHA1 ?) après chaque backup et sur tous les éléments ?

• Définir les procédures en cas de :

  • Perte totale (plus de serveur, il nous reste juste les backups)
    • Script de déploiement des sources et installation des prérequis logiciels
    • Recouvrement des données physiques
    • Recouvrement de la base de données
    • Reconfiguration du domaine
  • Perte partiel (plus de serveur de Prod)
    • On bascule alors sur la Préprod qui doit être quasiment instantanée. (Ceci implique une réplication des données physiques et base de données en permanence).
    • Puis script de synchronisation pour repasser sous Prod lorsque remonté.

Une fois que les fréquences, temps de sauvegardes, rotations et espaces disques nécessaires défini/calculé, je pense que vous pourrez mieux choisir où vous allez déposer vos fichiers de sauvegardes (chiffrés) ainsi que les méthodes à utiliser pour faire les scripts. (et certainement des tâches cron). Par exemple, utiliser un ftp (si chez OVH) en plus de faire des "rsync" entre Prod et Préprod, mais aussi de déposer les Backups chez un autre fournisseur.

Aussi, les scripts de sauvegardes, déploiements et de recouvrements doivent être sauvegardés quelques parts. J'ai lu dans un autre poste (ici) d'avoir un dépôt pour les scripts et problèmes serveurs… Si cela se fait (sinon prévoir un endroit où mettre ça), il faudrait aussi y mettre dans le Wiki, des pages de "procédure" afin de documenter au maximum, les sauvegardes et recouvrement des données, ainsi que la marche à suivre pour remonter le site rapidement quel que soit le problème rencontré.

Je pense qu'il faut également prévoir un cas où la personne responsable des backups quitte le bateau. D'où le fait de documenter dans un Wiki, comment tout se fait, quasiment n'importe quel admin pourrait prendre le relais. Peut être réfléchir pour changer les clés de chiffrements, si l'on veut que la personne n'est plus accès à la BDD par exemple…

Voilà, en espérant pouvoir aider ce projet prometteur.

@+

Honnêtement je ne vois pas comment on peut garantir cette cohérence sans mettre le site en lecture seule le temps de la sauvegarde. Car quid du gars qui edit son tuto pendant la sauvegarde ? Pour la base de données pas de problème, on peut toujours mettre un lock sur l'ensemble de la base au début de la save et le relâcher à la fin (ce qui est, dans les faits, une lecture seule…) (par contre on ne peut pas lock les tables les une après les autres, car sinon vive l'incohérence si la table des topics est mise à jour mais que celle des posts ne l'est pas).
Par contre, pour le système de fichier… si Monsieur X édite son tuto et ajoute une image pendant la sauvegarde il y 99% de chances (chiffre au pif mais certainement pas trop éloigné de la vérité) pour quelle soit perdue.

Après le public est presque exclusivement français (plus quelques amis du Quebec), ce qui veut dire qu'une sauvegarde autour de 7 - 8h du matin heure française (1 - 2h du matin au Quebec) pourrait être une bonne idée (mais sur ce point, Piwik, GA ou tout autre outil du genre saura donner une meilleure info).

Tous les bons SGBD ont une option pour récupérer une sauvegarde intègre à chaud.

D'autre part, les stats d'accès me disent que les sauvegardent devraient être faites entre 4h et 6h du matin, heure de Paris.