Sauvegarde et restauration Ceph avec exemples pratiques : guide complet d'implémentation

Introduction

Les opérations de sauvegarde et restauration Ceph exigent de la précision, une connaissance des versions et un chemin de récupération clair avant que toute commande ne touche aux données de production. Ce guide présente des implémentations pratiques pour sauvegarder et restaurer des clusters Ceph, couvrant les images RBD, les volumes CephFS et l'état de configuration du cluster. Vous y trouverez des commandes spécifiques aux versions, les motifs de sortie attendus, les signaux d'échec et des procédures de récupération testées.

Le public visé inclut les développeurs exécutant Ceph sur Kubernetes via Rook, les consultants DevOps gérant des clusters Ceph soutenus par Proxmox, et les équipes techniques de startups opérant du stockage auto-hébergé. Chaque exemple utilise des espaces réservés explicites au lieu d'identifiants réels, indique les prérequis et le rayon d'impact, et inclut une étape de vérification avec un chemin de retour documenté.

Les principes de sécurité opérationnelle s'appliquent tout au long : observer avant de modifier, limiter le rayon d'impact, protéger les identifiants, vérifier les résultats et documenter la récupération avant qu'un incident ne force la décision.

Inventaire des versions et de l'environnement

Avant toute opération de sauvegarde ou restauration, capturez l'état exact du cluster. Cet inventaire devient votre point de référence pour la validation et le retour arrière.

Identifier la version Ceph et la topologie de déploiement

Exécutez les commandes suivantes en lecture seule sur un nœud moniteur ou depuis un client admin avec accès cephadm :

ceph version
ceph orch host ls
ceph orch ls
ceph osd tree
ceph df

Enregistrez la sortie avec horodatage. Exemple de sortie attendue pour un cluster Ceph 18.2.2 (Reef) :

ceph version 18.2.2 (6f5c3a8b7c) reef (stable)
HOST          ADDR          LABELS  STATUS
ceph-mon-1    10.0.1.11     mon     running
ceph-mon-2    10.0.1.12     mon     running
ceph-mon-3    10.0.1.13     mon     running
ceph-osd-1    10.0.1.21     osd     running
ceph-osd-2    10.0.1.22     osd     running
ceph-osd-3    10.0.1.23     osd     running

Documenter l'état des pools et de la carte CRUSH

Capturez la configuration des pools et la carte CRUSH pour référence de restauration :

ceph osd dump -o /backup/osd_dump_$(date +%F).json
ceph osd getcrushmap -o /backup/crushmap_$(date +%F).bin
crushtool -d /backup/crushmap_$(date +%F).bin -o /backup/crushmap_$(date +%F).txt

Stockez ces artefacts dans un domaine de sauvegarde distinct (stockage objet, NFS, ou un autre cluster Ceph). Vérifiez que les tailles de fichiers sont non nulles et que le JSON s'analyse correctement :

jq empty /backup/osd_dump_$(date +%F).json && echo "OSD dump valide"

Liste de contrôle des prérequis

• Trousseau admin (/etc/ceph/ceph.client.admin.keyring) accessible
• Shell cephadm ou podman/docker pour accès CLI conteneurisé
• Espace suffisant dans la cible de sauvegarde (estimez 2 à 3x les données brutes pour export RBD complet)
• Connectivité réseau entre client et nœuds moniteur/OSD
• Fenêtre de maintenance approuvée pour toute opération pouvant augmenter la charge

Chemin de configuration sécurisé : procédures de sauvegarde

Cette section couvre trois stratégies de sauvegarde : export d'image RBD, instantané CephFS + rsync, et sauvegarde de configuration du cluster. Choisissez selon vos exigences RPO/RTO.

Sauvegarde d'image RBD avec rbd export

Pour le stockage bloc (disques VM, bases de données), rbd export crée un fichier d'image portable. Utilisez --no-progress pour l'automatisation.

# Prérequis : pool existe, image existe, client a accès en lecture
# Rayon d'impact : image RBD unique ; le cluster reste en ligne
# Récupération : rbd import restaure vers le même pool ou un pool différent

rbd export --no-progress \
  <nom-pool>/<nom-image> \
  /backup/rbd/<nom-pool>_<nom-image>_$(date +%F_%H%M).img

# Vérification
rbd info <nom-pool>/<nom-image> | grep -E 'size|objects|order'
ls -lh /backup/rbd/<nom-pool>_<nom-image>_$(date +%F_%H%M).img

