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

| Palier | Rythme | Conservation | État |
| --- | --- | --- | --- |
| Découverte | Un dump par jour, à minuit UTC | 7 jours | Servi |
| Standard | Un dump par heure | Chaque dump 48 heures, puis le dernier de chaque jour jusqu'à 30 jours | Servi |
| Pro, avant l'instance dédiée | Le rythme du Standard : un dump par heure | Chaque dump 48 heures, puis le dernier de chaque jour jusqu'à 35 jours | Servi |
| Pro, instance dédiée | Archivage continu, restauration à la seconde (PITR) | 35 jours | Pas encore servi |
| Souverain | Archivage continu et réplique synchrone | 90 jours | Pas encore servi |

- **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](database.md)). Tant que son instance dédiée et son archivage continu ne sont pas servis, il reçoit le calendrier de dumps du Standard avec la conservation du Pro : 35 jours. Dès qu'ils sont servis, les dumps cessent pour ce projet ; ceux déjà pris restent jusqu'à la fin de leur conservation.

### 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 :

| Palier | RPO | RTO |
| --- | --- | --- |
| Découverte | 24 h | 4 h |
| Standard | 1 h | 2 h |
| Pro, avant l'instance dédiée | 1 h | 2 h |
| Pro, instance dédiée | 5 min | 30 min |
| Souverain | 5 min | 30 min |

Le RPO de Découverte, de Standard et du Pro avant son instance dédiée découle du rythme des dumps : au pire, vous perdez ce qui a été écrit depuis la dernière échéance. Le RPO de l'instance dédiée du 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](restore.md)).

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](storage.md)).

> **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](leave.md).

## 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](database.md), [Branches et migrations](branches.md), [Restaurer](restore.md), [Sortir de Bastide](leave.md)
- [Limites par palier](limits.md), [Souveraineté](sovereignty.md)