Stratégie de backup cloud : RTO, RPO et automatisation
Obtenez un résumé intelligent et des insights personnalisés
Un backup application cloud stratégie repose sur deux objectifs mesurables : le RTO (temps de restauration acceptable) et le RPO (perte de données acceptable). Pour cela, vous devez combiner plusieurs méthodes de sauvegarde, une automatisation des jobs et des tests de restauration réguliers. Sans ces trois piliers, une sauvegarde reste une simple copie de fichiers, pas un plan de reprise fiable.
Les entreprises tolèrent en moyenne 72 minutes de perte de données par an sur leurs applications critiques. En réalité, elles en subissent 127 minutes, selon une étude Veeam menée auprès de directeurs des systèmes d’information. Cet écart illustre un problème courant : le RPO théorique ne correspond pas à la réalité. Alors, comment définir vos objectifs et choisir une stratégie de backup adaptée à votre architecture cloud, ou automatiser vos restaurations ? AquilApp vous accompagne sur ces chantiers de résilience.
Comment définir vos objectifs de récupération de RTO et RPO ?
Le RTO (Recovery Time Objective) est la durée maximale acceptable pour restaurer une application après un incident. Le RPO (Recovery Point Objective) est la quantité maximale de données que l’entreprise accepte de perdre, mesurée en temps.
Ces deux indicateurs ne se définissent jamais au hasard. Ils dépendent de la criticité métier de chaque application. Par exemple, une application de paiement n’a pas le même besoin qu’un outil de reporting interne.
L’écart entre RPO théorique et RPO réel, mesuré par Veeam, montre un risque fréquent. Les entreprises fixent un objectif ambitieux sur le papier. Elles ne vérifient pas si leur infrastructure de sauvegarde le tient réellement. Un RPO n’a de valeur que s’il est testé.
| Criticité applicative | RTO cible | RPO cible | Exemple d’application |
|---|---|---|---|
| Critique | < 1 heure | < 15 minutes | Paiement, authentification |
| Importante | < 4 heures | < 1 heure | CRM, ERP métier |
| Secondaire | < 24 heures | < 24 heures | Outils internes, reporting |
Source : ordres de grandeur usuels en architecture cloud, à ajuster selon votre contexte métier.
Ce tableau sert de base de discussion. Chaque application doit recevoir son propre couple RTO/RPO, validé par les métiers et non uniquement par la DSI.
Quelles sont les 3 stratégies de backup cloud ?
Vous avez notamment le choix entre trois approches pour structurer la majorité des architectures de backup cloud. Elles se combinent souvent plutôt qu’elles ne s’excluent.
Le snapshots natifs du fournisseur cloud
Un snapshot est une image instantanée d’un disque ou d’une base de données. Elle est prise directement par le fournisseur cloud (AWS EBS Snapshot, Azure Managed Disk Snapshot). Cette méthode est rapide à mettre en place et peu coûteuse.
Néanmoins, elle présente une limite importante. Le snapshot reste dans le même compte et souvent la même région que la production. En cas de compromission du compte cloud, snapshot et données de production peuvent être perdus ensemble.
Le backup as a Service (BaaS) avec agent
Un outil de BaaS déploie un agent qui capture les données applicatives et les stocke hors du périmètre de production. Exemple : Veeam, Rubrik, Cohesity, ou les services natifs comme AWS Backup. Cette approche permet l’immuabilité et le chiffrement des sauvegardes.
Par contre, elle demande une configuration plus poussée. Il n’empêche qu’elle est recommandée pour toute application jugée critique.
La réplication continue et DRaaS
Le DRaaS (Disaster Recovery as a Service) réplique en continu les données vers un site secondaire. Celui-ci prêt à prendre le relais en quelques minutes. Cette stratégie vise un RTO très court, souvent inférieur à une heure.
Évidemment, son coût est le plus élevé des trois approches. Notre conseil : réservez-la aux applications dont l’indisponibilité génère une perte financière immédiate.
| Stratégie | RTO obtenu | RPO obtenu | Coût relatif | Cas d’usage |
|---|---|---|---|---|
| Snapshot natif | Quelques heures | Quelques heures | Faible | Environnements non critiques |
| BaaS avec agent | 1 à 4 heures | 15 min à 1 heure | Moyen | Applications importantes |
| Réplication / DRaaS | < 1 heure | Quasi nul | Élevé | Applications critiques |
En pratique, une architecture solide de backup application cloud stratégie combine les trois niveaux. Notamment :
- Les snapshots couvrent le quotidien
- Le BaaS sécurise les données critiques hors production
- Et le DRaaS protège les applications à fort impact business.
Il reste à savoir comment migrer vos applications dans le cloud. Plus de conseils dans notre autre article.
Comment réussir votre Backup des bases de données : spécificités PostgreSQL, MongoDB, Redis
Chaque moteur de base de données impose ses propres méthodes de sauvegarde. Autrement dit, un backup générique de serveur ne suffit pas à protéger une base de données de manière cohérente.
PostgreSQL
pg_dump exporte une base sous forme de fichier SQL ou d’archive binaire. Cette méthode logique convient aux petites bases. Elle facilite la portabilité entre versions.
Par ailleurs, pg_basebackup copie l’intégralité du cluster au niveau fichier. Cette méthode physique est plus rapide sur de gros volumes. D’ailleurs, vous pouvez la combiner à l’archivage des journaux WAL (Write-Ahead Log). De quoi permettre la PITR (Point-In-Time Recovery), soit la restauration à une seconde précise avant un incident.
Vous avez une base de production ? Lla documentation officielle PostgreSQL recommande une combinaison des deux approches : un pg_dump quotidien pour la portabilité, et un archivage WAL continu pour la PITR.
Faites notamment attention à surveiller votre application en production. Lisez notre autre article pour plus de détails.
MongoDB
mongodump capture une image cohérente d’une base MongoDB. Ce qui est idéalement exécuté sur un membre secondaire du replica set pour ne pas impacter la production. De plus, l’option –oplog garantit la cohérence sur un cluster en écriture active.
Pour les clusters shardés de grande taille, MongoDB Atlas propose une sauvegarde continue avec restauration à un point dans le temps. Cette option managée évite de développer une orchestration de backup multi-shards en interne. Ce qui est un chantier technique coûteux en ressources d’ingénierie.
Redis
Redis est une base en mémoire. Sans configuration de persistance, toutes les données disparaissent au redémarrage du serveur. Deux mécanismes existent :
- Le RDB, qui prend des snapshots périodiques
- Et l’AOF (Append Only File), qui journalise chaque écriture.
À noter : le RDB offre une reprise rapide, mais peut perdre les écritures survenues depuis le dernier snapshot. L’AOF réduit ce risque au prix d’un espace disque plus important. Pour les usages critiques (sessions, files d’attente de paiement), le mode hybride RDB + AOF est recommandé.
Comment automatiser et tester vos restaurations pour un bon backup application cloud stratégie ?
Un backup application cloud stratégie non testé n’est pas une sauvegarde fiable. C’est une hypothèse. Donc, voici nos conseils.
La règle 3-2-1-1-0
L’ANSSI recommande depuis 2022 la règle 3-2-1-1-0 :
- 3 copies des données,
- Sur 2 supports différents
- Dont 1 copie hors site
- 1 copie immuable
- Et 0 erreur constatée lors des tests de restauration.
C’est une évolution de la règle historique 3-2-1. Elle répond directement aux ransomwares modernes, qui ciblent en priorité les dépôts de sauvegarde avant de chiffrer la production.
Ce risque n’est pas théorique. Selon le rapport Veeam 2025 sur les ransomwares, 89 % des entreprises victimes ont vu leurs dépôts de sauvegarde directement attaqués. Une copie immuable, non modifiable même par un compte administrateur compromis, devient donc indispensable.
Automatiser sans exception
L’automatisation élimine l’oubli humain. Ce qui est la principale cause de sauvegarde manquante. Elle passe par :
- Des jobs planifiés (cron, CronJob Kubernetes, scheduler cloud natif).
- Une intégration dans les pipelines CI/CD pour les bases applicatives.
- Des alertes automatiques en cas d’échec d’un job de sauvegarde.
- Une politique de rétention définie dans le code d’infrastructure (Infrastructure as Code).
Tester la restauration, pas seulement la sauvegarde
Un test de restauration consiste à recréer l’application à partir de la sauvegarde, dans un environnement isolé. Puis, vous allez vérifier l’intégrité des données. Faites cette étape tous les mois sur un échantillon d’applications. Puis, une fois par an, demandez un test de restauration complet incluant toute l’infrastructure.
Sans ce test, une entreprise découvre souvent la corruption d’une sauvegarde au pire moment : pendant l’incident réel.
Comment optimiser le coût de votre backup application cloud stratégie sans le compromettre ?
Le coût d’un backup application cloud stratégie dépend de quatre facteurs :
- Le volume de données
- La fréquence des sauvegardes
- La durée de rétention
- Et la classe de stockage choisie.
Généralement, les fournisseurs cloud proposent plusieurs niveaux de stockage, du plus rapide au plus économique. Un stockage d’archivage coûte nettement moins cher qu’un stockage standard. Cependant, il impose un délai de récupération plus long.
| Classe de stockage | Coût indicatif | Délai de récupération | Cas d’usage |
|---|---|---|---|
| Standard (chaud) | Le plus élevé | Immédiat | Backups récents, restauration rapide |
| Accès peu fréquent | Intermédiaire | Quelques heures | Backups de 30 à 90 jours |
| Glacier / archivage froid | À partir de 0,004 $/Go/mois | Minutes à heures | Archives légales, conformité |
| Deep Archive | Le plus bas | Jusqu’à 12 heures | Rétention longue durée (7-10 ans) |
Source : grille tarifaire AWS S3, 2026. Les tarifs varient selon la région et le fournisseur.
Attention néanmoins, vous devez aller au-delà du stockage pour estimer le coût de votre backup application cloud stratégie. En effet, les frais de sortie de données (egress fees) ne doivent pas être minimiser. D’ailleurs, ils sont facturés lors de la récupération. De plus, ils peuvent représenter une part importante de la facture en cas de restauration d’un gros volume.
Trois leviers permettent d’optimiser ce budget sans réduire la protection :
- Mettre en place des règles de cycle de vie (lifecycle policies) qui déplacent automatiquement les anciennes sauvegardes vers des classes moins coûteuses.
- Ajuster la rétention par type de donnée plutôt que d’appliquer une règle unique à toute l’infrastructure.
- Comparer les frais de sortie entre fournisseurs avant de choisir la destination du stockage hors site.
Vous pouvez également envisager le multi-cloud : réduire le risque de vendor lock-in.
Quid des services de backup et de résilience chez AquilApp ?
AquilApp accompagne les équipes techniques sur l’ensemble de la chaîne de résilience applicative. Notre méthode commence par un cadrage des objectifs RTO et RPO, application par application. Le tout se fait en lien avec les enjeux métier de chaque projet. Ensuite, nous concevons l’architecture de backup adaptée : snapshots, BaaS ou réplication, selon la criticité et le budget.
Notre expertise couvre les bases de données les plus courantes en environnement cloud (PostgreSQL, MongoDB, Redis). Idem de l’automatisation complète des jobs de sauvegarde et des tests de restauration. Nous intervenons aussi bien sur des projets de développement logiciel sur mesure que sur l’audit d’infrastructures existantes.
FAQ sur la stratégie de sauvegarde (Backup) d'application Cloud
* **RTO (Délai maximal d’interruption) :** Mesure le temps maximal tolérable pendant lequel l’application peut rester indisponible après une panne avant d’impacter gravement l’activité.
* **RPO (Perte de données maximale admissible) :** Mesure la quantité maximale de données que l’entreprise peut se permettre de perdre, exprimée en durée écoulée entre la dernière sauvegarde réussie et le moment de l’incident.
* **Tests automatisés et mensuels :** Contrôle régulier de la capacité de restauration sur un échantillon applicatif restreint.
* **Exercice global annuel :** Simulation complète de désastre (*Disaster Recovery Exercise*.
* **SLA du Cloud Provider :** Garantit uniquement la disponibilité matérielle et le taux de fonctionnement de l’infrastructure physique ou du service managé.
* **Gestion des sauvegardes :** La protection contre les erreurs de manipulation interne, la corruption logicielle, les suppressions malveillantes ou les attaques par **Ransomware** reste de la responsabilité exclusive de l’entreprise cliente.
* **Limites du Snapshot :** Par défaut, un snapshot reste hébergé dans le même compte et la même région géographique que l’environnement de production.
* **Stratégie recommandée :** Une sauvegarde robuste doit intégrer la copie distante des données dans un compte/région séparé ainsi que l’utilisation de **stockages immuables**.
Conclusion
Un backup application cloud stratégie efficace ne se résume pas à un job de sauvegarde planifié. Il repose aussi sur des objectifs RTO et RPO définis par application. À cela s’ajoute une combinaison de méthodes adaptées à chaque base de données, et des tests de restauration réguliers.
Respectez notamment la règle 3-2-1-1-0. Aujourd’hui, c’est la référence face aux ransomwares qui ciblent directement les dépôts de sauvegarde.
À noter : cette stratégie s’inscrit dans une démarche plus large de continuité d’activité. Pour aller plus loin sur le pilotage business de la reprise après sinistre, consultez notre guide sur le plan de reprise et de continuité d’activité.
Besoin d’évaluer votre stratégie de backup actuelle ? Demandez un audit à l’équipe AquilApp.
