Backaps et disaster récupération

Backups et Disaster Recovery

1) Définitions et objectifs

Backap est une copie cohérente des données/configurations pour une restauration ultérieure (à partir de suppressions accidentelles, bugs, cryptolockers, catastrophes).
DR (Disaster Recovery) est le processus de restauration des infrastructures/services aux travailleurs SLO après un accident majeur (incendie, perte d'une région, compromission massive).
RPO (Recovery Point Objective) est la perte de données maximale autorisée en temps (par exemple, 15 minutes).
RTO (Recovery Time Objective) est le temps cible de récupération du service (par exemple, 30 minutes).

Principe clé : réplication ≠ backup. La réplication « brise » rapidement les erreurs et le chiffrement sur toutes les copies. Backap est une copie isolée, vérifiée, potentiellement immuable.

2) Classification des données et niveaux de criticité

• Tier-0 (vital) : bases de données transactionnelles, paiements, comptabilité de bilan, secrets/ICP.
• Tier-1 (critiques) : configurations de services, files d'attente, artefacts CI/CD, registres de conteneurs.
• Tier-2 (importants) : analyses, rapports, indices secondaires, archives de journaux.
• Tier-3 (auxiliaires) : caches, données temporelles (peut être restauré par reconstruction).

Pour chaque classe, définissez le RPO/RTO, la durée de conservation, les exigences d'immuabilité et de localisation.

3) Stratégies de stockage : Règle 3-2-1-1-0

3 copies des données (prod + 2 de sauvegarde).
2 types de supports/référentiels différents.
1 copie offsite (autre région/nuage).
1 immutable/air-gap (WORM/Object Lock/Tape).
0 erreurs dans les tests de récupération (tests réguliers).

4) Types de backup

Full est une copie complète. Lentement/cher, mais une base pour toutes les stratégies.
Incremental est la différence avec le dernier backup. Optimal en volume.
Differential est la différence avec le dernier plein. Plus rapide de récupération, plus d'espace.
Snapshot est un instantané de volume/disque (EBS/ZFS/LVM). Il faut des snapshots app-consistent (quiesce).
PITR (Point-in-Time Recovery) est un backup de base + journaux (WAL/binlog) pour le retour à l'heure précise/LSN.
Objets/fichiers/images : Sous des types de données spécifiques (images VM, objets S3, DB).

5) Cohérence des backups

Crash-consistent : comme après l'arrêt soudain - convient pour les FS stateless/journalisables.
App-consistent : l'application « gèle » les opérations (fsfreeze/pre-post scripts) → l'intégrité garantie.
Cohérence OBD : API de l'outil backup (pgBackRest, XtraBackup), modes hot-backup, gel des points de contrôle.

6) Cryptage, clés et accès

Cryptage at-rest et in-transit pour toutes les copies.
Clés dans KMS/HSM, rotation par politique (90/180 jours), clés séparées par environnement.
Partage des responsabilités : qui crée/supprime les backaps ≠ qui peut les décoder/lire.
Ne gardez pas les clés de déchiffrement dans le même domaine de confiance que les copies cibles.

7) Copies immuables et protection contre le ransomware

Object Lock/WORM (Compliance/Governance) avec retenti et Legal Hold.
Air-gap : stockage isolé/hors ligne (bande, cloud hors ligne/compte).
Stratégies de suppression « avec activation différée », MFA-Delete, compte séparé pour les backup-buckets, interdiction d'accès public.
Vérification sur malware/indicateurs de compromission avant montage.

8) Fréquence, horaire et rétentions

GFS (Grandfather-Father-Son) : incrémental diurne, incrémental hebdomadaire, incrémental mensuel avec stockage de longue durée.
RPO dicte la fréquence des incréments et l'archivage WAL/binlog (par exemple toutes les 5 à 15 minutes).
Stockage : critique - ≥ 35-90 jours + mensuels pendant 12-36 mois (exigences légales).
Les pics saisonniers sont des points de contrôle distincts (avant les promotions/sorties).

