Stratégies de backaps et de réplication

Résumé succinct

Une stratégie de données robuste repose sur trois supports : backup, réplication, restauration. Réplique réduit RTO (temps de récupération), backup garantit RPO (perte de données) et protège contre les erreurs logiques/ransomware. Principes de base : 3-2-1-1-0 (3 copies, 2 types de médias, 1 offsite, 1 immuable, 0 erreurs dans les tests), des tests DR réguliers et l'immutabilité des jeux critiques.

Termes et objectifs

RPO - Combien de données est autorisé à perdre (par exemple, 5 minutes ≤).
RTO - Combien de temps est autorisé à récupérer (par exemple, 15 minutes ≤).
PITR (Point-in-Time Recovery) - Récupération « à l'instant X » avec réplication des journaux.
Le SLO de données est un contrat de niveau de service pour RPO/RTO et le succès des tâches de backup.

Exemple de matrice :

Classe de données	RPO	RTO	Remarques
Transactions/portefeuille	≤ 1-5 min	≤ 5-15 min	Logs + réplique synchrone du noyau
Rapports/PII	≤ 1 h	≤ 1 h	WORM/immutabilité, archives
Logs/événements bruts	≤ 24 h	≤ 4 h	Objet, lifecycle

Modèles de tolérance aux pannes et de réplication

Options de topologie

Active-Passive (chaud/chaud/froid) : plus facile, prédictible faussaires.
Active-Active : haute disponibilité, mais plus difficile à résoudre et consistance.
Multi-Zone/Région/Cloud : équilibre entre les retards et les coûts d'egress.

Synchron vs asynchron

Synchron : RPO≈0, au-dessus de latency, limite de distance.
Asynchron : proche de zéro RTO avec peu de RPO (minutes), résiste aux régions/nuages.
Hybride : synchrone dans la zone, asynchron dans la région éloignée.

Réplique ≠ backap

Une réplique emporte des erreurs/suppressions après la source. Backap est une copie off-path avec versioning, vérifications et isolation.

Politique 3-2-1-1-0 et immutabilité

3 copies (prod + sauvegarde locale + offsite).
2 types de supports (bloc/NAS/objet/bande).
1 offsite (autre site/nuage/bande).
1 copie immuable (WORM : Object Lock, snapshots/ruban immuable).
0 erreurs : vérification régulière de l'intégrateur (checksum/verify/restore-tests).

Pratiques :

Activez le versioning et le verrouillage d'objets (Compliance/Governance) pour un objet avec des backups critiques.
Pour NAS/blocks - snapshots immuables avec retenti et interdiction de suppression avant la date limite.

Types de backup et horaires

Full est une copie complète.
Incrémental - seulement les changements du passé backap.
Differential - changements depuis la dernière version complète.
Forever-incrémental avec plan GFS (Grandfather-Father-Son) : incréments diurnes, hebdomadaires et mensuels « synthétiques complets ».

Recommandation (exemple) :

Prod OBD : quotidien complet (ou synthétique complet), incréments/revues toutes les 5 à 15 minutes (PITR).
Serveurs de fichiers : full hebdomadaire, incrémental quotidien, archives mensuelles.
Objet : lifecycle + versions ; froid - dans la classe de stockage/bande d'archives.

Applications et OBD : Pratiques du PITR

PostgreSQL

Activer l'archivage WAL et la sauvegarde de base ; PITR via 'restore _ command'.
Outils : 'pgBackRest', 'wal-g' (objet), 'pg _ basebackup' pour les complets.
Séparer les volumes : données et WAL ; Écrire WAL sur NVMe rapide avec PLP.

MySQL/MariaDB

Journal binaire pour PITR, complet via 'Percona XtraBackup' (hot backup).
Réplication GTID ; pour DR - asynchrone dans la région/nuage.

MongoDB

Oplog pour le PITR ; snapshots au niveau storaja + 'mongodump'pour les copies logiques.
Tester la consistance de la réplique avant le backap.

Redis/Cache

Non considéré comme un backup : garder RDB/AOF + offsite ; reconstituer comme warm-cache ou à partir d'une source de vérité.

Kubernetes et conteneurs

etcd cluster est une cible critique distincte (snapshots fréquents, offsite).
Velero : backap de manifestes/ressources + snapshots CSI/PV ; stockage dans un baquet compatible S3 (avec Object Lock).
Stateful-over : app-consistent snapshots (pre/post hooks), sinon - crash-consistent.
La versionation des artefacts objets (modèles/médias) est au niveau des réservoirs.

Virtualisation et serveurs de fichiers

VM-snapshots : utiliser CBT (Changed Block Tracking), stocker hors site, faire guest-aware quiesce (VSS pour Windows) périodiquement.
Serveurs de fichiers (NAS) : snapshots + réplica et tests de restauration de catalogue réguliers (échantillonnage de fichiers).

Sécurité des backups

Cryptage au repos (LUKS/ZFS/cloud KMS/Vault) et en transmission (TLS/mTLS).
Gestion des clés : rôles individuels, double contrôle, rotation, stockage hors ligne des clés maîtres.
Isolement : comptes backap sans droits de suppression de copies immobilisées ; réseaux/VLAN séparés.
Ransomware-résilience : immuable, air-gap (bandes/compte isolé/Labs).
Audit : journal des opérations du système backup, alertes de suppression/réduction de rétention.