Vérification attendue : la taille du fichier exporté correspond à la taille rapportée par rbd info (dans 1% pour images creuses). Signal d'échec : rbd: error: image not found ou permission refusée sur le point de montage de sauvegarde.

Option de sauvegarde incrémentale (Ceph 16.2+) : Utilisez rbd export-diff avec un instantané antérieur :

rbd snap create <pool>/<image>@snap_$(date +%F)
rbd export-diff --from-snap snap_20240115 <pool>/<image>@snap_$(date +%F) /backup/rbd/diff_<image>_$(date +%F).diff

Sauvegarde CephFS via instantané et Rsync

CephFS prend en charge les instantanés natifs. Combinez avec rsync pour une sauvegarde au niveau fichier vers un stockage externe.

# Créer un instantané (requiert Ceph 15.2+)
mkdir -p /mnt/cephfs/.snap/backup_$(date +%F_%H%M)
# L'instantané apparaît instantanément sous le répertoire .snap

# Rsync vers la cible de sauvegarde (NFS, S3 via rclone, autre CephFS)
rsync -avHAX --delete --numeric-ids \
  /mnt/cephfs/.snap/backup_$(date +%F_%H%M)/ \
  /backup/cephfs/backup_$(date +%F_%H%M)/

# Vérification
du -sh /mnt/cephfs/.snap/backup_$(date +%F_%H%M)
du -sh /backup/cephfs/backup_$(date +%F_%H%M)

Rayon d'impact : création d'instantané en lecture seule ; charge rsync selon le taux de changement. Récupération : rsync vers un montage CephFS restauré. Pour les environnements Proxmox, cela s'intègre avec les tâches de sauvegarde pvesm ciblant le stockage CephFS.

Sauvegarde de la configuration du cluster

Sauvegardez la base de données moniteur, les trousseaux et ceph.conf pour une reprise complète après sinistre :

# Sur chaque nœud moniteur
tar -czf /backup/ceph-mon-$(hostname)-$(date +%F).tar.gz \
  /etc/ceph/ \
  /var/lib/ceph/mon/ceph-$(hostname)/store.db \
  /var/lib/ceph/mgr/ceph-$(hostname)/

# Vérification
tar -tzf /backup/ceph-mon-$(hostname)-$(date +%F).tar.gz | head -20

Stockez les sauvegardes moniteur d'au moins deux moniteurs. Pour les déploiements cephadm, exportez aussi la spécification :

ceph orch ls --export > /backup/cephadm_spec_$(date +%F).yaml

Vérification et diagnostics

Chaque sauvegarde doit être vérifiée. Cette section définit les procédures de validation et les commandes de diagnostic pour les modes d'échec courants.

Vérification d'export RBD

# Vérifier l'intégrité de l'image via rbd info sur le fichier exporté (nécessite import vers pool temporaire)
rbd import --no-progress \
  /backup/rbd/<pool>_<image>_$(date +%F_%H%M).img \
  <pool-verif>/verif-<image>-$(date +%F)

rbd info <pool-verif>/verif-<image>-$(date +%F)
rbd diff <pool-verif>/verif-<image>-$(date +%F) | wc -l

# Nettoyage
rbd rm <pool-verif>/verif-<image>-$(date +%F)

Résultat attendu : le nombre d'objets correspond à la source, diff montre zéro différence depuis l'instantané source. Signal d'échec : l'import échoue avec erreur de checksum ou fichier tronqué.

Vérification Rsync CephFS

# Comparer les comptes de fichiers et tailles
find /mnt/cephfs/.snap/backup_$(date +%F_%H%M) -type f | wc -l
find /backup/cephfs/backup_$(date +%F_%H%M) -type f | wc -l

# Vérification d'échantillon par checksum (1% des fichiers)
find /mnt/cephfs/.snap/backup_$(date +%F_%H%M) -type f -print0 | \
  shuf -z -n $(($(find /mnt/cephfs/.snap/backup_$(date +%F_%H%M) -type f | wc -l) / 100)) | \
  xargs -0 sha256sum > /tmp/src_checksums.txt

find /backup/cephfs/backup_$(date +%F_%H%M) -type f -print0 | \
  xargs -0 sha256sum > /tmp/dst_checksums.txt

# Comparer (nécessite mêmes chemins relatifs)
diff -u /tmp/src_checksums.txt /tmp/dst_checksums.txt

