Planification de la reprise après sinistre
RPO, RTO et procédures opérationnelles.
Planification de la reprise après sinistre est une leçon SQL Academy gratuite sur CoddyKit. Ceci est la leçon 4 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.
Qu'est-ce que la reprise après sinistre ?
La reprise après sinistre (DR) est l'ensemble des politiques, outils et procédures conçus pour permettre la récupération des infrastructures et systèmes technologiques essentiels après un sinistre naturel ou d'origine humaine.
Dans le contexte des bases de données, la planification de la DR garantit la sécurité de vos données et la remise en service de vos systèmes dans des délais acceptables après des événements tels qu'une panne matérielle, une suppression accidentelle de données, une attaque par rançongiciel ou une panne du centre de données.
Objectif de point de reprise (RPO)
RPO définit la quantité maximale acceptable de données perdue, mesurée en durée. Si votre RPO est d'une heure, vous devez pouvoir récupérer les données jusqu'à au moins une heure avant le sinistre.
Un RPO plus court exige des sauvegardes plus fréquentes ou une réplication continue. Vous pouvez interroger l'historique de vos sauvegardes pour vérifier que vous respectez votre cible de RPO.
-- Check the last backup time and calculate data loss window
SELECT
backup_id,
backup_type,
started_at,
finished_at,
EXTRACT(EPOCH FROM (NOW() - finished_at)) / 3600 AS hours_since_backup
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at DESC
LIMIT 5;Objectif de délai de reprise (RTO)
RTO définit la durée maximale pendant laquelle votre système peut rester hors ligne après un sinistre. Si votre RTO est de quatre heures, votre base de données doit être pleinement opérationnelle dans les quatre heures suivant la panne.
Le RTO guide les choix concernant les serveurs de secours, l'automatisation de la bascule et les procédures de restauration. Le suivi des durées de restauration au fil du temps vous aide à prévoir si vous pourrez respecter votre RTO.
-- Track restore durations to validate RTO compliance
SELECT
restore_id,
triggered_at,
completed_at,
EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 60 AS restore_minutes,
CASE
WHEN EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 3600 <= 4
THEN 'WITHIN RTO'
ELSE 'RTO BREACHED'
END AS rto_status
FROM restore_log
ORDER BY triggered_at DESC;RPO ou RTO — la différence essentielle
Ces deux métriques sont souvent confondues. Voici la manière la plus simple de les retenir :
- RPO = Quelle quantité de données pouvez-vous vous permettre de perdre ? (rétrospectif, mesuré en durée avant le sinistre)
- RTO = Combien de temps pouvez-vous vous permettre de rester hors ligne ? (prospectif, mesuré en durée après le sinistre)
Ensemble, ils définissent votre fenêtre de reprise et influencent directement la fréquence de vos sauvegardes, votre stratégie de réplication et votre budget d'infrastructure.
-- Store RPO and RTO targets per database in a DR configuration table
CREATE TABLE dr_config (
db_name VARCHAR(100) PRIMARY KEY,
rpo_minutes INT NOT NULL,
rto_minutes INT NOT NULL,
tier VARCHAR(20) CHECK (tier IN ('CRITICAL', 'HIGH', 'MEDIUM', 'LOW')),
updated_at TIMESTAMP DEFAULT NOW()
);
INSERT INTO dr_config (db_name, rpo_minutes, rto_minutes, tier) VALUES
('orders_db', 15, 60, 'CRITICAL'),
('analytics_db', 120, 240, 'MEDIUM'),
('archive_db', 480, 480, 'LOW');Types de sauvegardes
Il existe trois stratégies principales de sauvegarde, chacune établissant un compromis entre rapidité et espace de stockage :
- Sauvegarde complète : un instantané complet de toute la base de données. C'est la plus lente à créer, mais la plus rapide à restaurer.
- Sauvegarde différentielle : uniquement les modifications effectuées depuis la dernière sauvegarde complète. Sa création et sa restauration prennent un temps intermédiaire.
- Sauvegarde incrémentielle : uniquement les modifications effectuées depuis la dernière sauvegarde, quel qu'en soit le type. C'est la plus rapide à créer, mais la plus lente à restaurer, car plusieurs fichiers sont nécessaires.
La plupart des stratégies de DR combinent des sauvegardes complètes hebdomadaires avec des sauvegardes incrémentielles quotidiennes afin d'équilibrer le RPO et le coût du stockage.
-- Log each backup with its type for audit and recovery planning
CREATE TABLE backup_log (
backup_id SERIAL PRIMARY KEY,
db_name VARCHAR(100) NOT NULL,
backup_type VARCHAR(20) CHECK (backup_type IN ('FULL', 'DIFFERENTIAL', 'INCREMENTAL')),
started_at TIMESTAMP NOT NULL,
finished_at TIMESTAMP,
size_mb NUMERIC(12, 2),
status VARCHAR(20) DEFAULT 'IN_PROGRESS'
);
INSERT INTO backup_log (db_name, backup_type, started_at, finished_at, size_mb, status) VALUES
('orders_db', 'FULL', '2024-06-01 01:00:00', '2024-06-01 02:15:00', 45200, 'SUCCESS'),
('orders_db', 'INCREMENTAL', '2024-06-02 01:00:00', '2024-06-02 01:08:00', 320, 'SUCCESS'),
('orders_db', 'INCREMENTAL', '2024-06-03 01:00:00', '2024-06-03 01:07:00', 290, 'SUCCESS');Récupération à un instant donné (PITR)
La récupération à un instant donné permet de restaurer une base de données à n'importe quel instant précis, et pas seulement au moment de la dernière sauvegarde. Elle est obtenue en rejouant les journaux de transactions (WAL dans PostgreSQL) par-dessus une sauvegarde de base.
La PITR est essentielle lorsque vous devez vous remettre d'une corruption ou d'une suppression accidentelle de données survenue à un instant connu. Vous pouvez restaurer la base juste avant l'événement dommageable.
-- Record WAL archive events for PITR tracking
CREATE TABLE wal_archive_log (
segment_name VARCHAR(200) PRIMARY KEY,
archived_at TIMESTAMP DEFAULT NOW(),
size_bytes BIGINT,
storage_path TEXT
);
-- Find all WAL segments archived within a recovery window
SELECT
segment_name,
archived_at,
ROUND(size_bytes / 1024.0 / 1024.0, 2) AS size_mb
FROM wal_archive_log
WHERE archived_at BETWEEN '2024-06-03 09:00:00' AND '2024-06-03 11:00:00'
ORDER BY archived_at;Bases de données de secours et réplication
Une base de données de secours (réplique) est une copie de la base de données primaire, mise à jour en continu et hébergée sur un matériel distinct. Elle remplit deux fonctions de DR :
- Secours à chaud : peut accepter des requêtes de lecture et effectuer une bascule en quelques secondes (RTO quasi nul).
- Secours en attente : reste synchronisé, mais ne sert aucun trafic ; la bascule prend plusieurs minutes.
La surveillance du retard de réplication est essentielle — une réplique en retard signifie que votre RPO réel est moins bon que prévu.
-- Monitor replication lag on a PostgreSQL primary
SELECT
client_addr,
application_name,
state,
sent_lsn,
replay_lsn,
(sent_lsn - replay_lsn) AS lag_bytes,
EXTRACT(EPOCH FROM (NOW() - reply_time)) AS seconds_since_reply
FROM pg_stat_replication
ORDER BY lag_bytes DESC;Guides opératoires : documenter les procédures de récupération
Un guide opératoire est un ensemble documenté d'instructions étape par étape que l'opérateur suit lors d'un événement de reprise après sinistre. Sans guide opératoire, même des administrateurs de bases de données expérimentés commettent des erreurs coûteuses sous la pression.
Un bon guide opératoire de DR précise notamment qui contacter, quels systèmes sont concernés, les commandes exactes à exécuter, les résultats attendus à chaque étape et les procédures de retour en arrière si la récupération échoue. Le stockage des métadonnées du guide opératoire dans une base de données aide à suivre les versions et à contrôler son utilisation.
-- Store runbook metadata in the database for audit tracking
CREATE TABLE runbook (
runbook_id SERIAL PRIMARY KEY,
title VARCHAR(200) NOT NULL,
scenario VARCHAR(100),
version VARCHAR(20) DEFAULT '1.0',
last_tested DATE,
owner VARCHAR(100),
doc_url TEXT
);
INSERT INTO runbook (title, scenario, version, last_tested, owner, doc_url) VALUES
('Full Database Restore from S3', 'total_loss', '2.1', '2024-05-15', 'dba_team', 'https://wiki.internal/dr/full-restore'),
('Failover to Hot Standby', 'primary_down', '1.4', '2024-04-20', 'dba_team', 'https://wiki.internal/dr/failover'),
('PITR to Specific Timestamp', 'data_corruption','1.2', '2024-03-10', 'dba_team', 'https://wiki.internal/dr/pitr');Journalisation de l'exécution des guides opératoires
Chaque fois qu'un guide opératoire est exécuté — que ce soit lors d'un sinistre réel ou d'un exercice — son exécution doit être consignée. Les journaux d'exécution permettent de mesurer la durée réelle de la récupération (pour valider votre RTO), d'identifier les étapes lentes ou sujettes aux erreurs et de démontrer votre conformité aux auditeurs.
-- Log each runbook execution for RTO validation and audit
CREATE TABLE runbook_execution (
execution_id SERIAL PRIMARY KEY,
runbook_id INT REFERENCES runbook(runbook_id),
triggered_by VARCHAR(100),
is_drill BOOLEAN DEFAULT FALSE,
started_at TIMESTAMP NOT NULL,
completed_at TIMESTAMP,
outcome VARCHAR(20) CHECK (outcome IN ('SUCCESS', 'PARTIAL', 'FAILED'))
);
-- Report average restore time per runbook
SELECT
r.title,
COUNT(*) AS executions,
ROUND(AVG(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60), 1) AS avg_minutes,
MAX(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60) AS max_minutes
FROM runbook_execution e
JOIN runbook r ON r.runbook_id = e.runbook_id
WHERE e.outcome = 'SUCCESS'
GROUP BY r.title;Tests de DR : exercices réguliers
Un plan de DR qui n'a jamais été testé n'est pas un plan — c'est un simple souhait. Des exercices réguliers sont indispensables pour garantir que votre équipe peut réellement exécuter les guides opératoires dans le RTO défini et que les sauvegardes peuvent véritablement être restaurées.
La planification et le suivi des exercices dans votre base de données créent une piste d'audit et vous aident à repérer les guides opératoires dont le test est en retard.
-- Find runbooks that have not been drilled in over 90 days
SELECT
r.runbook_id,
r.title,
r.scenario,
MAX(e.completed_at) AS last_drill,
CURRENT_DATE - MAX(e.completed_at::DATE) AS days_since_drill
FROM runbook r
LEFT JOIN runbook_execution e
ON e.runbook_id = r.runbook_id
AND e.is_drill = TRUE
AND e.outcome = 'SUCCESS'
GROUP BY r.runbook_id, r.title, r.scenario
HAVING MAX(e.completed_at) IS NULL
OR CURRENT_DATE - MAX(e.completed_at::DATE) > 90
ORDER BY days_since_drill DESC NULLS FIRST;Politiques de rétention des sauvegardes
Les politiques de rétention définissent la durée de conservation des sauvegardes. Conserver chaque sauvegarde indéfiniment gaspille de l'espace de stockage ; les supprimer trop rapidement enfreint votre RPO et les exigences de conformité.
Une politique courante consiste à conserver les sauvegardes incrémentielles quotidiennes pendant 7 jours, les sauvegardes complètes hebdomadaires pendant 4 semaines et les sauvegardes complètes mensuelles pendant 12 mois. Vous pouvez appliquer et contrôler la rétention avec des requêtes SQL sur votre journal de sauvegardes.
-- Identify backups that are outside their retention window and ready to purge
SELECT
backup_id,
db_name,
backup_type,
finished_at,
CURRENT_DATE - finished_at::DATE AS age_days,
CASE backup_type
WHEN 'INCREMENTAL' THEN 7
WHEN 'DIFFERENTIAL' THEN 28
WHEN 'FULL' THEN 365
END AS retention_days,
CASE
WHEN (CURRENT_DATE - finished_at::DATE) >
CASE backup_type
WHEN 'INCREMENTAL' THEN 7
WHEN 'DIFFERENTIAL' THEN 28
WHEN 'FULL' THEN 365
END
THEN 'PURGE'
ELSE 'KEEP'
END AS action
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at;Vérification rapide
Vérifiez votre compréhension des définitions de RPO et de RTO.
Récapitulatif : planification de la reprise après sinistre
Dans cette leçon, vous avez exploré les fondements de la planification de la reprise après sinistre d'une base de données :
- RPO définit la perte de données maximale tolérable dans le temps ; un RPO plus court nécessite des sauvegardes plus fréquentes ou une réplication continue.
- RTO définit la rapidité avec laquelle le système doit être restauré ; un RTO plus court exige des systèmes de secours à chaud et un basculement automatisé.
- Les types de sauvegarde — complète, différentielle et incrémentielle — offrent chacun un compromis différent entre l'espace de stockage, la vitesse de création et la vitesse de restauration.
- PITR (récupération à un instant donné) utilise les journaux de transactions pour restaurer les données à n'importe quel instant précis et se protéger contre les modifications accidentelles.
- Les guides opératoires documentent chaque étape d'une procédure de récupération ; journaliser les exécutions permet de vérifier que votre RTO est atteignable en pratique.
- Les exercices DR réguliers sont le seul moyen de confirmer que les sauvegardes peuvent être restaurées et que votre équipe peut atteindre les objectifs de RPO et de RTO dans des conditions réellement stressantes.
- Les politiques de conservation établissent un équilibre entre le coût du stockage, les exigences de conformité et les besoins de récupération.
Un plan DR soigneusement vérifié est l'un des investissements les plus précieux qu'une équipe chargée d'une base de données puisse réaliser.
Questions Fréquemment Posées
La leçon « Planification de la reprise après sinistre » est-elle gratuite ?
Oui — le texte complet de « Planification de la reprise après sinistre » 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 « Planification de la reprise après sinistre » ?
RPO, RTO et procédures opérationnelles. 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 4 sur 4.
Combien de temps prend la leçon « Planification de la reprise après sinistre » ?
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