Sauvegarde et restauration

Les bases PostgreSQL — qu'il s'agisse du template PostgreSQL autonome ou du PostgreSQL intégré à Digdash BI — peuvent être sauvegardées en continu vers un stockage S3, puis restaurées dans une nouvelle application.

Activer les sauvegardes

Dans le formulaire de déploiement (section Sauvegarde), ou après coup via Configurer → Paramètres avancés :

1. Activer les sauvegardes planifiées : active à la fois l'archivage continu des journaux (WAL) et la sauvegarde de base planifiée — les deux sont nécessaires pour pouvoir restaurer.
2. Politique de rétention : durée de conservation, par exemple 7d, 4w.
3. Chemin S3 (destinationPath) : le bucket cible. Choisissez Bucket existant pour sélectionner un bucket de la plateforme — le chemin s3://… et l'endpoint se remplissent automatiquement.
4. Access Key / Secret Key : les identifiants du bucket (fournis par la page Buckets).

Sauvegarde immédiate

La planification par défaut est quotidienne. Pour produire une première sauvegarde sans attendre, une option de sauvegarde immédiate est disponible dans les paramètres de sauvegarde.

Restaurer

La restauration crée une nouvelle application dont la base démarre depuis la sauvegarde — l'application d'origine n'est pas modifiée.

1. Nouvelle app → même template que la source (PostgreSQL ou Digdash BI).
2. Dans la section Restauration :
   • activez la restauration ;
   • Nom de l'app source : le nom exact de l'application dont la sauvegarde a été écrite (tel qu'affiché sur sa carte) ;
   • Chemin S3 de la sauvegarde à restaurer : le même bucket que celui de la sauvegarde ;
   • les identifiants S3 du bucket.
3. Déployez : la nouvelle application démarre en rejouant la sauvegarde, puis passe en Running.

Warning

Si la source S3 est vide, inaccessible ou corrompue, la nouvelle application ne démarrera pas (redémarrages en boucle). Vérifiez le contenu du bucket depuis la page Buckets avant de lancer la restauration.

Restaurer à une date précise

Par défaut, la restauration rejoue la sauvegarde jusqu'au point le plus récent disponible (fin du flux des journaux WAL). Il est aussi possible de restaurer la base telle qu'elle était exactement à un instant donné dans le passé — utile par exemple pour annuler les effets d'une suppression ou d'une migration ratée survenue après la dernière sauvegarde valable.

Exemple : sauvegardes quotidiennes, restauration à l'état de la veille à 23h59

Une application source a les sauvegardes planifiées activées avec une planification quotidienne (0 0 0 * * *, soit minuit chaque jour) et une rétention de 7 jours. Une erreur est constatée aujourd'hui ; on souhaite retrouver l'état de la base tel qu'il était hier à 23h59, juste avant la sauvegarde de minuit :

1. Nouvelle app → même template que la source.
2. Section Restauration : activez-la, renseignez le Nom de l'app source et le Chemin S3 de la sauvegarde à restaurer comme pour une restauration classique.
3. Restaurer à une date précise (optionnel) : saisissez 2024-06-24 23:59:00+02 (adapter la date et le fuseau horaire).
4. Déployez : CNPG restaure la sauvegarde puis rejoue les journaux WAL archivés jusqu'à l'instant indiqué, sans aller plus loin.

Tip

Le fuseau horaire fait partie de la valeur (+02, +00…) — sans lui, l'heure est interprétée dans le fuseau du serveur PostgreSQL. La continuité des journaux WAL entre la sauvegarde et l'instant cible doit être intacte : une rétention trop courte ou une sauvegarde manquante entre les deux empêche la restauration d'atteindre la date demandée.

Snapshots de volumes

Indépendamment des sauvegardes S3, tout volume persistant peut faire l'objet de snapshots ponctuels et de clones — voir Volumes.