Planification des fenêtres et de la bande passante

Backup window vs charge : Trottling I/O/réseaux, déduplication, compression.
Réseau : incréments toutes les N minutes, canaux individuels/VPN, réplique la nuit ou en permanence avec QoS.
Suivi de bloc de changement/CDC pour réduire le trafic.
Grandes bases : flux parallèles/streaming, multipart multicanal dans l'objet.

Surveillance, métriques et SLO

Les métriques :

Succès des tâches de backap/réplication (%), durée, vitesse, journal (WAL/binlog/oplog).
Espace de stockage des backaps, facteur de déduplication, autres dépenses.
Le temps et le succès des restaurations de test.

SLO (exemple) :

Le succès des backups ≥ 99. 9 %/30 jours.
La RPO est respectée ≥ 99 % du temps (journal ≤ cible).
RTO (test-restore) ≤ 15 min pour le portefeuille, ≤ 1 h pour le rapport.
DR-drill mensuel : 100 % des scénarios programmés sont terminés.

Alert :

Backup ignoré/échoué, PITR> seuil, baisse du degré de déduplication, manque d'espace, changement de stratégie de rétention, absence de nouveau test-restore.

Exercice de DR et vérification des restaurations

Tabulaires (table-top) : coordination des rôles, contacts, communications.
Technique : récupération « dans le bac à sable », mesure RTO, comparaison des montants de contrôle/données.
Black-start : récupération complète sur « fer nu/cluster propre ».
Répertoires de données : étapes de récupération (runbooks) pré-décrites pour chaque classe de système.
Automatisation : restauration périodique « canariale » et rapprochement des montants de contrôle.

Modèles pratiques

1) PostgreSQL (pgBackRest + archive WAL dans l'objet)

ini
[global]
repo1-type=s3 repo1-path=/pgbackups repo1-s3-endpoint=minio. local:9000 repo1-s3-bucket=pg-wal repo1-s3-key=ACCESSKEY repo1-s3-key-secret=SECRET repo1-retention-full=8 start-fast=y compress-type=zst

2) wal-g (example BOU)

bash export WALG_S3_PREFIX=s3://pg-wal/prod export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export WALG_COMPRESSION_METHOD=zstd

3) Velero (K8s - objet + immutabilité du baquet)

yaml apiVersion: velero. io/v1 kind: BackupStorageLocation metadata: { name: default, namespace: velero }
spec:
provider: aws objectStorage:
bucket: k8s-backups config:
s3Url: https://minio. example s3ForcePathStyle: "true"
publicUrl: https://minio. example

4) Politique de lock d'objets (exemple 'mc')

bash mc version enable my/backups mc retention set --default COMPLIANCE 365d my/backups

5) Exemple de planning GFS (concept)

Quotidien : incréments toutes les 15 min (revues), jour plein synthétique.
Week-end : un « plein » (synthétique), stocker 8 semaines.
Monthly : complet, stocker 12-24 mois (archives/ruban).

Chèque d'implémentation

Classes de données définies, propriétaires, RPO/RTO/SLO.
Les modèles de réplication (sync/async) et de topologie (AZ/Région/Cloud) sont sélectionnés.
Backaps configurés : full/incremental/PITR, horaires, annuaires.
L'immutabilité (WORM/Object Lock/Immutable snapshots) et l'offsite/air-gap sont incluses.
Cryptage et KMS/Vault, rôles séparés et rotations de clés.
Suivi : succès des tâches, logs, lieu, test-restore ; alerte.
Runbooks de récupération et de faussaire ; contacts, escalade, modèles de communication.
Exercice de RD mensuel + rapport, ajustement des plans.
Budget et FinOps : coût du stockage/egress, projet d'archivage/tyring.

Erreurs typiques

« La réplique est là - le backup n'est pas nécessaire » : les suppressions logiques et les ransomware partiront pour la réplique.
Aucun test de récupération - le backup existe « théoriquement ».
L'absence d'immutabilité et d'offsite est un seul point de risque.
Le même compte/clés pour les prod et les backups - compromission = perte de tout.
Fenêtres de backup trop longues → conflit avec les pics ; pas de trottinette et de QoS.
PITR sans contrôle de la lagune des journaux.
Ignorer app-consistent snapshots - « sales » volumes récupérables.

Spécificité pour iGaming/fintech

Porte-monnaie/noyau de paiement : RPO ≤ 1-5 min, RTO ≤ 15 min ; Les journaux (WAL/binlog) dans un objet avec WORM ; synchrone dans la zone + région asynchrone.
Reporting/réglementation : entrepôts immuables, rétentions prolongées (années), intégrité vérifiable, procédures claires pour la communication des données aux régulateurs.
Logs/événements bruts/antifrod : stockage à longue durée de vie (objet) bon marché + lifecycle ; indices et vitrines - séparément.
Pics (matchs/tournois) : fenêtres backup en dehors des pics, throttling ; Plans DR pour la période des événements ; restore canaris avant les promotions.

Résultat

La protection des données est une discipline architecturale : 3-2-1-1-0, versioning et immutabilité, RPO/RTO comme SLO, exercices réguliers de DR et vérification de la récupération « en fait ». Combinez la réplication pour l'aptyme et les faussaires rapides avec des backups pour les erreurs logiques et les compromis. Automatisez, mesurez, documentez - et vous aurez toujours un chemin de travail de retour, même le plus mauvais jour.