SQL Academy · Leçon

Tester vos restaurations

Une sauvegarde que vous ne pouvez pas restaurer ne sert à rien.

Tester vos restaurations est une leçon SQL Academy gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage SQL Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours SQL Academy comprend 4 leçons au total.

Une sauvegarde impossible à restaurer ne vaut rien

De nombreuses équipes consacrent du temps à mettre en place des sauvegardes automatisées, mais ne vérifient jamais si elles peuvent réellement être utilisées pour récupérer les données. Une sauvegarde qui échoue lors de la restauration n'est pas une sauvegarde.

Cette leçon présente la rigueur des tests de restauration : comment vérifier que vos sauvegardes fonctionnent avant qu'un véritable sinistre ne vous oblige à le découvrir dans les pires conditions.

En quoi consiste un test de restauration ?

Un test de restauration consiste à prendre un fichier de sauvegarde et à le charger dans une base de données — généralement une instance de test distincte — puis à interroger cette base pour confirmer que les données sont complètes et cohérentes.

Les étapes sont les suivantes : 1) Obtenez le fichier de sauvegarde. 2) Restaurez-le dans un environnement isolé. 3) Exécutez les requêtes de validation. 4) Comparez les résultats avec ceux de la production.

Créer un instantané de référence pour la comparaison

Avant de pouvoir vérifier une restauration, vous avez besoin d'une référence — un ensemble connu de nombres de lignes et de sommes de contrôle issus de la production, auquel vous pourrez comparer la copie restaurée.

Exécutez ceci sur votre base de données de production et consignez les résultats :

SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

Vérifier le nombre de lignes après une restauration

Une fois la sauvegarde restaurée dans une base de données de test, exécutez la même requête et comparez les nombres. Si les comptes correspondent, la structure fondamentale de la restauration est saine.

Une différence vous indique immédiatement que des données ont été perdues pendant la sauvegarde ou la restauration — avant même que vous touchiez à la production.

-- Run on the RESTORED test database
SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

Vérifier les données les plus récentes

Le nombre de lignes confirme la quantité, mais pas l'actualité des données. Vérifiez que la base de données restaurée contient des enregistrements récents — la sauvegarde doit refléter les données jusqu'au moment où elle a été effectuée.

SELECT
  MAX(created_at) AS latest_order,
  MIN(created_at) AS oldest_order,
  COUNT(*)        AS total_orders
FROM orders;

Valider l'intégrité référentielle

Même si le nombre de lignes correspond, une restauration peut laisser des lignes orphelines — des enregistrements enfants dont le parent n'existe plus. Cela se produit souvent lorsque les clés étrangères ne sont pas appliquées pendant la sauvegarde ou la restauration.

Utilisez un LEFT JOIN pour détecter les articles de commande orphelins :

SELECT
  oi.id       AS orphaned_item_id,
  oi.order_id AS missing_order_id
FROM order_items oi
LEFT JOIN orders o ON o.id = oi.order_id
WHERE o.id IS NULL;

Utiliser une somme de contrôle pour détecter la corruption

Pour les tables critiques, générez une somme de contrôle des données afin de détecter une corruption au niveau des bits. Dans PostgreSQL, vous pouvez combiner MD5 avec une conversion de type de la ligne entière.

Si la somme de contrôle de la production diffère de celle de la copie restaurée, les données ont été modifiées ou corrompues à un moment donné.

SELECT
  MD5(string_agg(row_data, ',' ORDER BY row_data)) AS table_checksum
FROM (
  SELECT CAST(ROW(id, customer_id, total, created_at) AS TEXT) AS row_data
  FROM orders
) sub;

Créer une table de validation des restaurations

Pour suivre l'historique de vos tests de restauration, créez une table dédiée au journal de validation. Consignez chaque test avec la date de la sauvegarde, le nombre de lignes restaurées et la réussite ou l'échec de la validation.

CREATE TABLE IF NOT EXISTS restore_validation_log (
  id             SERIAL PRIMARY KEY,
  backup_taken_at TIMESTAMP NOT NULL,
  restored_at    TIMESTAMP NOT NULL DEFAULT NOW(),
  table_name     VARCHAR(100) NOT NULL,
  expected_rows  INT NOT NULL,
  actual_rows    INT NOT NULL,
  passed         BOOLEAN NOT NULL
);

