Sauvegardes

Cette page dit ce que Bastide sauvegarde de votre base, à quel rythme et pour combien de temps selon le palier, comment une base se restaure, et ce qui n'existe pas encore. Elle distingue l'engagement de la grille tarifaire de ce que le code tient aujourd'hui.

Ce qui est sauvegardé, par palier

Pour les paliers du cluster partagé, chaque base est sauvegardée par un dump à chaque échéance du palier. Les échéances sont alignées en UTC.

• Une base inchangée depuis son dernier dump n'est pas sauvegardée à nouveau : la nouvelle échéance désigne le même dump. Un dump ne se purge que quand plus aucune échéance gardée ne le désigne.
• La purge suit le calendrier : une sauvegarde sortie du calendrier de son palier est retirée, et aucune autre.
• Un projet Pro vit aujourd'hui sur le cluster partagé, faute d'instance dédiée servie (voir Base de données). L'archivage continu étant propre à l'instance dédiée, un projet Pro n'a pas de dump par base : il n'est couvert que par la sauvegarde du cluster décrite ci-dessous.

Sous les dumps : la sauvegarde du cluster

Le cluster entier est aussi copié : une copie complète chaque semaine, une différentielle chaque jour, et son journal d'écriture. Cette couche garde 30 jours ; la dernière copie complète n'est jamais purgée. Elle sert à reconstruire un nœud de données perdu, pas à rendre une base seule à un instant choisi.

Hors de la machine

Chaque nuit, les sauvegardes sont recopiées hors du site, chez un autre fournisseur, chiffrées avant de partir : la clé reste chez l'exploitant, jamais chez le fournisseur.

Les exercices de restauration

Chaque semaine, cinq bases sont tirées au hasard, restaurées dans un environnement isolé, et confrontées à une somme de contrôle logique prise au moment du dump. Un exercice qui ne rapporte pas dans les 24 heures compte comme un échec.

RPO et RTO

La grille tarifaire publie un objectif de perte de données (RPO) et un délai de remise en service (RTO) par palier :

Le RPO de Découverte et de Standard découle du rythme des dumps : au pire, vous perdez ce qui a été écrit depuis la dernière échéance. Le RPO de Pro et de Souverain suppose l'archivage continu, qui n'est pas encore servi. Le RTO d'une base restaurée est celui d'une restauration menée par l'exploitant (ci-dessous).

Restaurer une base

Il n'existe pas de restauration en libre-service : aucun écran ni aucun outil ne liste les points de sauvegarde d'une base ou ne la restaure. Les outils deployment_restorable_list et deployment_rollback restaurent une release, pas des données (voir Restaurer).

Une base se restaure par l'exploitant de la plateforme, à votre demande, depuis l'un de ses dumps. Ce que le geste fait :

1. Le dump est rapatrié et vérifié (taille, empreinte) avant toute écriture.
2. La base est restaurée à côté de la vôtre, sous un nom provisoire que votre application ne peut pas ouvrir, et confrontée à la somme de son dump.
3. La bascule ferme les connexions à votre base, échange les deux noms en une transaction, et vos clients se reconnectent au même nom. Votre base refuse les connexions une ou deux secondes.

Ce que le geste ne rend pas :

• Ce que vous avez écrit après le dump. C'est la perte permise par votre palier. La base remplacée reste écartée sept jours : l'exploitant peut en extraire des lignes à votre demande.
• Un instant arbitraire. La restauration à la seconde est celle de l'archivage continu, pas encore servi.
• Les objets du stockage. Les fichiers de vos seaux ne sont pas restaurés avec la base (voir Stockage).

Conseil. Avant une opération risquée, exportez vous-même ce qui compte : une lecture par database_sql_read ou l'éditeur SQL, copiée en CSV, ou l'archive de sortie décrite dans Sortir de Bastide.

Ce qui n'existe pas encore

• La restauration à la seconde (PITR) et la réplique synchrone de Pro et de Souverain.
• La restauration d'une base en libre-service, depuis la console ou par un agent.
• La liste des points de sauvegarde d'une base.
• Les événements database.backup.succeeded et database.backup.failed : ils figurent au catalogue des webhooks mais ne sont pas encore émis.
• La rétention étendue à 90 jours en option.

Erreurs fréquentes

• Une migration a détruit des données : demandez une restauration à l'exploitant au plus vite, en donnant l'heure de la migration. Plus vous attendez, plus le dernier dump antérieur s'éloigne de vos dernières écritures.
• Vous avez restauré une release et vos données n'ont pas bougé : c'est attendu, deployment_rollback ne touche pas la base.

Voir aussi

• Base de données, Branches et migrations, Restaurer, Sortir de Bastide
• Limites par palier, Souveraineté

Signaler une erreur sur cette page