RETOUR D’EXPÉRIENCE /

Faire du restore test le critère d’acceptation d’un backup

Introduction

Une commande de backup qui termine sans erreur n’implique pas automatiquement que l’application peut être restaurée à un état fonctionnel antérieur. Le document formalisé du projet recommande de n’accepter la capacité de disaster recovery qu’après une restauration et des tests fonctionnels.

Symptômes observés

  • L’intégrité de l’archive et de la base restait à démontrer.
  • Les étapes destructives exigeaient des mécanismes de préflight, de confirmation et de cleanup.

Contexte technique

Plusieurs workloads disposent déjà de scripts de restauration et de runbooks. Le besoin est d’extraire un critère d’acceptation clair : un backup est considéré valable seulement s’il a été vérifié par un restore effectif et des checks fonctionnels.

Diagnostic

Le diagnostic principal est que la création d’un artefact ne valide que l’écriture de données (présence du fichier, taille non nulle, etc.) sans garantir la capacité à reprendre l’application. Des préchecks elementaires sur l’artefact existent dans les scripts, mais ils ne prouvent pas la complétude du processus de restauration.

Cause racine

La cause racine est que l’acceptation d’un backup s’appuie sur des signes d’écriture correcte plutôt que sur une restauration complète validée par des tests fonctionnels.

Solution retenue

La décision consiste à ajouter une étape d’acceptation qui inclut : validation d’intégrité des artefacts avant remplacement, restauration sur jeux de données synthétiques, garanties de cleanup et de redémarrage des services, puis vérifications fonctionnelles aboutissant à l’acceptation ou au rejet du backup.

Les préconditions et les confirmations font désormais partie du design de restore : les scripts doivent refuser de continuer si des artefacts manquent ou semblent vides, vérifier l’existence des services nécessaires, préparer un répertoire de restauration, exécuter la restauration, puis effectuer des contrôles post-restore.

Exemple pédagogique : éléments de checks et cleanup

Le fragment ci-dessous est une représentation pédagogique et minimale illustrant les types de vérifications rencontrées dans les scripts du projet (présence d’archives, vérification de conteneurs, extraction, trap de cleanup, contrôle basique de la base restaurée). Ce n’est pas une reproduction exacte du contenu du dépôt.

if [[ ! -s "${DUMP_FILE}" ]]; then
  echo "ERROR: database dump missing or empty" >&2
  exit 1
fi

if ! docker inspect "${DB_CONTAINER}" >/dev/null 2>&1; then
  echo "ERROR: DB container not found" >&2
  exit 1
fi

rm -rf "${RESTORE_DIR}"
mkdir -p "${RESTORE_DIR}"

tar -xzf "${CONTENT_FILE}" -C "${RESTORE_DIR}"

trap 'rm -rf "${RESTORE_DIR}"; docker start "${WP_CONTAINER}" >/dev/null || true' EXIT

# contrôle pédagogique : vérifier au moins la présence de tables
TABLE_COUNT="$(docker exec "${DB_CONTAINER}" some-db-client -N -e "SELECT COUNT(*) FROM ...;")"
if ! [[ "${TABLE_COUNT}" =~ ^[1-9][0-9]*$ ]]; then
  echo "ERROR: restored database contains no tables" >&2
  exit 1
fi

Validation

La validation opérationnelle combine restaurations sur données synthétiques et scénarios de montée en charge limités pour prouver que le rollback fonctionne, que le cleanup supprime les artefacts temporaires et que les services redémarrent correctement. Le dossier de sortie du projet suggère explicitement d’injecter des corruptions pour prouver le rollback, le cleanup et le redémarrage.

Enseignements

  • Un backup n’est accepté qu’après une restauration testée.
  • Les préconditions et les confirmations sont des éléments constitutifs du design de restore.
  • Ajouter des tests de restauration augmente le temps de validation, mais réduit significativement le risque d’une fausse sécurité.

Un backup n’est accepté qu’après une restauration testée.

Pattern réutilisable

  1. Effectuer des préflight checks sur les artefacts (existence, taille, format).
  2. Vérifier la disponibilité des services nécessaires à la restauration.
  3. Restaurer sur un environnement contenant des données synthétiques ou isolées.
  4. Exécuter des vérifications fonctionnelles minimales (présence de tables, existence de répertoires, endpoints de sanity).
  5. Garantir un mécanisme de cleanup et de redémarrage automatique en cas d’échec ou à la fin du test.
  6. N’accepter le backup que si toutes les étapes précédentes réussissent.

Conclusion

Transformer le restore en critère d’acceptation d’un backup est une décision qui priorise la sécurité opérationnelle au prix d’efforts supplémentaires de test. La pratique réduit le risque d’une confiance illusoire dans les procédures de backup et fournit un cadre réutilisable pour d’autres workloads.