Disaster Recovery и cold-backups

Résumé succinct

Le DR est la capacité de rétablir les fonctions de l'entreprise après un accident majeur. Cold-backups est la « dernière ligne de défense » : copie immuable/isolée, apte à être restaurée lorsque le site est complètement déconnecté ou compromis. La stratégie s'articule autour du RTO/RPO, de la hiérarchisation des systèmes, des exercices annuels de RD et d'une discipline opérationnelle rigoureuse (catalogues, clés, vérifications).

Termes et objectifs

RPO (Recovery Point Objective) - la perte au maximum admissible des données (par ex., ≤ 15 mines).
RTO (Recovery Time Objective) est le temps de récupération maximal autorisé (par exemple, ≤ 2 h).
Black-start - Récupération « à partir de zéro » : fer/cluster/secrets/données/DNS.
Air-gap - isolation physique/logique des copies (bande/compte déconnecté/média hors ligne).
Immutabilité (WORM) est un stockage immuable (ruban/objet avec Lock/Retentation).

Niveaux de préparation DR

Cold Site - infrastructure manquante/gelée ; RTO : heures-jours ; Le CAPEX/OPEX le moins cher.
Site Warm - modèles/images/services partiellement prêts ; RTO : des dizaines de minutes-heures.
Hot Site - répliques actives ; RTO : minutes ; plus cher et plus complexe.
Hybride : noyau → hot/warm, tout le reste → cold (avec priorité au démarrage).

Où le cold-backups est indispensable

Cryptosaration de masse/compromission de domaine.
La corruption des données est partie pour toutes les répliques.
Perte de région/centre de données, force majeure (incendie, inondation).
Suppression/sabotage intentionnel des comptes privilégiés.

Topologie cold-backups

1. Médias/classes de stockage

Bandes (LTO-8/9) : bon marché, air-gap par défaut, haute capacité, accès série.
Les disques offline/NAS : « coffre-fort » ne sont connectés qu'à la fenêtre backup/restore.
Classe d'objet archivé (Glacier-like) : prix de stockage bas, temps d'extraction plus élevé.

2. Hébergement

Autre site/région ; un autre fournisseur/compte ; clés/administrateurs individuels.

3. Immutabilité

Rubans WORM/Object Lock (Conformité/Gouvernance) avec retenti et Legal Hold.

Politique 3-2-1-1-0 (avec un accent sur la cold)

3 copies des données (prod + sauvegarde locale + offsite).
2 supports différents (disque/bande/objet).
1 offsite (autre site/nuage).
1 immuable (WORM/air-gap).
0 erreurs de vérification (checksum/récupération de test périodique).

Répertoires, métadonnées et contrôle de l'intégrité

Catalogue des backups : quoi, où, quand, la version, les clés, les chèques-montants, la durée est retentie.
Répertoire des actifs : service → les dépendances → volume/baquets → priorité.
Checksums et les fichiers manifeste : rapprochement par enregistrement et par restauration.
Fichiers canaries : restauration régulière pour un détail précoce des problèmes de médias.

Chiffrement et clés

Cryptage au repos (bande/objet) et en vol (copie).
KMS/Vault avec double contrôle, coffres-forts hors ligne pour clés maîtres, rotation.
Clés séparées pour les prod/backaps/archives (minimisation du rayon blast).
Processus documenté d'accès aux clés sous DR (exigences, rôles, journal).

Plan RD : Priorité et cohérence

1. Identification et accès : IdP (zone minimale), Vault/KMS, noyau réseau.

2. Données et plans de contrôle : etcd K8s, configi, secrets, registres d'images, artefacts de déchargements.

3. OBD/portefeuille transactionnel : logs + dernier complet/incrémental.

4. Passerelles de paiement/intégration : clés, certificats, IP/DNS.

5. Web/api fronts : lancement canarien, contenu statique à partir d'un objet.

6. Analyse/reporting : à la fin du noyau.

1. Infrastructure : réseau, DNS/Anycast, noyau IAM, images de base/cluster.

2. Secrets/certificats : Restaurer Vault/KMS à partir de cold-backup, distribuer des secrets bootstrap.

3. Plan de contrôle : etcd/Control Plane/registres/référentiels.

4. Données : déployer les bases de données à partir de cold-backup + PITR à partir des journaux (par RPO).

5. Applications : exécute les dépendances arborescentes en chauffant les caches/CDN.

6. Tests et validation : échantillons de santé, consistance, montants de contrôle.

7. Changement de trafic : DNS/Routage/Équilibreurs (par étapes/Canaries).

8. Après-vérification : pas de fuites/dettes, logage et acte DR.

Procédures cold-restore (types)

Rubans : inventaire, téléchargement, strimes parallèles, map de fichiers → répertoires → tasks de restauration ; prise en compte des temps de recherche et de remontée.
Archive-classes : Demande d'extraction (minutes→hours), mise en stockage à chaud, restauration par manifeste.
Disques offline : connexion read-only, vérifications checksum → copie.
Pratique : « bac à sable » isolé pour la récupération, puis le transfert dans l'environnement prod.

Communications et org. structure sous DR

