Sauvegardes

Politique de sauvegarde

TeDomum sauvegarde ses données selon quelques principes simples :

• sauvegarde régulière : les données sont sauvegardées régulièrement, en général une fois par jour ;
• sauvegarde incrémentale : seules les données modifiées depuis la dernière sauvegarde sont sauvegardées ;
• sauvegarde distante : les données sont sauvegardées sur un autre cluster que celui qui les héberge (de manière générale nous tâchons de nous rapprocher de la règle des 3-2-1, c’est-à-dire 3 copies de vos données, sur 2 supports différents, dont 1 hors site, en limitant toutefois à 2 copies pour une partie des données) ;
• sauvegarde chiffrée : les données sont chiffrées avant d’être envoyées sur le cluster de sauvegarde.

Ces quelques principes permettent de garantir un bon niveau de sécurité de vos données, et de les restaurer en cas de problème, y-compris en cas de panne de l’ensemble de nos serveurs. En outre, elles nous permettent ponctuellement de restaurer des données effacées par erreur par un utilisateur.

Plus précisément, notre politique suit les principes suivants :

• autant que possible, sauvegarde continue des journaux de transaction, sinon au minimum une copie incrémentale par jour ;
• une copie complète des données est effectuée une fois par semaine ;
• tous les différentiels sont conservés jusqu’à la dernière complète, avec une capacité de restauration au minimum à la journée sur 3 jours et à la semaine sur 3 semaines ;
• les sauvegardes sont structurées et chiffrées avant envoi vers du stockage indépendant de nos clusters, où nous ne sommes pas tous administrateurs ;
• la technologie de stockage des sauvegardes est distincte de celle de nos clusters, pour éviter une défaillance commune.

Limites de la politique de sauvegarde

La politique de sauvegarde de TeDomum a des limites, qui sont les suivantes :

• perte de données : les données modifiées entre deux sauvegardes peuvent être perdues en cas de panne, soit au cours d’une journée ou une semaine pendant notre période de rétention, soit généralement au delà de 3 semaines dans le passé ;
• restauration partielle : il n’est pas toujours possible de restaurer une partie des données à une date donnée, mais seulement l’ensemble des données à une date donnée, en particulier vrai pour nos bases de données, donc la plupart des données de services (par exemple, pas possible de restaurer un compte sur un service sans restaurer tous les comptes) ;
• durée de restauration : la restauration de données peut prendre du temps, en particulier si elle est étendue, et cause une interruption de service ;
• pas de sauvegarde hors-ligne : hors des sauvegardes ponctuelles de nos éléments les plus essentiels (clés des sauvegardes, configurations, etc.), nous n’avons pas les moyens d’effectuer des sauvegardes hors ligne, donc une compromission de 100% des actifs de TeDomum, y-compris nos points de sauvegarde, pourrait entraîner une perte de données.

Méthodes de sauvegarde

Bases de données PostgreSQL

L’ensemble de nos bases PostgreSQL, qu’elles soient déployées sur aegir manuellement ou bien gérées dans kity par CNPG, sont sauvegardées par une combinaison de sauvegardes continues des journaux de transaction et de sauvegardes complètes du répertoire de données PostgreSQL :

• aegir utilise wal-g pour l’envoi chiffré des WAL vers S3 en continu, avec une complète hebdomadaire, les données sont chiffrées par libsodium ;
• kity utilise barman, géré par CNPG, pour l’envoi chiffré des WAL vers S3 en continu, avec une complète hebdomadaire.

Dans les deux cas, l’envoi est effectué vers un bucket S3 hébergé sur la zone fr-halfa-1 sous maîtrise d’un membre de l’association et sur le sol français.

Données fichiers sur aegir

aegir notre dernier serveur en cloud, héberge les données des services sous forme de fichiers locaux.

Elles sont sauvegardées quotidiennement par restic vers un point de sauvegarde S3. Un prune des sauvegardes est effectué hebdomadairement, conformément à la politique.

La sauvegarde est chiffrée par restic en GPG avant envoi. Le tout est stocké sur la zone fr-halfa-1 sous maîtrise d’un membre de l’association et sur le sol français.

Données S3 de garage

De plus en plus de données sont stockées dans notre cluster garage via S3. Garage conserve en permanence 3 copies de chaque objet, de sorte que nous puissions assurer la continuité des services en cas de perte d’un site. Cette réplication ne joue toutefois pas le rôle de sauvegarde.

Nous avons développé un outil de sauvegarde higlo qui permet de synchroniser régulièrement, avec conservation des différences, les données de nos buckets S3 vers des buckets S3 de sauvegarde. Ces sauvegardes sont chiffrées avant envoi (higlo est un opérateur kubernetes qui s’appuie sur rclone en backend).

Les données de sauvegarde sont stockées sur la zone fr-halfa-1 sous maîtrise d’un membre de l’association et sur le sol français.

Planning de backups

Les backups prennent du temps, et on a de nombreuses familles de données à sauvegarder. On organise donc un planning de backups, avec des créneaux de 1h chaque nuit de minuit à 6h. Le temps de chaque backup est approximatif, mais l’enjeu est de réserver les créneaux intelligemment.

Lancer un backup cnpg manuellement

$ krew install cnpg
$ kubectl cnpg backup -m plugin --plugin-name barman-cloud.cloudnative-pg.io -n namespace databasename