Insérer un résultat de validation

Après chaque test de restauration, insérez une ligne dans le journal de validation. Vous disposerez ainsi d'une piste d'audit prouvant que les sauvegardes ont été testées et montrant l'évolution des réussites et des échecs au fil du temps.

INSERT INTO restore_validation_log
  (backup_taken_at, table_name, expected_rows, actual_rows, passed)
VALUES
  ('2024-06-09 02:00:00', 'orders',      15482, 15482, TRUE),
  ('2024-06-09 02:00:00', 'customers',    8201,  8201,  TRUE),
  ('2024-06-09 02:00:00', 'order_items', 47310, 47310, TRUE);

Interroger l'historique de validation

Consultez régulièrement le journal de validation pour repérer toute régression. Une sauvegarde qui a réussi la semaine dernière mais échoue cette semaine révèle un problème dans votre chaîne de traitement des sauvegardes, qui doit être examiné immédiatement.

SELECT
  backup_taken_at,
  table_name,
  expected_rows,
  actual_rows,
  passed,
  CASE
    WHEN passed THEN 'OK'
    ELSE 'MISMATCH - investigate!'
  END AS status
FROM restore_validation_log
ORDER BY backup_taken_at DESC, table_name;

Vérification de la récupération à un instant donné

Les bases de données modernes prennent en charge la récupération à un instant donné (PITR), qui permet de restaurer une base de données à n'importe quel instant en utilisant une sauvegarde de base et des archives de WAL (journal d'écriture anticipée).

Pour vérifier que PITR fonctionne, restaurez jusqu'à un horodatage connu et vérifiez l'absence (NOT) d'un enregistrement créé après cet horodatage dans la base de données restaurée :

-- After a PITR restore to '2024-06-09 03:00:00',
-- this order (created at 03:45) should NOT exist:
SELECT id, created_at, total
FROM orders
WHERE created_at > '2024-06-09 03:00:00'
ORDER BY created_at
LIMIT 5;
-- Zero rows = PITR worked correctly

Vérification rapide

Laquelle des requêtes suivantes est la plus utile pour détecter des enregistrements enfants orphelins après la restauration d'une sauvegarde ?

Récapitulatif de la leçon : tester vos restaurations

Dans cette leçon, vous avez appris pourquoi les tests de restauration sont indispensables à toute stratégie de sauvegarde et comment les mettre en œuvre avec SQL :

Instantanés de référence — consignez le nombre de lignes en production avant les tests.
Comparaison du nombre de lignes — exécutez la même requête sur la base de données restaurée et comparez les résultats.
Vérification de l'actualité — confirmez que les enregistrements les plus récents correspondent à la fenêtre de sauvegarde attendue.
Intégrité référentielle — utilisez LEFT JOIN pour trouver les lignes enfants orphelines.
Validation par somme de contrôle — détectez la corruption au niveau des bits avec des agrégats MD5.
Table du journal de validation — suivez chaque test pour conserver un historique vérifiable.
Vérification de PITR — confirmez que la récupération à un instant donné aboutit au bon moment.

Une sauvegarde n'est aussi fiable que le dernier test de restauration réussi. Planifiez régulièrement ces vérifications et considérez tout échec comme un incident critique.

Questions Fréquemment Posées

La leçon « Tester vos restaurations » est-elle gratuite ?

Oui — le texte complet de « Tester vos restaurations » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours SQL Academy, passe à CoddyKit PRO. Le cours SQL Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Tester vos restaurations » ?

Une sauvegarde que vous ne pouvez pas restaurer ne sert à rien. Tu pratiques SQL Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer SQL Academy ?

Aucune expérience préalable n'est requise. SQL Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Tester vos restaurations » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon SQL Academy ?

Oui. Chaque leçon SQL Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

Sauvegardes logiques ou physiques
Récupération à un instant donné
Tester vos restaurations
Planification de la reprise après sinistre

← Retour à SQL Academy