9) Modèles et scénarios DR

Active-Active : les deux régions desservent le trafic. RTO minimum, la saisie des données nécessite une politique de conflit stricte.
Active-Passive (chaud/chaud) : chaud - déplié et synchronisé (minutes RTO), chaud - partiellement prêt (heures RTO).
Cold : nous stockons des copies et Terraform/Ansible/images, nous soulevons sur demande (RTO 24 heures +).
DRaaS : orchestre fournisseur VM/réseaux/adresses dans une autre zone.

10) Orchestration de faussaires et priorités de récupération

La priorité de la mise en marche : le réseau/VPN/DNS → les secrets/KMS → les bases/clusters → les tours/caches → les applications → le périmètre/CDN → de l'analyste.
Automatisation : scripts/Runbook-action, Terraform/Ansible/Helm/ArgoCD profils pour l'environnement DR.
Données : DB PITR → reindex/replica → le cache warm → exécute des services avec des indicateurs de compatibilité de schéma.
DNS/GSLB : rétrogradation TTL à l'avance, scripts de commutation avec validation.

11) Tests de récupération (backup verification)

Restore-tests programmés : échantillonnage N % des backups, déploiement dans le « bac à sable », vérifications automatiques des schémas/invariants.
DR-drill complet (game-day) : désactivation de la région/AZ, vérification RTO/RPO sur trafic en direct (ou trafic-shadow).
Tests d'intégrité : répertoires hash, checksum, tentative de lecture de tous les calques (full + chain).
Rapport de quai : temps, étapes, anomalies, taille de l'écart par rapport aux objectifs, corrections.

12) Pratiques pour les technologies de base

Bases de données

PostgreSQL : base backup + archives WAL (PITR), outils pgBackRest/Barman ; slots de réplication, contrôle de 'lsn'.
MySQL/MariaDB : Percona XtraBackup/Enterprise Backup, binlog archivage.
MongoDB : 'mongodump' pour la copie logique + snapshot pour les grands ensembles ; Oplog pour PITR.
Redis : RDB/AOF pour les critiques (si Redis n'est pas seulement un cache), mais plus souvent une reconstruction logique à partir de la source + snapshot pour les accidents.
Kafka/Pulsar : backup de métadonnées (ZK/Kraft/BookKeeper), snapshots de disques, miroir de tops/logs.

Kubernetes

etcd snapshot + Velero pour les ressources/volumes (CSI snapshots).
Backup secrets/PKI séparément (Vault snapshot).
Registre d'images séparé : Polycy de stockage d'artefacts (tags immuables).

VM et systèmes de fichiers

ZFS : 'zfs snapshot' + 'zfs send | send-recv' incréments, vérifiez 'scrub'.
LVM/EBS snapshots avec des scripts pre/post (app-consistent).
Référentiels d'objets : versions + Object Lock.

13) Catalogage et contrôle des versions des backaps

Catalogue (catalogue de métadonnées) : quoi, où, quand, quoi que ce soit, les hachages, la clé KMS, le propriétaire, la durée de conservation.
Метки/теги: `env=prod|stage`, `system=db|k8s|vm`, `tier=0|1|2`, `retention=35d|1y`.
Points de contrôle « or » (Gold) : avant les migrations/DDL/sorties à grande échelle.

14) Observabilité et métriques

Succès des tâches :% de succès/d'échec, raisons.
Temps de backap/restauration, largeur de fenêtre.
RPO-fact : lag des archives des revues (WAL/binlog) p95.
Intégrité : proportion de chaînes testées, erreurs de rapprochement des hachages.
Coût : volume de stockage par classe, taux de déduplication/compression.
DR : fréquence et résultat des exercices (pass/fail).

15) Politiques d'accès et de conformité

