Plan de Reprise d'Activité (PRA) et Sauvegardes

1. Vue d'ensemble du concept et problème systémique

En ingénierie infrastructure, les pannes matérielles des disques SSD, les incidents dans les datacenters des fournisseurs, les ransomwares et les erreurs humaines (DROP DATABASE production, un rm -rf accidentel) ne sont pas une question de « si », mais de « quand ».

La plupart des équipes vivent dans une illusion de sécurité : elles ajoutent une ligne dans le crontab pour générer un dump quotidien et considèrent la tâche comme accomplie. Lors d'une catastrophe réelle, il s'avère que :

• Le dernier backup a échoué il y a trois mois à cause d'un disque plein.
• Le dump contient des données binaires corrompues.
• La restauration d'une base de 100 Go prend 36 heures, paralysant l'activité (RTO inacceptable).
• L'attaquant, ayant compromis le serveur, a supprimé les backups ainsi que la base de production, car la clé API S3 disposait de droits complets de suppression (s3:DeleteObject).

Le Disaster Recovery (reprise après sinistre) est une stratégie globale de continuité des affaires. Elle ne se limite pas à la sauvegarde de fichiers, mais englobe des objectifs RTO/RPO mathématiquement calculés, des stockages immuables (Immutable Storage) et des exercices automatisés réguliers de déploiement de l'infrastructure depuis zéro.

2. Taxonomie architecturale et modèle mental

La matrice architecturale du disaster recovery repose sur un compromis entre la vitesse et la fréquence de capture de l'état :

┌─────────────────────────────────────────────────────────────┐
│                 TAXONOMIE DE LA RECONSTRUCTION APRÈS SINISTRE │
├─────────────────────────────────────────────────────────────┤
│ 1. Restauration à un instant donné (PITR) ➔ RPO ~ secondes   │
│    • Streaming des journaux WAL (Write-Ahead Log) en temps réel│
│    • Outils : Litestream (pour SQLite), pgBackRest (PG)      │
├─────────────────────────────────────────────────────────────┤
│ 2. Instantanés dédupliqués et chiffrés ➔ RPO ~ heures        │
│    • Instantanés de données atomiques via Restic, BorgBackup, Kopia │
│    • Chiffrement côté client AES-256 / ChaCha20              │
├─────────────────────────────────────────────────────────────┤
│ 3. Niveau de stockage immuable hors site (Anti-Ransomware)   │
│    • S3 Object Lock (WORM - Write Once, Read Many)           │
│    • Stockages géographiquement isolés (Cloudflare R2, AWS S3)│
├─────────────────────────────────────────────────────────────┤
│ 4. Standby froid & exercice automatisé de restauration (validation du RTO) │
└─────────────────────────────────────────────────────────────┘

1. Restauration à un instant précis (Point-In-Time Recovery - PITR) :
   • Au lieu d'un lourd dump quotidien, la base diffuse en continu son journal des modifications binaires (WAL) vers le cloud. Cela permet de « rembobiner » l'état de la base à la seconde précédant la panne ou une requête erronée d'un développeur (RPO < 10 secondes).
2. Snapshots incrémentaux dédupliqués (Content-Addressed Snapshots) :
   • Des utilitaires comme Restic découpent les fichiers en blocs cryptographiques. Si seulement 1% d'une base de 50 Go a changé, seuls les nouveaux blocs sont uploadés, économisant jusqu'à 95% d'espace disque et de trafic réseau.
3. Stockage immuable (Immutable WORM Storage) :
   • Une politique de sécurité S3 Object Lock qui empêche quiconque (même un administrateur avec accès root) de supprimer ou de réécrire une archive créée pendant une période définie (par exemple, 30 jours).
4. Exercices de test de restauration (Recovery Drills) :
   • Un processus automatique régulier dans le CI qui télécharge la dernière archive, la déploie dans un conteneur isolé, exécute des requêtes SQL de vérification et confirme l'intégrité des données.

3. Pipeline technique et mécanique interne

