Sauvegarder et restaurer Pulp (conteneur et Kubernetes)

Ce guide sauvegarde et restaure une instance Pulp sans rien perdre, en conteneur podman comme sur Kubernetes. Public visé : administrateurs responsables de la continuité d'un dépôt d'artefacts. Prérequis : une instance Pulp en fonctionnement. Le point à comprendre avant tout : chez Pulp, les données sont réparties sur trois emplacements distincts, et sauvegarder l'un sans les autres donne une restauration cassée.

Beaucoup pensent que « tout est dans la base ». C'est faux, et cette erreur coûte cher le jour de la restauration. Comprendre où vivent les données est le préalable à toute stratégie de sauvegarde fiable.

Ce que vous allez apprendre

• Identifier les trois emplacements de données de Pulp.
• Sauvegarder une instance en conteneur (base, artefacts, clés).
• Restaurer dans le bon ordre pour éviter les liens morts.
• Automatiser la sauvegarde et la restauration sur Kubernetes.

Où vivent les données : trois emplacements, pas un

Pulp ne stocke pas tout au même endroit. Une sauvegarde complète doit couvrir les trois :

Emplacement	Contenu	Sans lui, à la restauration
PostgreSQL	Métadonnées : dépôts, versions, publications, distributions, tâches, RBAC	Plus aucune structure : les artefacts existent mais rien ne sait les servir
File storage (/var/lib/pulp/media, ou objet S3)	Les artefacts eux-mêmes (binaires, adressés par sha256)	La base pointe vers des fichiers absents : liens morts
Clés de chiffrement (/etc/pulp/certs)	La clé qui chiffre les champs sensibles (identifiants des remotes) et le secret key	Les identifiants chiffrés sont irrécupérables

Glissez pour voir

La base contient donc uniquement des métadonnées. Les binaires vivent séparément, sur un système de fichiers ou un stockage objet. Redis, lui, ne sert que de file de tâches éphémère et n'a pas besoin d'être sauvegardé.

La clé de chiffrement, l'oubli qui tue la restauration

Le fichier database_fields.symmetric.key chiffre les mots de passe des remotes stockés en base. Si vous restaurez la base et les artefacts mais pas cette clé, Pulp ne peut plus déchiffrer ces identifiants : vos synchronisations sont mortes. Sauvegardez cette clé avec le même soin qu'une clé privée.

Sauvegarder une instance en conteneur

En déploiement podman, les trois emplacements sont des volumes montés. La sauvegarde consiste à figer la base et à archiver les volumes.

1. Dumper la base PostgreSQL. Le dump texte est portable :

   podman exec pulp bash -c 'pg_dump -U pulp pulp' > pulp-db.sql

   La sortie doit produire un fichier de plusieurs milliers de lignes commençant par -- PostgreSQL database dump.

2. Archiver les artefacts depuis le volume de stockage :

   podman exec pulp tar czf - -C /var/lib/pulp media > pulp-artifacts.tar.gz

3. Copier les clés de chiffrement et de session :

   podman exec pulp tar czf - -C /etc/pulp certs > pulp-certs.tar.gz

Ces trois fichiers (pulp-db.sql, pulp-artifacts.tar.gz, pulp-certs.tar.gz) forment une sauvegarde complète et cohérente. Stockez-les ensemble, chiffrés, hors de la machine Pulp.

Cohérence base / artefacts

Les artefacts sont adressés par empreinte (sha256) et immuables : le stockage ne fait qu'accumuler des fichiers, jamais les modifier. Un léger décalage entre le dump de la base et l'archive des artefacts est donc sans danger, tant que les artefacts sont archivés après ou en même temps que la base.

Restaurer une instance en conteneur, dans le bon ordre

L'ordre de restauration n'est pas indifférent. On restaure les artefacts et les clés d'abord, la base en dernier.

1. Restaurer les clés et les artefacts dans les volumes de la nouvelle instance :

   tar xzf pulp-certs.tar.gz -C /chemin/volume/etc-pulp
   tar xzf pulp-artifacts.tar.gz -C /chemin/volume/var-lib-pulp

2. Recharger la base :

   podman exec -i pulp bash -c 'psql -U pulp pulp' < pulp-db.sql

3. Vérifier que l'API répond et que les dépôts sont là :

   pulp status
   pulp file repository list