Comptes/projets séparés pour le stockage backup ; accès selon le principe NaC (nous ne permettons pas la suppression/cryptage des comptes pro).
Logs d'accès/changements (audit trail), alertes pour les suppressions massives/changements de rétention.
Conformité : GDPR (droit de supprimer les archives), PCI DSS (cryptage, clés, segmentation), régulateurs locaux.

16) Anti-modèles

« La réplique est là, donc le backup n'est pas nécessaire ».
Pas d'immutable/air-gap : une erreur/malware efface tout.
Backaps dans le même compte/région que prod.
Ne jamais vérifier la restauration (backup « mort avant la vérification »).
Pas de catalogage et de contrôle des versions → chaos en cas d'accident.
Clés de cryptage partagées pour tous les environnements.
Snapshots sans app-consistent en mode OBD.
La fenêtre backup croise les pics (affecte p99 et SLO).

17) Chèque de mise en œuvre (0-60 jours)

0-10 jours

Inventaire des systèmes/données, classes de criticité.
Fixer des objectifs RPO/RTO par classe.
Activer full + incremental pour les Tier-0/1, archives WAL/binlog.
Dissocier les backups : Région/compte séparé + activer le cryptage KMS.

11-30 jours

Configurer immutable (Object Lock/WORM) pour les copies critiques.
Entrez le catalogage, les balises, les rapports ; les alertes pour les échecs et les magazines.
Premier drill DR : restaurer un service séparé à partir d'un backup dans un environnement isolé.

31-60 jours

Automatiser les profils runbook : Terraform/Ansible/Helm DR.
Des tests de restauration réguliers (semaine/mois) + un scénario de DR complet trimestriel.
Optimiser les coûts : Déduplication/compression/cycle de vie du stockage.

18) Métriques de maturité

Tests de restauration : ≥ 1/ned pour le Tier-0 (sélectivement), ≥ 1/mes est un scénario complet.
Immutable coverage для Tier-0/1 = 100%.
RPO réel p95 ≤ cible (par exemple, 15 min ≤).
RTO réel sur les exercices DR ≤ cible (par exemple, 30 min ≤).
Répertoire-complémentarité = 100 % (chaque backup est décrit et vérifié).
Incident-to-restore : temps entre la détection et le démarrage de la récupération.

19) Exemples (extraits)

bash base backup once a day pgbackrest --stanza = prod --type = full backup archive WAL every 5 minutes pgbackrest --stanza = prod archive-push restore to time pgbackrest --stanza = prod restore --type = time --target =" 2025-11-03 14:00:00 + 02"

bash xtrabackup --backup --target-dir=/backup/full-2025-11-01 xtrabackup --backup --incremental-basedir=/backup/full-2025-11-01 --target-dir=/backup/inc-2025-11-02 xtrabackup --prepare --apply-log-only --target-dir=/backup/full-2025-11-01 xtrabackup --prepare --target-dir=/backup/full-2025-11-01 --incremental-dir=/backup/inc-2025-11-02

yaml apiVersion: velero. io/v1 kind: Backup metadata: { name: prod-daily }
spec:
includedNamespaces: ["prod-"]
ttl: 720h storageLocation: s3-immutable

json
{
"Rules": [{
"ID": "prod-immutable",
"Status": "Enabled",
"NoncurrentVersionExpiration": { "NoncurrentDays": 365 }
}]
}

20) Communications et rôles opérationnels

Incident Commander, Comms Lead, Ops Lead, DB Lead, Security.
Modèles de messages pour steakchalders/régulateurs/utilisateurs.
Post-mortem avec des actions : où vous avez perdu des minutes, où améliorer l'automatisation.

21) Conclusion

Le contour robuste des backups et des DR n'est pas une "copie", mais un cycle : classification → objectifs RPO/RTO → copies multi-niveaux et immutables → runbook automatisé "et → des restaurations et des exercices réguliers. Respectez le 3-2-1-1-0, séparez la réplication des backups, cryptez et isolez les clés, documentez et vérifiez. Alors même le « cygne noir » deviendra un processus contrôlé avec un temps d'arrêt prévisible et une perte de données minimale.