Continuité · Sauvegarde / PRA

Sauvegarde et reprise d'activité : RPO, RTO et tests de restauration

Une sauvegarde sans RPO/RTO définis ni tests de restauration n'est qu'un coût disque. Un PRA sans procédure ni fenêtres de communication est un plan papier. En modèle infogéré, les deux couches doivent faire partie du SLA — pas un add-on « quand il y a le temps ».

RPO et RTO — en clair

• RPO (Recovery Point Objective) — quelle perte de données est acceptable (par exemple 15 minutes, 4 heures),
• RTO (Recovery Time Objective) — en combien de temps l'environnement doit revenir en service.

Des valeurs plus basses impliquent une architecture plus coûteuse : snapshots plus fréquents, réplication, warm/hot standby, site distinct. Toutes les applications n'ont pas besoin d'un RPO quasi nul. Chez BaseCloud, RPO/RTO ne s'appliquent que lorsqu'ils sont contractuels après évaluation. Nous ne publions pas de date de « dernière restauration » comme promesse produit.

Erreurs fréquentes sur le terrain

• sauvegarde sur la même baie / la même AZ que la production,
• pas de test de restauration (ou un test « tous les deux ans »),
• flou sur qui autorise la restauration et qui communique avec les clients,
• rétention trop courte pour la comptabilité ou les exigences de filière.

Ce que couvre le PRA infogéré chez BaseCloud

Dans les formules Professional et Enterprise, les procédures de sauvegarde et de reprise font partie de l'exploitation : calendriers, suivi des jobs, rétention et participation aux tests PRA. Le périmètre RPO/RTO se précise après évaluation — nous ne promettons pas « zéro interruption » sans une architecture qui le permet vraiment.

Liste de contrôle avant de signer le SLA

• liste des systèmes critiques et de leurs responsables métier,
• cibles RPO/RTO par système (pas un seul chiffre pour toute l'entreprise),
• fréquence et forme des tests de restauration,
• chemin d'escalade et compte rendu après incident.

Voir les formules · DORA et continuité d'activité · Plus d'articles