Transfert de fichiers en reprise après sinistre : continuité d'activité

Le transfert de fichiers en reprise après sinistre maintient les opérations quand un site principal tombe — via la réplication inter-régions (S3 CRR, Azure GRS), une infrastructure de standby tiède et des runbooks de basculement documentés. Un système de fichiers prêt pour le PCA copie en continu les modifications vers un emplacement secondaire avec un RPO de quelques secondes à quelques heures, supporte le basculement dans le délai RTO cible, et a été testé dans des conditions réalistes. Le chemin le plus court vers un PCA utile : choisissez une charge de travail, répliquez-la dans une seconde région, simulez une défaillance régionale un samedi, et mesurez ce qui se passe réellement.

Classifier les charges de travail par impact métier

Toutes les systèmes de fichiers ne méritent pas une réplication active-active. Une analyse d'impact métier catégorise les systèmes selon leur tolérance à l'indisponibilité et à la perte de données :

• Niveau 0 (critique) : traitement des paiements, systèmes cliniques. RPO < 1 min, RTO < 15 min.
• Niveau 1 (important) : gestion des commandes, applications clients. RPO < 15 min, RTO < 1 heure.
• Niveau 2 (utile) : outils internes, reporting. RPO < 24 heures, RTO < 8 heures.
• Niveau 3 (standard) : matériels de formation, archives. RPO < 1 semaine, RTO < 3 jours.

Le niveau 0 coûte 3 à 10 fois plus cher à répliquer que le niveau 3. Cartographiez honnêtement. La plupart des entreprises ont 5 à 10 % de leurs systèmes en niveaux 0-1 et devraient concentrer leurs dépenses là plutôt que de tout dorer à l'or fin.

Topologies de réplication

Trois modèles de réplication dominent pour le stockage de fichiers :

1. Actif-passif : le primaire reçoit les écritures, le secondaire reçoit la réplique. Le basculement nécessite une promotion. Utilisé par la plupart des configurations DR régionales.
2. Actif-actif : les deux régions reçoivent des écritures, avec résolution de conflits. Plus complexe mais RTO quasi nul. Utilisé par les systèmes globaux.
3. Basé sur la sauvegarde : sauvegarde périodique vers le secondaire. RPO le plus élevé mais le plus simple. Utilisé pour le niveau 3.

S3 Cross-Region Replication (CRR) implémente l'actif-passif avec un RPO de moins d'une minute. Les S3 Multi-Region Access Points ajoutent le routage de basculement. Pour l'actif-actif, DynamoDB Global Tables et CockroachDB gèrent les bases de données ; pour les fichiers, rclone dans les deux sens avec des tags de résolution de conflits est une approche DIY.

Choisir une région secondaire

Le primaire et le secondaire doivent échouer indépendamment. Règles empiriques :

• Région géographique différente (eu-west-3 Paris → eu-central-1 Francfort, pas Paris → eu-west-1 Irlande uniquement pour la diversité)
• Réseau électrique différent (côte ouest vs côte est aux États-Unis, différents réseaux électriques nationaux en Europe)
• Zones tectoniques différentes si pertinent

Pour les charges de travail de conformité, les deux régions doivent satisfaire la réglementation. Les données RGPD doivent rester dans l'UE — répliquez Paris vers Francfort ou Dublin, pas vers Virginia. HIPAA exige un BAA dans la région secondaire aussi. Documentez la sélection des régions et la justification ; les auditeurs poseront la question.

Coût de la réplication inter-régions

La réplication a trois composantes de coût :

1. Stockage : double du coût primaire (les deux régions conservent une copie)
2. Transfert de données : AWS facture 0,02 $/Go pour le CRR entre régions
3. Frais de requête : opérations PUT à la destination

Pour 10 To répliqués par mois, comptez environ 700 $/mois sur AWS entre Virginia et Oregon. Atténuations : répliquer vers une classe de stockage moins chère à la destination (S3 Glacier Instant Retrieval au lieu de Standard), filtrer la réplication par préfixe ou tag pour exclure les données non critiques, et utiliser les métriques de réplication des buckets pour détecter une réplication runaway.

Le runbook de basculement

Un runbook qui n'existe que comme idée est un runbook qui échoue. Un runbook prêt pour la production couvre :

