Solution
Haute disponibilité, sauvegarde et reprise
Conception de clusters HA, de dépôts de sauvegarde et de plateformes de Disaster Recovery sur site et dans le cloud. Configuration de la réplication, du failover, de la rétention des copies et des procédures de restauration selon les objectifs RTO/RPO et les volumes à récupérer.
Architecture et réalisation
Copies et rétention
Architecture 3–2–1–1–0, dépôts indépendants, copies hors site et rétention immuable. Organisation des accès, des clés et des points de restauration.
Haute disponibilité et réplication
Clusters actif-actif ou actif-passif, réplication synchrone ou asynchrone, load balancing et procédures de failover pour les applications et le stockage.
Reprise et restauration
PRA intersite ou interrégional, restauration à un instant précis, reconstruction automatisée et exercices mesurant le délai de reprise et le point récupéré.
Réalisations associées
Dimensionner la reprise avec le RTO et le RPO
Le délai de reprise et la perte de données admissible orientent le choix du stockage, la fréquence des sauvegardes et le niveau de redondance. Ces objectifs se définissent par service, avec ses dépendances et son volume de données.
- RPORecovery Point ObjectivePerte de données admissible
- Le RPO fixe la perte de données maximale admissible en minutes ou en heures. Avec un RPO de 15 minutes et un incident à 10 h, les sauvegardes ou les réplicas doivent permettre de récupérer les transactions enregistrées au moins jusqu’à 9 h 45.
- RTORecovery Time ObjectiveDélai de remise en service
- Le RTO fixe la durée maximale d’interruption admissible. Avec un RTO de 2 heures et un incident à 10 h, l’application doit accepter de nouveau les connexions et les transactions avant midi. Ce délai inclut la détection, le failover ou la restauration, puis les tests de fonctionnement.
- Point de reprise au plus tôt
- Interruption du service
- Remise en service au plus tard
RPO · Au plus 15 min de données perdues
RTO · Au plus 2 h d’interruption
Ces valeurs illustrent des objectifs de conception. Leur respect se mesure lors des exercices de reprise.
Le point récupérable dépend des sauvegardes terminées et des journaux de transactions disponibles. Un job lancé toutes les 15 minutes peut échouer ou terminer en retard. Les exercices de restauration vérifient donc les transactions effectivement récupérées, puis l’authentification, les requêtes applicatives et les connexions aux API externes.
Références techniques AWS Well-Architected · RTO / RPO
Hot, warm et cold selon les accès aux données
Les tables d’une base en production, les sauvegardes récentes et les archives sont lues à des fréquences différentes. Les catégories hot, warm et cold décrivent ces accès et le délai de récupération attendu. Le support physique et le mode d’accès se choisissent ensuite pour les traitements concernés.
| Catégorie | Accès et exemples | Implémentations possibles | Coût et récupération |
|---|---|---|---|
| Hot | Tables et index sollicités par les transactions, logs actifs et données servies par les API | SSD NVMe locaux, volumes sur baie all-flash ou stockage cloud provisionné pour les I/O | Budget lié aux IOPS et à la latence des écritures. Accès sans récupération préalable depuis une archive |
| Warm | Historiques consultés périodiquement et sauvegardes récentes utilisées pour les tests ou les restores | Pools HDD, systèmes hybrides ou dépôts flash lorsque plusieurs restores doivent s’exécuter en parallèle | Arbitrage entre capacité et débit de restauration. Les données restent directement accessibles dans le dépôt choisi |
| Cold | Sauvegardes anciennes, jeux de données archivés et conservation de longue durée | Classes objet de rétention, bandes hors ligne ou dépôts HDD et flash selon le délai d’accès attendu | Priorité au coût de conservation. Frais de lecture ou de sortie d’archive selon l’offre et délai à intégrer au restore |
Une base SQL utilise des volumes flash pour ses transactions. Les sauvegardes récentes sont écrites dans un dépôt HDD ou flash, représentés ici comme deux options. Une copie de rétention est transférée vers le cloud. Les accès hot, warm et cold décrivent l’utilisation des données, tandis que le choix du support dépend des performances et du délai de restauration.
Azure Storage
SQL Server
Composants et flux
- La base lit les pages de données et écrit son journal sur un volume flash, local ou présenté par une baie
- Un dépôt HDD privilégie la capacité, tandis qu’un dépôt flash peut soutenir davantage de restaurations et de tests simultanés
- Les classes Azure Blob Cold et Archive sont deux options de rétention avec des parcours de lecture différents
- La classe Cold reste en ligne, tandis que la classe Archive impose une réhydratation avant le restore
- La rétention et les jobs de copie sont configurés séparément du support physique
Flash, SSD et protocole NVMe
La flash NAND est la mémoire qui conserve les données dans un SSD. NVMe est le protocole utilisé pour communiquer avec le stockage, notamment sur PCIe dans un serveur. NVMe over Fabrics étend cet accès à un réseau de stockage, par exemple avec NVMe/TCP. Les SSD existent aussi avec des interfaces SATA ou SAS.
Flash pour les bases transactionnelles
Une base OLTP enregistre les transactions courantes de l’application. Ses accès aux index et aux pages de données peuvent produire de nombreuses petites lectures, tandis que le journal exige des écritures durables. La flash réduit l’attente liée aux mouvements mécaniques des HDD. Le dimensionnement mesure la latence, le nombre d’opérations d’entrée-sortie par seconde (IOPS) et le débit avec la charge SQL réelle.
HDD ou flash pour le backup
Les HDD servent notamment à constituer des dépôts de capacité pour les fichiers de sauvegarde. Un dépôt flash peut accélérer les lectures parallèles lors de plusieurs restores ou de tests simultanés. Une copie rarement consultée peut rester cold même sur SSD. Le choix du support dépend du volume à conserver et du débit de récupération mesuré, avec les limites du réseau et du logiciel de backup.
NVM Express | NVMe / NAND · NVM Express | NVMe over Fabrics
Cold en ligne et archive avec réhydratation
Azure Blob Cold reste accessible en ligne. Azure Blob Archive impose une réhydratation avant lecture, dont le délai peut atteindre 15 heures selon la priorité. Google Cloud Archive reste en ligne sans cette étape. Sur Azure Blob, Hot propose des lectures moins coûteuses, tandis que Cold réduit le tarif de la capacité conservée. Le calcul du coût inclut la capacité stockée, les lectures et les transferts, ainsi que les durées minimales de facturation. Ces conditions entrent dans le calcul du RTO.
Microsoft | Azure Blob access tiers · Google Cloud | Storage classes
Block, file et object selon l’interface de l’application
Un moteur SQL peut écrire ses fichiers sur un volume bloc, une application documentaire ouvrir un partage SMB et un pipeline charger des fichiers Parquet dans un bucket objet. Ces trois modes définissent comment le logiciel accède aux données. Chacun peut utiliser du HDD ou de la flash, avec des niveaux de performance propres au service.
La base SQL écrit des fichiers sur un volume bloc monté par son serveur. Une application utilisant des chemins de fichiers accède à un partage SMB ou NFS. Le pipeline de données dépose ses objets dans un conteneur Azure Blob via HTTPS. Le support HDD ou flash est choisi séparément selon les performances du service.
- Azure Storage
Python- SQL Server
Composants et flux
- Bloc avec volume monté par l’hôte, filesystem et accès aux blocs via un disque local ou un SAN
- Fichier avec arborescence de répertoires et accès partagé par SMB ou NFS
- Objet avec identifiant, métadonnées et appels API pour déposer ou récupérer les données
- Les classes hot, warm et cold sont choisies séparément du mode d’accès
| Interface | Organisation et accès | Applications | Fonctionnement à prendre en compte |
|---|---|---|---|
| Block storage | Volume de blocs adressables présenté au serveur. Accès local ou via iSCSI, Fibre Channel ou NVMe-oF | Volumes de VM, fichiers et journaux de bases SQL, disques système | L’hôte ou le moteur organise les fichiers sur le volume. Un volume partagé entre plusieurs hôtes exige une coordination des écritures compatible avec le cluster |
| File storage | Fichiers organisés en répertoires et ouverts par leur chemin. Partages SMB ou NFS sur NAS ou service cloud | Fichiers d’applications, répertoires partagés, datasets scientifiques et certains déploiements de VM ou de bases | Le service de fichiers gère les noms, les permissions et les locks. Les performances dépendent aussi du protocole et du nombre d’accès concurrents |
| Object storage | Objets adressés par une clé avec leurs métadonnées. Accès par API, notamment S3, Azure Blob ou Google Cloud Storage | Data lakes Parquet, modèles et données d’IA, médias et copies de sauvegarde | L’application lit et écrit avec les opérations de l’API. Versioning, rétention et classes d’accès se configurent selon les fonctions du service |
Le choix part des opérations effectuées par l’application. Un moteur SQL attend des écritures durables et des mécanismes de verrouillage précis. Certains déploiements sur NFS ou SMB sont pris en charge par les éditeurs. Un montage de bucket par une passerelle de fichiers demande de vérifier ces mêmes opérations, car l’API objet et le filesystem monté n’offrent pas automatiquement les mêmes garanties.
Références techniquesMicrosoft | Storage services · Microsoft | Blob Storage
Organiser les sauvegardes selon la règle 3–2–1–1–0
La stratégie de sauvegarde combine diversité du stockage, séparation géographique, protection contre la suppression et vérification des restaurations. Une même copie peut remplir les critères « hors site » et « immuable ».
3 Copies
Les données de production et deux sauvegardes
2 Types de stockage
Par exemple, disque local et stockage objet cloud
1 Copie hors site
Séparée du site de production et de ses défaillances
1 Copie protégée
Hors ligne, isolée du réseau ou immuable
0 Erreur non résolue
Vérification des sauvegardes et essais de restauration
Pour une plateforme hébergée sur site, cette architecture associe un dépôt local, rapide à restaurer, à une copie cloud hors site avec rétention verrouillée. Les trois copies comprennent les données de production. Une bande conservée hors ligne peut ajouter une quatrième copie, indépendante du réseau.
- Azure Storage
- SQL Server
Composants et flux
- Sauvegarde cohérente des applications vers un dépôt sur disque distinct du stockage de production
- Copie vers Azure Blob Storage hors site, avec rétention WORM verrouillée et administration séparée
- Disque local et stockage objet cloud pour diversifier les types de stockage, avec bande hors ligne en option
- Restauration depuis les copies dans un réseau isolé, puis contrôle des données et des fonctions applicatives
- Le « 0 » correspond aux erreurs de vérification à résoudre, sans promettre un risque nul
Rétention immuable et copie hors ligne
Une copie immuable reste accessible, mais sa modification et sa suppression sont bloquées pendant la rétention configurée. Une copie hors ligne est déconnectée. Dans les deux cas, le catalogue, les clés de chiffrement et les accès de secours doivent rester récupérables indépendamment de la production.
Réplication, snapshot et sauvegarde
Un réplica reçoit les modifications de la base primaire, y compris une suppression accidentelle. Un snapshot conserve un état antérieur d’un volume, mais reste exposé à la perte de la baie qui l’héberge. Une sauvegarde copiée dans un dépôt indépendant conserve des versions antérieures pendant la durée de rétention et permet leur restauration après la perte du stockage de production.
Références techniques Veeam · 3–2–1–1–0 · Microsoft · Azure Blob WORM · Microsoft · Redundancy, replication and backup
Maintenir une application en service avec la HA
Pour une application web, la haute disponibilité (High Availability, HA) consiste à exécuter plusieurs instances sur des hôtes distincts. Un load balancer répartit les requêtes HTTP entre ces instances et retire du routage celles qui ne répondent plus aux health checks. Pour une base à primaire unique, le failover promeut un réplica en serveur primaire et redirige les nouvelles connexions vers celui-ci.
Instances et trafic
Les health checks interrogent une URL de l’application pour vérifier qu’elle peut traiter une requête. Le load balancer est lui-même déployé sur plusieurs instances ou fourni par un service managé réparti entre zones. Les sessions utilisateur sont stockées dans un service partagé répliqué, ou dans des jetons vérifiables par chaque instance, afin qu’une requête puisse être traitée par un autre hôte.
Écritures et arbitrage
Dans un cluster à primaire unique, le quorum fixe le nombre de votes requis pour autoriser la désignation d’un primaire. Le fencing bloque l’accès de l’ancien primaire au stockage ou arrête son serveur avant la promotion d’un réplica. Ces mécanismes évitent que deux serveurs écrivent séparément dans la même base après une coupure réseau. La réplication des baies de stockage et les règles d’écriture du moteur SQL se configurent à leurs niveaux respectifs.
Capacité et dépendances
Les hôtes du site restant doivent disposer de la RAM, des CPU, du débit réseau et des opérations d’entrée-sortie par seconde (IOPS) nécessaires pour absorber la charge après failover. Le réseau de stockage utilise des switches et des chemins SAN distincts. Le DNS et le service d’authentification restent accessibles depuis le site de secours. Des essais sous charge vérifient la réponse de l’application pendant la perte d’un hôte, d’un lien réseau ou d’un site.
Deux sites proches hébergent des instances applicatives actives et des baies Pure Storage FlashArray synchronisées par ActiveCluster. Le load balancer retire les instances défaillantes du routage selon les health checks configurés. Pure1 Cloud Mediator détermine quelle baie conserve l’accès aux volumes lorsque la liaison de réplication est interrompue. Le cluster applicatif applique ses propres mécanismes de quorum et de fencing.
Linux
Pure Storage
Composants et flux
- Point d’entrée redondant et health checks applicatifs ; retrait des instances défaillantes du routage
- Instances réparties sur deux sites, avec capacité suffisante sur le site restant et gestion cohérente des sessions
- Volumes répliqués en mode synchrone ; la latence intersite entre dans le temps de validation des écritures
- Pure1 Cloud Mediator pour l’arbitrage du stockage ; quorum et fencing également prévus au niveau des clusters applicatifs
- Stockage actif-actif sans double écriture non coordonnée dans une base ; sauvegardes historiques indépendantes
En réplication synchrone, une écriture attend la confirmation du stockage ou du serveur distant selon le mode configuré. La latence aller-retour entre sites allonge donc le temps de réponse des écritures. En mode asynchrone, le primaire confirme sans attendre le réplica distant, qui peut ne pas avoir reçu les dernières transactions si le primaire devient irrécupérable. Les sauvegardes conservent séparément les versions historiques nécessaires pour annuler une suppression ou restaurer une base corrompue.
Références techniques Microsoft · Redundancy, replication and backup · Microsoft · Load balancer reliability · Pure Storage · ActiveCluster
Organiser le Disaster Recovery entre deux régions
Le Disaster Recovery (DR), documenté dans un plan de reprise d’activité (PRA), prépare le redémarrage d’une application après la perte de son datacenter ou de sa région cloud. Une seconde région héberge les réplicas, les sauvegardes ou les instances nécessaires à cette reprise. Les zones de disponibilité, situées dans une même région, servent à répartir les instances entre datacenters sans couvrir la perte de la région entière.
L’application écrit dans la base PostgreSQL primaire de la région A. Un réplica PostgreSQL reçoit ses journaux dans la région B, où les instances applicatives sont préparées sans trafic de production. En cas de perte de la région A, le runbook effectue le fencing de l’ancien primaire, promeut le réplica et redirige les connexions après les tests. Les sauvegardes conservent un historique distinct des réplicas.
Azure
Docker
PostgreSQL
Terraform
Composants et flux
- Deux régions distinctes ; application conteneurisée et PostgreSQL autogéré dans cet exemple Azure
- Réplication asynchrone du WAL ; le retard observé et la durabilité des données reçues déterminent le point récupérable
- Détection et décision, puis fencing de l’ancien primaire avant toute promotion pour éviter deux serveurs en écriture
- Capacité de secours, secrets et réseau préparés ; routage modifié après validation du nouveau service
- Failback vers la région initiale après resynchronisation des données et vérification des connexions
La région de secours reçoit une configuration réseau, les identités techniques, les secrets et les images des applications. Les quotas cloud et les ressources réservées doivent permettre de démarrer les instances prévues. Le runbook décrit le failover, l’exploitation depuis la région de secours et le failback vers la région initiale après resynchronisation des données.
| Architecture | État avant l’incident | Compromis de conception |
|---|---|---|
| Backup / Restore | Copies conservées ; plateforme à reconstruire | Peu de ressources de secours actives ; délai dominé par le transfert et la reconstruction |
| Actif-passif · Warm standby | Réplica alimenté et plateforme préconfigurée | Coût de secours permanent ; reprise accélérée, avec retard possible des données |
| Actif-actif · HA | Plusieurs instances servent déjà le trafic | Capacité et coordination supplémentaires ; disponibilité des applications à distinguer de celle du stockage |
Ces architectures présentent des exemples d’implémentation. Les essais mesurent le retard de réplication, la capacité du site de secours et le délai de remise en service des applications pour les comparer aux objectifs du projet.
Références techniques Microsoft · Multi-region disaster recovery · PostgreSQL · Standby and replication
Restaurer les données, reconstruire le service
La restauration d’un fichier récupère un document ou un répertoire. Celle d’une base rétablit ses tables et ses transactions. La reprise d’une application ajoute les serveurs, les accès et les API dont elle dépend. Après une compromission, les sauvegardes sont d’abord restaurées et contrôlées dans un réseau isolé avant d’autoriser les connexions de production.
Après une corruption de données ou une compromission, la reprise s’effectue dans un environnement isolé, sur site ou dans une autre région cloud. Une sauvegarde antérieure à l’incident, les journaux de la base, le code d’infrastructure et les accès de secours permettent de reconstruire un ensemble cohérent avant sa remise en service.
- Azure Storage
- Docker
- PostgreSQL
- Terraform
Composants et flux
- Sélection d’un point de reprise sain ; sauvegarde de base et chaîne complète des journaux pour le PITR
- Recréation du réseau, des instances et des services ; récupération des clés et des accès par un canal séparé
- Restauration de la base, puis démarrage des applications ; échanges externes bloqués pendant les essais
- Contrôles techniques et applicatifs, mesure du temps de reprise et du point récupéré, puis ouverture du trafic
- En cas d’échec, correction ou choix d’un autre point de reprise ; aucune ouverture automatique sur un test incomplet
Choisir la bonne séquence de restauration
Complète, incrémentale ou différentielle
Une sauvegarde complète copie l’ensemble des données couvertes par le job. Une incrémentale conserve les modifications depuis la précédente sauvegarde, ce qui impose de conserver les incréments nécessaires à la restauration. Une différentielle contient toutes les modifications depuis la dernière complète. La restauration utilise cette complète et la dernière différentielle. Le choix dépend du volume à copier à chaque exécution et du nombre de fichiers à relire pendant la restauration.
Restaurer une base à un instant précis avec le PITR
Pour PostgreSQL, une sauvegarde de base et une séquence continue de journaux de transactions (WAL) permettent le Point-in-Time Recovery. SQL Server utilise une complète, éventuellement une différentielle, puis les sauvegardes des journaux en mode de récupération approprié. La cible peut précéder une suppression accidentelle ; les transactions ultérieures sont absentes et doivent être rapprochées séparément.
Snapshots et restauration instantanée
Un snapshot cohérent avec l’application facilite certains retours arrière. La restauration instantanée, lorsqu’elle est prise en charge, peut démarrer une VM depuis le dépôt de sauvegarde avant sa migration vers le stockage de production. La disponibilité du dépôt et ses performances restent déterminantes ; le démarrage ne clôt pas la restauration.
Validation complète et exercices de reprise
Les essais couvrent la lecture des sauvegardes, l’intégrité des bases, l’authentification et des transactions applicatives représentatives. Les intégrations susceptibles d’envoyer des messages ou de modifier un système externe restent isolées. Le compte rendu mesure le point récupéré et le délai total, puis relève les écarts aux objectifs et les corrections à apporter.
Transférer 1 To sur un lien à 1 Gbit/s prend environ 2 h 15 au débit théorique. La décompression, le rejeu des journaux et les tests applicatifs allongent ensuite le délai de reprise. Le dimensionnement tient aussi compte du temps de récupération des archives cloud, des frais de transfert et des IOPS du stockage de secours.
Références techniques PostgreSQL · Point-in-time recovery · Microsoft · SQL Server restore sequences
Conception et intégration
- Dimensionnement du stockage SSD/NVMe et HDD, avec accès bloc, fichier ou objet
- Architecture des dépôts, rétention, immutabilité et séparation des accès
- Sauvegardes cohérentes des bases, VM, fichiers et configurations applicatives
- Clusters HA, load balancing, réplication et procédures de failover
- Automatisation du PRA, restauration isolée et mesure des objectifs RTO/RPO
- Supervision des jobs, du retard de réplication et de la capacité de secours
Les systèmes concernés
- Sauvegardes, journaux de transactions et PITR pour PostgreSQL et SQL Server
- Serveurs Linux, environnements virtualisés et applications conteneurisées
- Baies SAN/NAS, dépôts sur disque, bandes et stockage objet cloud
- Plateformes cloud, réseau et infrastructure as code
Service associéServeurs et hébergement →
Pour approfondir
Cinq scénarios d’attaque et les mesures qui en limitent les conséquences
Les accès exposés, les comptes, les paiements, les prestataires et la reprise demandent des protections différentes. Leur priorité dépend des activités que l’organisation doit préserver.
Vérifier qu’une sauvegarde permet réellement de reprendre l’activité
Une restauration complète vérifie les données, les applications et leurs dépendances. Son résultat permet de comparer les capacités de reprise aux besoins de l’organisation.
Solutions complémentaires
Parlons de votre projet
Un échange sur la conception, le développement et la mise en production de votre projet.