Restaurer une sauvegarde
Restaurez les bases de données PostgreSQL d'IBM Bob à partir d'une sauvegarde pour récupérer après une perte de données, migrer des environnements ou revenir à un état stable connu.
Utilisez cette procédure pour restaurer IBM Bob et les bases de données PostgreSQL associées à partir de fichiers de sauvegarde. Le processus de restauration comprend la validation de l'intégrité de la sauvegarde, la préparation de l'environnement, la recréation de la base de données cible, la restauration du contenu de la sauvegarde et la vérification des données restaurées avant de remettre en service les services applicatifs.
La restauration d'une base de données remplace le contenu actuel de la base de données par les données du fichier de sauvegarde sélectionné. Les services applicatifs doivent être arrêtés avant de commencer, car les écritures actives sur la base de données peuvent corrompre le processus de restauration. Testez toujours les procédures de restauration dans un environnement hors production avant d'effectuer une reprise en production.
Avant de commencer
Avant de restaurer une base de données, vérifiez les points suivants :
Vérifier l'intégrité de la sauvegarde
# Accéder au PVC de sauvegarde
oc run backup-verify -n <bob-instance-namespace> --image=busybox --rm -it --restart=Never \
--overrides='{
"spec": {
"containers": [{
"name": "backup-verify",
"image": "busybox",
"command": ["sh"],
"stdin": true,
"tty": true,
"volumeMounts": [{
"name": "backup",
"mountPath": "/backups"
}]
}],
"volumes": [{
"name": "backup",
"persistentVolumeClaim": {
"claimName": "bob-db-backup-pvc"
}
}]
}
}'
# À l'intérieur du pod :
cd /backups/bob-db
gunzip -t backup_bob_20260902_020000.sql.gz # Tester l'intégrité gzip
cat backup_bob_20260902_020000.sql.gz.meta # Vérifier les métadonnéesConfirmer les détails de la sauvegarde
- L'horodatage de la sauvegarde correspond au point de restauration attendu.
- Le nom de la base de données est correct.
- La taille de la sauvegarde est raisonnable.
- Le fichier de métadonnées existe et est lisible.
Créer une sauvegarde préalable à la restauration
Avant de restaurer, sauvegardez l'état actuel de la base de données :
oc exec -n <bob-instance-namespace> bob-db-1 -- \
pg_dump -U postgres bob | gzip > pre-restore-backup-$(date +%Y%m%d_%H%M%S).sql.gzProcédure de restauration
Arrêtez tous les services applicatifs IBM Bob pour éviter les écritures sur la base de données pendant la restauration.
# Réduire les services Bob à zéro réplica
oc scale deployment bob-admin-service --replicas=0 -n <bob-instance-namespace>
oc scale deployment bob-api-service --replicas=0 -n <bob-instance-namespace>
oc scale deployment bob-ui-service --replicas=0 -n <bob-instance-namespace>
# Vérifier que les pods sont arrêtés
oc get pods -n <bob-instance-namespace> -l app.kubernetes.io/name=bobCréez un pod de restauration temporaire ayant accès à la fois à la base de données PostgreSQL et à l'emplacement de stockage de la sauvegarde.
# Obtenir l'image PostgreSQL
POSTGRES_IMAGE=$(oc get cluster bob-db -n <bob-instance-namespace> -o jsonpath='{.spec.imageName}')
# Créer le pod de restauration
oc run postgres-restore -n <bob-instance-namespace> --image=$POSTGRES_IMAGE --rm -it --restart=Never \
--overrides='{
"spec": {
"containers": [{
"name": "restore",
"image": "'$POSTGRES_IMAGE'",
"command": ["bash"],
"stdin": true,
"tty": true,
"env": [
{"name": "PGHOST", "value": "bob-db-rw"},
{"name": "PGPORT", "value": "5432"},
{"name": "PGUSER", "value": "postgres"},
{"name": "PGPASSWORD", "valueFrom": {"secretKeyRef": {"name": "bob-db-app", "key": "password"}}}
],
"volumeMounts": [{
"name": "backup",
"mountPath": "/backups"
}]
}],
"volumes": [{
"name": "backup",
"persistentVolumeClaim": {
"claimName": "bob-db-backup-pvc"
}
}]
}
}'À l'intérieur du pod de restauration, vérifiez le fichier de sauvegarde et testez la connexion à la base de données :
# Lister les sauvegardes disponibles
ls -lh /backups/bob-db/
# Vérifier le fichier de sauvegarde
BACKUP_FILE="/backups/bob-db/backup_bob_20260902_020000.sql.gz"
gunzip -t $BACKUP_FILE
echo "Backup file is valid"
# Vérifier les métadonnées
cat ${BACKUP_FILE}.meta
# Tester la connexion à la base de données
psql -c "SELECT version();"Pour la plupart des scénarios de reprise, restaurez dans une base de données vide pour vous assurer que les données obsolètes ou en conflit sont supprimées.
Cette étape supprime définitivement le contenu actuel de la base de données.
psql -c "DROP DATABASE IF EXISTS bob;"
psql -c "CREATE DATABASE bob;"Restaurez la base de données en chargeant le contenu de la sauvegarde dans PostgreSQL :
# Extraire et restaurer la sauvegarde
gunzip -c $BACKUP_FILE | psql -d bob
# Cela peut prendre plusieurs minutes selon la taille de la sauvegardeAvant de remettre l'application en service, vérifiez que la restauration s'est terminée avec succès :
# Se connecter à la base de données restaurée
psql -d bob
# Vérifier que les tables existent
\dt
# Vérifier le nombre de lignes pour les tables principales
SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM projects;
SELECT COUNT(*) FROM conversations;
# Vérifier les données récentes
SELECT * FROM users ORDER BY created_at DESC LIMIT 10;
# Quitter psql
\qUne fois la validation de la base de données terminée avec succès, redémarrez les services IBM Bob et laissez-les se reconnecter à la base de données restaurée. Surveillez les journaux de démarrage de l'application pour détecter d'éventuelles erreurs ou échecs de migration.
# Quitter le pod de restauration
exit
# Remettre à l'échelle les services Bob
oc scale deployment bob-admin-service --replicas=1 -n <bob-instance-namespace>
oc scale deployment bob-api-service --replicas=3 -n <bob-instance-namespace>
oc scale deployment bob-ui-service --replicas=2 -n <bob-instance-namespace>
# Vérifier que les pods sont en cours d'exécution
oc get pods -n <bob-instance-namespace> -l app.kubernetes.io/name=bob
# Vérifier les journaux applicatifs
oc logs -n <bob-instance-namespace> -l app.kubernetes.io/name=bob --tail=50Effectuez une validation applicative de bout en bout avant d'autoriser les utilisateurs à se reconnecter :
# Tester les endpoints applicatifs
curl -k https://bob.example.com/health
# Vérifier que la connexion des utilisateurs fonctionne
# Vérifier que l'accès aux données fonctionne
# Vérifier que les fonctionnalités principales fonctionnentUne validation réussie indique que le processus de restauration est terminé.
Bonnes pratiques
- Testez toujours d'abord dans un environnement hors production.
- Créez une sauvegarde préalable de l'état actuel de la base de données avant de commencer.
- Vérifiez l'intégrité de la sauvegarde avant de démarrer.
- Planifiez l'interruption de service et communiquez avec les utilisateurs.
- Documentez le processus de restauration et les résultats.
- Vérifiez l'intégrité des données après la restauration.
- Surveillez attentivement l'application après la restauration.
Problèmes de restauration courants
| Problème | Cause | Solution |
|---|---|---|
| Espace insuffisant | Pas assez d'espace disque pour l'opération de restauration | Augmentez la taille du PVC ou libérez de l'espace de stockage avant de restaurer. |
| Timeout de connexion | Problèmes de connectivité réseau ou d'indisponibilité de la base de données | Vérifiez la connectivité à la base de données et augmentez les valeurs de timeout si nécessaire. |
| Erreurs d'autorisation | L'utilisateur de restauration ne dispose pas des privilèges de base de données requis | Accordez les autorisations nécessaires à l'utilisateur de restauration avant d'exécuter l'opération de restauration. |