Sauvegardes et restauration

Ce qui est sauvegardé automatiquement

Chaque namespace est sauvegardé chaque nuit à 22h00, sans configuration de votre part :

Aspect	Détail
Périmètre	Tout le namespace : ressources Kubernetes (Deployments, Services, ConfigMaps, Secrets…) et volumes persistants
Fréquence	Quotidienne, 22h00
Rétention	10 jours
Stockage	Bucket objet S3 dédié, chiffré, géo-redondant : à plus de 400 km du site de production

Demander une restauration

La restauration n’est pas en self-service : elle passe par un ticket support. Indiquez :

1. le namespace concerné ;
2. quoi restaurer : tout le namespace, une ressource précise, ou un volume (nom du PVC) ;
3. la date/heure de la sauvegarde souhaitée (dans la fenêtre de 10 jours) ;
4. la raison — utile pour éviter de restaurer par-dessus une donnée plus récente que le problème.

Attention

Une restauration de volume écrase les données actuelles par celles de la sauvegarde. Tout ce qui a été écrit entre la sauvegarde et la restauration est perdu — d’où l’intérêt des sauvegardes applicatives ci-dessous pour réduire la fenêtre de perte.

Compléter avec des sauvegardes applicatives

La sauvegarde plateforme est un filet de sécurité quotidien. Pour maîtriser finement votre point de reprise (RPO), doublez-la d’une sauvegarde applicative dont vous contrôlez la fréquence et la rétention. Exemple : un dump PostgreSQL toutes les 6 heures via un CronJob :

apiVersion: batch/v1
kind: CronJob
metadata:
  name: pg-dump
spec:
  schedule: "0 */6 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: dump
              image: postgres:17-alpine
              command: ["sh", "-c", "pg_dump $DATABASE_URL > /backup/dump-$(date +%Y%m%d-%H%M).sql"]
              envFrom:
                - secretRef:
                    name: db-credentials
              volumeMounts:
                - name: backup
                  mountPath: /backup
          volumes:
            - name: backup
              persistentVolumeClaim:
                claimName: pg-backups

Avantages : restauration en autonomie (psql < dump.sql), granularité de 6 h au lieu de 24 h, pour quelques dizaines de centimes par mois (facturation à l’heure entamée).

PostgreSQL managé

Si vous utilisez l’opérateur PostgreSQL intégré (CNPG), vous pouvez en plus configurer des sauvegardes continues vers votre propre stockage objet S3 (OVHcloud, Scaleway…), avec sauvegardes à la demande et planifiées que vous pilotez vous-même — voir le guide.

En résumé

Besoin	Solution
Filet de sécurité quotidien	Sauvegarde plateforme (automatique, rien à faire)
Récupérer l’état d’il y a N jours (≤ 10)	Ticket de restauration
RPO fin, restauration autonome	Dumps applicatifs en CronJob
PostgreSQL	Backups CNPG self-service + filet plateforme