---
title: "Sauvegardes et restauration"
description: "Ce qui est sauvegardé automatiquement chaque nuit sur Kontainers, comment demander une restauration, et comment compléter avec vos propres sauvegardes applicatives."
source_url:
  html: https://docs.blackswift.cloud/operer/sauvegardes-et-restauration/
  md: https://docs.blackswift.cloud/operer/sauvegardes-et-restauration.md
---

# Sauvegardes et restauration

> Ce qui est sauvegardé automatiquement chaque nuit sur Kontainers, comment demander une restauration, et comment compléter avec vos propres sauvegardes applicatives.

## 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](https://docs.blackswift.cloud/depanner/contacter-le-support.md). 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.

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

```yaml
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](https://docs.blackswift.cloud/reference/facturation.md)).

:::tip[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](https://docs.blackswift.cloud/deployer/postgresql-manage.md#sauvegardes-vers-votre-stockage-s3).
:::

## 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](https://docs.blackswift.cloud/depanner/contacter-le-support.md) |
| RPO fin, restauration autonome | Dumps applicatifs en CronJob |
| PostgreSQL | Backups CNPG self-service + filet plateforme |