1. Critères de déclenchement : quelles conditions initient le basculement (page de statut de région, vérifications de santé d'application, latence P99 au-dessus du seuil)
2. Autorité de décision : qui prend la décision (typiquement VP Ingénierie + SRE lead, avec des seuils pré-approuvés pour un déclenchement automatique)
3. Étapes : commandes exactes, dans l'ordre, avec la sortie attendue
4. Vérification : comment confirmer que chaque étape a fonctionné
5. Retour arrière : comment annuler si le basculement lui-même a causé des problèmes
6. Communication : mise à jour de la page de statut, notification clients, Slack interne

Exemple d'étape de basculement pour une application S3 : mettre à jour Route 53 pour pointer fichiers.example.com depuis le CloudFront du bucket primaire vers le CloudFront du bucket secondaire. Testez avec dig et un envoi test. Objectif de temps : moins de 10 minutes.

Stratégie DNS et de routage

Le DNS pilote généralement le basculement. Options :

• Route 53 Failover routing : actif-passif avec basculement automatique basé sur les health checks
• Route 53 Latency routing : trafic vers la région saine la plus proche
• CloudFront avec basculement d'origine : transparent pour les clients
• Répartiteur de charge avec backends multi-régions : fonctionne mais ajoute de la complexité

Le TTL compte. Un enregistrement DNS avec un TTL de 300 secondes bascule en 5 minutes ; un TTL de 3 600 secondes prend une heure. Réglez les enregistrements critiques pour le PCA à TTL 60-300 secondes, en acceptant un trafic DNS légèrement plus élevé pour une convergence plus rapide.

Intégrité des données lors du basculement

Le décalage de réplication signifie que le secondaire a légèrement de retard. Basculer peut faire perdre les écritures les plus récentes. Documentez le RPO comme la pire perte attendue et prévoyez un plan de réconciliation :

• Journalisez les écritures non commitées au niveau de la couche applicative pour pouvoir les rejouer
• Capturez les transactions en cours et rejouez depuis les journaux d'événements
• Acceptez la perte explicitement (pour les données non critiques, la simplicité est préférable)

Pour les envois de fichiers spécifiquement, un envoi multipart interrompu par un basculement peut laisser des envois incomplets sur le secondaire. Configurez des règles lifecycle AbortIncompleteMultipartUpload dans les deux régions pour les nettoyer.

Tester le PCA sérieusement

Un plan DR testé et un plan DR non testé sont deux animaux différents. Niveaux de test :

• Exercice sur table : parcourez le runbook verbalement. Chaque trimestre.
• Basculement partiel : basculez un sous-système (par exemple, uniquement le service de fichiers). Semestriel.
• Basculement régional complet : basculez tout dans une fenêtre de maintenance planifiée. Annuel.
• Ingénierie du chaos : non planifié, simulé, pendant les heures ouvrées. Chaque trimestre pour les systèmes de niveau 0.

Documentez tout. Ce qui a cassé. Combien de temps chaque étape a réellement pris. Qui n'a pas pu accéder à la documentation quand il en avait besoin. Améliorez le runbook après chaque test. Les équipes qui font cela ont des basculements qui fonctionnent ; celles qui ne le font pas découvrent les problèmes lors d'incidents réels.

Les canaux de communication comptent

Lors d'un incident, la communication dans le cloud peut être indisponible. Un Slack hébergé dans la même région AWS qui est en train de tomber est inutile. Préparez des canaux hors bande :

• Un espace de travail Slack secondaire hébergé dans une région différente
• Un pont SMS via Twilio ou Telnyx
• Un arbre téléphonique personnel en dernier recours
• Une page de statut publique hébergée hors de votre infrastructure primaire (Atlassian Statuspage, StatusGator)

Documentez les canaux dans le classeur physique. Entraînez-vous à basculer vers eux.

Transférer des fichiers de récupération entre personnes

Quand une défaillance régionale bloque l'accès aux outils de collaboration habituels, transférer des fichiers spécifiques — un dump de base de données à jour, un export de configuration, un playbook de réponse à incident — nécessite un canal fonctionnant indépendamment de votre infrastructure. Un outil utilisable depuis un appareil personnel est utile ici.

HexaTransfer fonctionne dans n'importe quel navigateur sans création de compte — utile quand le fournisseur SSO est lui aussi indisponible, ou quand des consultants qui interviennent doivent recevoir des fichiers sans être provisionnés dans votre tenant. Le chiffrement AES-256-GCM de bout en bout signifie que même dans les moments de stress avec des mains sur le clavier, les secrets ne fuient pas sur le réseau.

Revues post-incident

Chaque test DR et chaque incident réel mérite un post-mortem sans reproche. Documentez :

• Chronologie des événements
• Ce qui a fonctionné
• Ce qui n'a pas fonctionné
• Causes profondes (techniques et processus)
• Actions correctives avec responsables et échéances

Suivez les actions jusqu'à leur clôture. Un post-mortem avec 20 actions et zéro complétée est pire que pas de post-mortem — cela signale à l'équipe que les améliorations ne comptent pas. Fermez la boucle, et le prochain incident se passera mieux que le précédent.

La reprise après sinistre est principalement une question de discipline. Définissez le RPO/RTO, répliquez en continu, documentez le runbook, testez chaque trimestre, et communiquez hors bande. La technologie, c'est la partie facile.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.