Le cycle de vie d'une sauvegarde fiable avec déduplication et chiffrement :

1. Gel cohérent de l'état (Snapshot Lock) : La base de données passe en mode préparation à la copie ou crée un snapshot transactionnel via les mécanismes COW (Copy-on-Write) du système de fichiers ZFS/Btrfs.
2. Chiffrement côté client sur l'hôte : Avant l'envoi sur le réseau, les données sont chiffrées par un algorithme robuste (AES-256-GCM) à l'aide d'une passphrase connue uniquement de l'ingénieur. Le fournisseur d'hébergement S3 ne reçoit que du bruit binaire chiffré.
3. Upload parallèle vers un stockage cloud isolé : Les blocs sont transférés via HTTPS vers une région géographique indépendante (par exemple, un serveur en Allemagne effectue ses backups vers un bucket Cloudflare R2 en Suède).
4. Application de la politique de rotation (GFS Retention Policy) : L'algorithme conserve : les 24 dernières copies horaires, 7 quotidiennes, 4 hebdomadaires et 12 mensuelles (Grandfather-Father-Son), supprimant automatiquement les anciens snapshots intermédiaires.
5. Vérification automatique de l'intégrité (Automated Integrity Check) : Une tâche séparée en arrière-plan exécute chaque semaine la commande restic check --read-data-subset=5%, détectant toute éventuelle dégradation des bits (Bit Rot) dans le stockage.

4. Scénarios d'ingénierie pratiques en production

01. Réplication continue de SQLite via Litestream

Pour les applications basées sur SQLite/Turso :

• Litestream fonctionne comme un processus système en arrière-plan, interceptant les modifications dans le fichier WAL.
• Toutes les 10 secondes, les nouvelles frames sont chiffrées et uploadées vers un bucket Cloudflare R2.
• En cas de destruction totale du serveur, une nouvelle machine se redresse avec une seule commande litestream restore -o /var/data/app.db, restaurant l'état du système sans perte de données significative (RPO < 10 s, RTO < 60 s).

02. Protection contre les attaquants via S3 Object Lock

Prévention de la destruction de l'infrastructure par des hackers :

• Même si un attaquant obtient un accès root complet au serveur et trouve la configuration contenant les clés AWS_ACCESS_KEY_ID, la tentative d'exécution de aws s3 rm --recursive est bloquée par la politique AWS Compliance Lock au niveau du datacenter Amazon.
• L'entreprise garantit un accès aux sauvegardes immuables.

03. Plan de restauration cold standby via Terraform (IaC Standby)

Incident de niveau OVH (incendie dans le datacenter de Strasbourg) :

• Le serveur principal devient physiquement inaccessible.
• L'ingénieur lance le pipeline CI : Terraform loue une nouvelle instance chez Hetzner en 3 minutes, Ansible applique la configuration de base, un script télécharge le dernier backup Restic, et les enregistrements DNS Cloudflare basculent vers la nouvelle IP en 60 secondes.

5. Pièges courants, erreurs typiques et sécurité

• Stockage du mot de passe de déchiffrement à côté du backup : Si le mot de passe du repository Restic est stocké dans un fichier texte /root/.backup_pass, la compromission du serveur donne simultanément aux attaquants un accès en lecture à toute la base client dans les backups.
• Tentative de copie de fichiers de bases vivantes sans verrous (Dirty Reads) : La simple copie du répertoire de données PostgreSQL (cp -r /var/lib/postgresql) pendant des requêtes actives crée un état binaire incohérent (Torn Pages) impossible à démarrer après restauration.
• Manque de mémoire pour la décompression du dump : Si le nouveau serveur dispose d'un disque plus petit que la taille de la base de données décompressée, la procédure de restauration échouera en cours de route avec une erreur d'espace disque insuffisant (No space left on device).
• Ignorance des fichiers de configuration et variables d'environnement : Sauvegarder uniquement la base de données sans conserver les configurations Nginx, les certificats SSL et les fichiers .env augmente le RTO de 15 minutes à plusieurs jours de reconstruction manuelle des paramètres.