Роли: Incident Commander, Tech Lead (Infra), DB Lead, App Lead, Comms, Security.
Canaux : sauvegarde (en dehors du domaine d'entreprise), voix/chat, SecureDocs.
Modèles de messages : clients/partenaires/régulateurs ; la fréquence des updates ; une seule « source de vérité ».
Un seul journal d'événements : timing, solutions, propriétaires.

DNS, réseaux et trafic

Protection split-brain : drapeaux « DR-mode » dans la configuration ; feature-flags pour une fonctionnalité limitée.
Stratégie DNS : TTL bas à l'avance, fournisseur DNS indépendant ; changement progressif de A/AAAA/CNAME, chauffage du CDN.
Routage : Anycast/Geo, annonce BGP du site DR ; Les ACL/firewall sont recoupés à partir de l'IaC.

SLO pour DR

La RPO est respectée ≥ 99 % du temps (logs/incréments dans la cible).
RTO black-start (scénario complet) ≤ cible (par exemple, 4 heures) sur les tests une fois par trimestre.
Succès de l'exercice DR - 100 % des tâches critiques ont été effectuées dans la fenêtre.
L'immutabilité est la proportion de backups avec Retentation/Lock = 100 %.
Contrôles d'intégrité - 100 % selon le calendrier ; refus du porteur → ticket pour la migration.

Tests et exercices

Table-top : scripts, rôles, checklists, liste de contact.
Technique : récupération sélective des bases de données/fichiers/secrets dans le « bac à sable » avec vérification des montants de contrôle et de la consistance.
Black-start-drill : une fois/trimestre (ou une fois/six mois) est le lancement complet du noyau sur le site DR.
Post-mortem : faits, goulets d'étranglement, plan d'amélioration (SLO/processus/automatisation).

Automatisation et artefacts

IaC : clusters, réseaux, piles - dans le code ; DR-branches/paramètres.
Runbooks : compact (Vault/KMS, etcd, OBD, écluses, fronts).
Paquet DR : copie hors ligne des docks clés (contacts, schémas, mots de passe des phrases de coffre-fort), instructions d'accès physique.
Canary-restore : petit restore quotidien et rapprochement checksum.
Étiquettes/étiquettes : « DR-critical », « Warm-only », « Cold-only » pour les services/volumes.

Chèque d'implémentation

• Les classes de données et leurs RPO/RTO sont harmonisées avec les entreprises ; les priorités en matière de rétablissement ont été définies.
• Implémentation cold-backups : médias, immutabilité (WORM/Object Lock), offsite/air-gap.
• Catalogues : actifs, backups, clés ; chèques-montants et contrôle des versions.
• Procédures black-start : réseaux/DNS, IdP/Vault/KMS, plan de contrôle, données, couche d'app.
• Exercice : table-top trimestriel ; restore canaris tous les jours ; black start une fois/trimestre à six mois.
• Communications et modèles réglementaires ; des canaux de communication distincts.
• SLO/métriques/alertes pour DR ; rapports à la direction.
• Les accords avec les fournisseurs (bandes/archives-classes/DNS/CDN), SLA ont été confirmés.
• Finances : budget des supports/archives, logistique, remplacement des supports selon le calendrier.

Erreurs typiques

« Il y a une réplique - le backup n'est pas nécessaire » → l'erreur logique/ransomware va partir partout.
Il n'y a pas d'immutabilité/air-gap → un vecteur de compromis unique pour toutes les copies.
L'absence de catalogues/chèques-montants a → rétabli « quelque chose », mais pas.
Le DNS TTL est trop grand → la migration du trafic de plusieurs jours.
Les clés/KMS dans le même domaine/compte → bloquer l'accès en cas d'incident.
Les exercices « sur papier » → RTO/RPO ne sont pas confirmés.

Spécificité pour iGaming/fintech

Portefeuille/noyau de paiement : RPO strict (≤ 1-5 min) et RTO (≤ 15-60 min) ; Journaux en objet avec WORM ; La fonction DR « read-only balance » pour une communication transparente.
PSP/fournisseurs de contenu : DR-IP/domaine convenu à l'avance, whitelists, certificats, clés HMAC/mTLS - copies dans le paquet DR.
Rapports/organismes de réglementation : modèles de notification, archives immuables, intégrité prouvable, journal des activités.
Pics et events : La préparation DR est vérifiée avant les grands tournois/actions ; restore canaris et chauffage CDN.

Modèles de mini-runbook

1. Initialisation du cluster DR, chargement des clés unseal (dual-control).

2. Restauration de storage-backap (cold-copy).

3. Vérification des stratégies, émission de secrets bootstrap pour les CI/CD/K8s.

1. Développer une instance vide, restaurer full à partir de cold.

2. Placer les journaux WAL (incréments) jusqu'à l'instant cible.

3. Vérifie la cohérence, active la réplication, ouvre read-only, puis read-write.

1. Réduire la TTL de 24 à 72 heures aux risques prévus (ou rester faible en permanence).

2. Basculer A/AAAA/CNAME par chèque, surveillance de l'erreur/latence.

3. Croissance progressive du trafic (canaris 5 % → 25 % → 100 %).

Total

Le DR robuste basé sur les backups cold est : des copies isolées immuables, des procédures formalisées black-start, des RPO/RTO clairs, des exercices réguliers, une stratégie DNS/réseau réfléchie et une discipline clé. Enregistrez tout dans IaC et runbook-ah, automatisez les contrôles d'intégrité et la restauration canariale - et vous aurez toujours un chemin contrôlé vers la restauration même après le pire scénario.