Diagnostics de santé du cluster

Exécutez avant et après toute opération de sauvegarde/restauration :

ceph -s
ceph health detail
ceph pg dump_stuck inactive unclean stale undersized degraded
ceph osd df tree | grep -E 'osd\.[0-9]+' | awk '{if ($5 > 85) print $0}'

Signaux d'échec : HEALTH_ERR, PGs bloqués > 5 minutes, utilisation OSD > 85%. Ces indicateurs révèlent une instabilité du cluster qui peut corrompre les sauvegardes ou empêcher la restauration.

Modes d'échec et récupération

Cette section associe les scénarios d'échec courants à des procédures de récupération spécifiques avec commandes.

Scénario 1 : Corruption ou suppression accidentelle d'image RBD

Symptômes : rbd ls <pool> montre image manquante ; VM signale erreurs de lecture ; rbd info retourne "image not found".

Récupération depuis export complet :

# 1. Créer le pool cible si nécessaire (pg_num, pgp_num identiques à l'original)
ceph osd pool create <pool-restauration> <pg_num> <pgp_num> replicated
ceph osd pool set <pool-restauration> allow_ec_overwrites true

# 2. Importer l'image
rbd import --no-progress \
  /backup/rbd/<pool>_<image>_<timestamp>.img \
  <pool-restauration>/<image>

# 3. Vérifier
rbd info <pool-restauration>/<image>
rbd map <pool-restauration>/<image>  # Test de montage
rbd unmap /dev/rbd<X>

Récupération depuis chaîne incrémentale (si export complet est obsolète) :

# Importer l'export de base complet
rbd import --no-progress /backup/rbd/<pool>_<image>_base.img <pool-restauration>/<image>

# Appliquer chaque diff dans l'ordre chronologique
for diff in /backup/rbd/diff_<image>_*.diff; do
  rbd import-diff "$diff" <pool-restauration>/<image>
done

Retour arrière : rbd rm <pool-restauration>/<image> si la vérification échoue.

Scénario 2 : Perte de données CephFS (rm -rf accidentel)

Symptômes : arborescence de répertoire manquante ; erreurs d'application ; instantané existe encore.

Récupération :

# 1. Identifier le dernier instantané propre
ls -lt /mnt/cephfs/.snap/ | head -5

# 2. Restaurer via rsync depuis l'instantané vers le système de fichiers actif
rsync -avHAX --delete \
  /mnt/cephfs/.snap/backup_20240115_0200/ \
  /mnt/cephfs/donnees_restaurees/

# 3. Vérifier et permuter (rename atomique si même système de fichiers)
mv /mnt/cephfs/donnees_perdues /mnt/cephfs/donnees_perdues.corrompu
mv /mnt/cephfs/donnees_restaurees /mnt/cephfs/donnees_perdues

Rayon d'impact : arborescence de répertoire unique. Le cluster reste en ligne.

Scénario 3 : Corruption de base de données moniteur / perte de quorum

Symptômes : ceph -s bloque ou montre mon: 1 daemons, quorum <un-seul> ; ceph mon dump montre des trous d'époque.

Récupération (nécessite store.db de moniteur sauvegardé depuis un pair sain) :

# Sur le nœud moniteur défaillant (exemple cephadm)
systemctl stop ceph-mon@<hostname>

# Restaurer store.db depuis la sauvegarde
tar -xzf /backup/ceph-mon-<pair-host>-<date>.tar.gz -C / \
  var/lib/ceph/mon/ceph-<hostname>/store.db

# Corriger les permissions
chown -R ceph:ceph /var/lib/ceph/mon/ceph-<hostname>/

# Redémarrer
systemctl start ceph-mon@<hostname>

# Vérifier le quorum
ceph -s
ceph mon dump | grep -A5 "monmap"

Critique : restaurez depuis un moniteur qui était dans le quorum au moment de la sauvegarde. Ne restaurez jamais tous les moniteurs depuis la même sauvegarde simultanément — échelonnez de 30 secondes.

Scénario 4 : Reprise complète après sinistre cluster (nouveau matériel)

Prérequis : osd_dump.json, crushmap.txt, tarballs moniteurs, cephadm_spec.yaml, exports RBD/CephFS sauvegardés.

Procédure :