La logique : une base restaurée qui pointe vers un artefact absent casse le service, tandis qu'un artefact présent sans enregistrement en base est simplement orphelin (inoffensif, nettoyé plus tard par l'orphan cleanup). On privilégie donc les données immuables d'abord.

Sur Kubernetes : PulpBackup et PulpRestore

L'operator automatise tout le cycle via deux custom resources. Vous décrivez une sauvegarde, l'operator capture base, artefacts et secrets vers une PVC dédiée ; une ressource de restauration recrée l'instance complète depuis cette PVC.

Version de PostgreSQL alignée

L'outillage de sauvegarde de l'operator lance un pg_dump d'une version figée (15 dans l'operator 2.0). Un pg_dump ne peut pas dumper un serveur d'une version supérieure : votre base doit donc être en PostgreSQL 15, pas 16. Voir Déployer sur Kubernetes pour ce réglage. Une base en 16 ferait échouer PulpBackup en boucle (Failed to run pg_dump).

Sauvegarder avec PulpBackup

1. Créer une PVC de destination pour la sauvegarde :

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pulp-backup-claim
     namespace: pulp
   spec:
     accessModes: ["ReadWriteOnce"]
     storageClassName: local-path
     resources:
       requests:
         storage: 5Gi

2. Déclarer la sauvegarde avec une ressource PulpBackup :

   apiVersion: repo-manager.pulpproject.org/v1
   kind: PulpBackup
   metadata:
     name: sauvegarde-pulp
     namespace: pulp
   spec:
     deployment_name: pulp
     backup_pvc: pulp-backup-claim

   kubectl apply -f pulpbackup.yaml

   L'operator lance un job qui, une fois terminé, passe la condition BackupComplete à True. La PVC contient alors un dossier horodaté avec le dump pulp.db, le cr_object (la définition de l'instance) et tous les secrets, dont db_fields_encryption_secret.yaml (la clé de chiffrement) et pulp_secret_key.yaml.

Restaurer avec PulpRestore

La restauration se déclare de façon tout aussi déclarative. Elle recrée l'instance complète et recharge base et secrets depuis la PVC de sauvegarde.

apiVersion: repo-manager.pulpproject.org/v1
kind: PulpRestore
metadata:
  name: restauration-pulp
  namespace: pulp
spec:
  deployment_name: pulp
  backup_name: sauvegarde-pulp
  backup_pvc: pulp-backup-claim

kubectl apply -f pulprestore.yaml

Le champ backup_name est obligatoire : il désigne la ressource PulpBackup à restaurer. L'operator recrée alors la base, l'API, le contenu, les workers et le reverse proxy, puis recharge le dump et les secrets. Vérifiez ensuite que vos dépôts sont bien revenus :

kubectl -n pulp port-forward svc/pulp-api-svc 24817:24817 &
curl -s -u admin:MOT_DE_PASSE \
  http://localhost:24817/pulp/api/v3/repositories/file/file/

La sauvegarde reste sur une PVC

PulpBackup écrit sur une PVC du cluster, ce n'est pas une externalisation. Pour une vraie protection, copiez ensuite le contenu de cette PVC vers un stockage hors cluster (objet S3, site distant), ou pointez la PVC vers une classe de stockage qui réplique déjà ailleurs.

À retenir

• Les données de Pulp vivent à trois endroits : base (métadonnées), file storage (artefacts), clés de chiffrement.
• La base ne contient pas les artefacts : les binaires sont sur un système de fichiers ou un stockage objet.
• La clé database_fields.symmetric.key est indispensable : sans elle, les identifiants chiffrés des remotes sont perdus.
• En conteneur, on restaure artefacts et clés d'abord, base en dernier (les artefacts sont immuables et adressés par empreinte).
• Sur Kubernetes, PulpBackup / PulpRestore automatisent le cycle complet ; la base doit être en PostgreSQL 15 pour que la sauvegarde fonctionne.

Prochaines étapes

Déployer Pulp sur Kubernetes L'operator et la ressource Pulp, prérequis de PulpBackup.

Installer Pulp (conteneur) Le déploiement podman et ses volumes.

Sécuriser Pulp RBAC, content-guards et signature.

Air-gapped et transfert hors-ligne Export/import de contenu vers un réseau isolé.

×

📖 Voir la documentation →