1. Déployez nouveaux nœuds OS avec même schéma hostname/IP
2. Bootstrap premier moniteur depuis la sauvegarde :

   cephadm bootstrap --mon-ip <nouvelle-ip> --config /backup/ceph.conf \
     --registry-url <registry> --initial-dashboard-user admin \
     --initial-dashboard-password <depuis-secret-store>

1. Restaurez store.db moniteur sur nœud bootstrap (comme Scénario 3)
2. Appliquez la carte CRUSH :

   crushtool -c /backup/crushmap_<date>.txt -o /tmp/crushmap_new.bin
   ceph osd setcrushmap -i /tmp/crushmap_new.bin

1. Recréez les pools depuis osd_dump.json (analysez pool_name, pg_num, pgp_num, type)
2. Importez images RBD et restaurez CephFS via rsync
3. Réappliquez cephadm_spec.yaml pour les démons :

   ceph orch apply -i /backup/cephadm_spec_<date>.yaml

Vérification : ceph -s montre HEALTH_OK, tous PGs active+clean, tous démons en cours d'exécution.

Liste de contrôle des opérations

Utilisez cette liste avant, pendant et après les opérations de sauvegarde/restauration.

Avant sauvegarde

• [ ] Santé cluster HEALTH_OK ou HEALTH_WARN (pas de HEALTH_ERR)
• [ ] Cible de sauvegarde vérifiée accessible en écriture avec espace suffisant (df -h /backup)
• [ ] Trousseau admin accessible ; ceph -s réussit
• [ ] Fenêtre de maintenance communiquée ; aucune opération conflictuelle planifiée
• [ ] Valeurs d'espaces réservés remplacées dans toutes les commandes (pool, image, hostname, dates)

Pendant la sauvegarde

• [ ] Capturer horodatage de début dans journal de sauvegarde
• [ ] Exécuter commande de sauvegarde avec --no-progress pour automatisation
• [ ] Surveiller santé cluster toutes les 5 minutes (watch -n 300 ceph -s)
• [ ] Vérifier chaque artefact immédiatement après création (taille, checksum, test d'analyse)
• [ ] Enregistrer horodatage de fin et durée

Après sauvegarde

• [ ] Copier artefacts vers domaine secondaire (hors site, zone de défaillance différente)
• [ ] Vérifier intégrité de la copie secondaire
• [ ] Mettre à jour inventaire de sauvegarde (feuille de calcul ou CMDB) avec emplacements, tailles, horodatages
• [ ] Purger sauvegardes plus anciennes que la politique de rétention (garder minimum 3 cycles complets)
• [ ] Documenter toute anomalie dans le runbook

Avant restauration

• [ ] Confirmer que la version du cluster cible correspond ou dépasse la version de sauvegarde
• [ ] Vérifier intégrité de l'artefact de sauvegarde (checksums, rbd info, tar -tzf)
• [ ] Isoler namespace/pool cible (empêcher écritures client pendant restauration)
• [ ] Documenter plan de retour : rbd rm, rsync --delete, redémarrage moniteur

Après restauration

• [ ] Exécuter vérification complète (procédures Section 3)
• [ ] Valider connectivité application et intégrité des données
• [ ] Surveiller santé cluster pendant 30 minutes post-restauration
• [ ] Mettre à jour runbook avec durées réelles et écarts éventuels
• [ ] Notifier les parties prenantes de la finalisation

Conclusion

La fiabilité de la sauvegarde et restauration Ceph provient de procédures adaptées aux versions, d'étapes de vérification observables et de chemins de récupération testés — non de la copie de commandes sans contexte. Ce guide a couvert les exports RBD et chaînes de diff incrémentales, les flux de travail instantané CephFS plus rsync, la capture de configuration du cluster et la reprise complète après sinistre sur nouveau matériel. Chaque procédure inclut prérequis, évaluation du rayon d'impact, sortie attendue, signaux d'échec et commande de retour arrière.

Comme prochaine étape, sélectionnez une vérification à faible risque : exportez une seule image RBD non-production, importez-la vers un pool de vérification, comparez la sortie rbd info, et nettoyez. Enregistrez la durée et tout écart. Étendez ensuite le même motif à la validation d'instantané CephFS et aux exercices de restauration store.db moniteur sur un cluster de staging. Un flux de travail fiable rend l'échec visible, protège les valeurs sensibles, limite les changements à la ressource visée et définit la vérification de récupération avant qu'un incident ne force la décision.