Sauvegardes OUTSCALE : RPO, RTO et plan de reprise

Une stratégie de sauvegarde sans définition explicite du RPO et du RTO n’est pas une stratégie — c’est une intention. Cette page articule les briques techniques OUTSCALE (snapshots BSU, exports OOS, copies cross-AZ) au sein d’une discipline de sauvegarde structurée : règle 3-2-1, politique de rétention, test de restauration trimestriel, plan de reprise documenté. Page tagguée pour les piliers Well-Architected Reliability (objectif principal) et Operational Excellence (la sauvegarde n’est utile que si elle est exploitable).

Ce que vous allez apprendre

Définir RPO et RTO avec le métier — la décision la plus structurante.
Appliquer la règle 3-2-1 sur OUTSCALE (3 copies, 2 supports, 1 hors-site).
Articuler snapshots BSU + exports OOS pour couvrir les besoins applicatifs et long terme.
Construire une politique de rétention adaptée aux contraintes (légales, opérationnelles).
Tester la restauration — discipline trimestrielle non négociable.
Documenter le plan de reprise et le runbook qui va avec.

Prérequis

Avoir lu Stockage — BSU, volumes, IOPS — les snapshots BSU sont la brique principale.
Avoir lu Stockage — OOS, versioning, lifecycle — OOS sert de cible long terme et d’archive.
Notions de Régions et sous-régions OUTSCALE — la résilience multi-AZ structure le plan de reprise.
oapi-cli et aws-cli configurés.

RPO et RTO — les deux questions à poser au métier

Toute stratégie de sauvegarde commence par deux décisions métier qu’aucune discussion technique ne peut remplacer.

RPO — Recovery Point Objective

Le RPO est la quantité maximale de données qu’on accepte de perdre en cas d’incident, mesurée en temps. Concrètement : si l’incident survient à 14 h 30 et que le dernier snapshot date de 2 h 00, le RPO réel est de 12 h 30.

Métier	Question RPO typique	Réponse type
Site vitrine	« Que se passe-t-il si on perd les commits de la journée ? »	RPO de 24 h acceptable
E-commerce	« Que se passe-t-il si on perd 1 h de commandes ? »	RPO de 5-15 min
Banque / paiements	« Que se passe-t-il si on perd 1 minute de transactions ? »	RPO < 1 min — réplication synchrone
Données analytiques	« Que se passe-t-il si on perd la journée d’événements ? »	RPO de 6-24 h, recalculable depuis les sources

Plus le RPO est court, plus la stratégie est coûteuse (snapshots fréquents, réplication continue, architecture multi-AZ active-active). Le métier doit accepter le coût correspondant à son niveau de tolérance.

RTO — Recovery Time Objective

Le RTO est le temps maximum acceptable entre l’incident et la reprise complète du service. Concrètement : si l’incident survient à 14 h 30 et que la restauration complète prend jusqu’à 18 h 30, le RTO est de 4 h.

Métier	Question RTO typique	Réponse type
Site vitrine	« Acceptable que le site soit indisponible 24 h ? »	RTO de 24 h
E-commerce	« Combien d’heures sans service au pic de Noël ? »	RTO de 1-4 h
Production industrielle critique	« Une heure de coupure = combien de pertes ? »	RTO < 1 h
Système de paiement temps réel	« Une seconde d’indisponibilité = ? »	RTO de quelques secondes — bascule automatique

Le RTO contraint l’architecture : un RTO de 1 h interdit de devoir redéployer 50 VMs depuis zéro. Pour des RTO courts, l’infrastructure secondaire doit être déjà prête (warm standby) ou même active (active-active).

Définir RPO/RTO avant la conception

Le piège classique consiste à définir RPO/RTO après avoir vu ce que la technique permet. C’est l’inverse : le métier définit la cible, la technique trouve la solution (ou explique le coût). Sans cette discipline, on bâtit une infrastructure « par défaut » dont les caractéristiques ne sont pas alignées avec le besoin réel.

La règle 3-2-1 appliquée à OUTSCALE

La règle 3-2-1 est le standard de l’industrie pour la sauvegarde sérieuse. Elle stipule :

3 copies des données — l’original + au moins 2 sauvegardes.
2 supports différents — pour ne pas dépendre d’un seul mécanisme.
1 copie hors-site — pour résister à un incident sur le site principal.

Application sur OUTSCALE

Copie	Support	Localisation
1ère : données vivantes	Volume BSU attaché à la VM	Sous-région principale (ex: `eu-west-2a`)
2ème : snapshot quotidien	Snapshot BSU	Stocké hors du volume mais dans la même région
3ème : copie hors-site	Export OOS dans un autre bucket / autre compte	OOS dans une autre sous-région, voire dans un autre compte (paying / linked, cf. multi-comptes)

Le 3ème niveau est ce qui résiste à un incident majeur — perte d’AZ, compromission du compte principal, erreur humaine massive. C’est aussi le plus souvent omis dans les stratégies improvisées.

Renforcement Object Lock

Pour les sauvegardes les plus critiques, activer l’object lock sur le bucket OOS de destination (cf. OOS). Cela rend les fichiers de sauvegarde immuables pendant la durée définie — protection contre les ransomwares qui chiffreraient les sauvegardes.

Articuler snapshots BSU et exports OOS

Les deux mécanismes sont complémentaires, pas concurrents.

Snapshots BSU — sauvegarde courte / moyenne

Un snapshot BSU capture l’état d’un volume à un instant T. C’est le mécanisme principal pour :

Sauvegarde quotidienne des bases de données et fichiers applicatifs.
Snapshot avant maintenance ou changement de schéma.
Image dorée d’un volume préparé pour duplication.

Avantages : rapide, incrémental, restauration en quelques minutes.

Limites : le snapshot reste lié au compte OUTSCALE d’origine. Si le compte est compromis, les snapshots peuvent être supprimés en bloc. Le snapshot reste lié à une région (mais peut être copié vers d’autres sous-régions de la même région).

Exports OOS — sauvegarde long terme et hors-site

Un export OOS consiste à copier les données (dump de base de données, archive tar, image d’OMI) vers un bucket OOS, idéalement dans :

Un bucket dédié sauvegardes, séparé des autres usages.
Un autre compte OUTSCALE (compte audit / sauvegardes), pour échapper à une compromission du compte principal.
Avec versioning + object lock + lifecycle pour la durée de rétention.

Avantages : hors-site logique (autre compte = autre périmètre EIM), durée de rétention illimitée, protection ransomware via object lock.

Limites : le coût du transfert et du stockage long terme, plus la complexité opérationnelle de scripter l’export.

Stratégie combinée

Niveau	Quoi ?	Fréquence	Rétention
Niveau 1	Snapshot BSU automatisé	Quotidien	7 jours roulants
Niveau 2	Snapshot BSU hebdomadaire	Hebdomadaire	4 semaines
Niveau 3	Export OOS (compte audit)	Mensuel	12 mois
Niveau 4	Export OOS object-locked	Annuel	Selon contraintes légales

Cette stratégie permet :

Récupération rapide d’une suppression accidentelle récente (niveaux 1 et 2).
Récupération possible sur l’année passée (niveau 3).
Conformité réglementaire (niveau 4 pour les obligations légales — santé, fiscalité, etc.).

Politique de rétention — l’art de l’équilibre

Une politique de rétention trop courte expose à perdre des données, trop longue fait exploser le coût. Quelques principes.

Aligner sur les contraintes

Réglementaires : RGPD impose des durées maximum (purge), HDS impose des durées minimum (10 ans pour les données médicales), comptabilité impose 10 ans, etc.
Métier : combien de temps en arrière le métier peut avoir besoin de remonter ?
Coûts : la rétention longue sur OOS reste raisonnable, sur BSU elle devient vite coûteuse.

Lifecycle automatisé

Implémenter la politique en lifecycle automatisé, pas en discipline humaine. Un humain qui doit penser à supprimer les vieilles sauvegardes finit par les oublier — automatiser élimine le risque.

Snapshots BSU anciens : à supprimer via un script oapi-cli DeleteSnapshot planifié.
Exports OOS : utiliser le lifecycle policy OOS qui purge automatiquement (cf. OOS).

Le test de restauration — non négociable

Une sauvegarde non testée n’est pas une sauvegarde. C’est la règle la plus violée en pratique et celle qui fait le plus de dégâts le jour J.

Méthode

Test trimestriel sur un environnement de pré-production :

Sélectionner une sauvegarde récente (snapshot ou export OOS).
Restaurer dans un environnement de test.
Vérifier l’intégrité des données (checksums, requêtes métier de validation).
Mesurer le RTO réel (temps entre le déclenchement et la disponibilité).
Comparer au RTO cible — écart à corriger si dépassement.
Documenter la session : qui, quand, quoi, durée, écarts.

Cas d’école à tester

Plusieurs scénarios à couvrir au fil des trimestres :

Scénario	Brique testée
Suppression accidentelle d’une table	Snapshot BSU récent + restauration ciblée
Corruption d’une base de données	Export OOS + restauration complète
Compromission du compte principal	Export OOS depuis un compte audit
Perte d’une sous-région entière	Bascule sur infrastructure pré-déployée dans une autre sous-région
Ransomware qui chiffre tout	Restauration depuis un export OOS object-locked

Plan de reprise (PRA) — le runbook

Un PRA documenté est ce qui transforme un test réussi en un vrai filet de sécurité. Le runbook doit être lisible par n’importe qui d’astreinte, pas seulement par celui qui l’a écrit.

Ce que doit contenir un runbook PRA

Conditions de déclenchement — à partir de quand on déclenche le PRA ? (perte d’AZ détectée, base de données corrompue, etc.)
Liste des contacts : on-call technique, RSSI, métier, OUTSCALE support.
Procédure étape par étape — commandes exactes à exécuter, dans quel ordre.
Points de validation entre étapes — comment vérifier que chaque étape a réussi.
Critères de succès — quand considère-t-on le service comme rétabli.
Communication — qui informer, à quels moments, sur quels canaux.

Maintenance du runbook

Un PRA non maintenu finit obsolète au moment où on en aurait besoin. Discipline :

Revue après chaque changement d’architecture significatif.
Mise à jour à chaque test de restauration trimestriel.
Versionné en Git, dans un dépôt accessible aux astreintes.
Game day annuel : exercice complet de simulation de l’incident le plus probable.

Industrialiser les sauvegardes en CLI / IaC

Snapshot BSU automatisé en `oapi-cli`

#!/bin/bash
# Script de sauvegarde quotidienne (à mettre dans un cron)

VOLUME_ID="vol-abc12345"
DATE=$(date +%Y-%m-%d)

# Créer le snapshot
SNAPSHOT_ID=$(oapi-cli CreateSnapshot \
  --VolumeId "$VOLUME_ID" \
  --Description "Sauvegarde quotidienne $DATE" \
  | jq -r '.Snapshot.SnapshotId')

# Tagger le snapshot
oapi-cli CreateTags \
  --ResourceIds "[\"$SNAPSHOT_ID\"]" \
  --Tags "[
    {\"Key\": \"backup-type\", \"Value\": \"daily\"},
    {\"Key\": \"backup-date\", \"Value\": \"$DATE\"},
    {\"Key\": \"source-volume\", \"Value\": \"$VOLUME_ID\"}
  ]"

echo "Snapshot $SNAPSHOT_ID créé pour $VOLUME_ID le $DATE"

Export OOS depuis une VM

# Sur la VM, dump de la base de données puis upload vers OOS
DATE=$(date +%Y-%m-%d)
DUMP_FILE="/tmp/db-prod-$DATE.sql.gz"

# Dump compressé
pg_dump -h db.example.local -U backup_user db_prod | gzip > "$DUMP_FILE"

# Upload vers OOS (compte audit) avec endpoint OUTSCALE
aws s3 cp "$DUMP_FILE" \
  "s3://monprojet-audit-backups/db-prod/$DATE.sql.gz" \
  --endpoint-url https://oos.eu-west-2.outscale.com

# Cleanup local
rm "$DUMP_FILE"

Industrialisation en pipeline

Sur des environnements en production, les sauvegardes passent par un pipeline :

Job CI/CD (GitHub Actions, GitLab CI, Forgejo) qui s’exécute selon une planification (cron schedule).
Identifiants AK/SK dédiés stockés dans le gestionnaire de secrets du pipeline (jamais en clair).
Notifications sur succès / échec (Slack, mail, webhook).
Métriques exportées (durée, taille de la sauvegarde) pour suivre la dérive éventuelle.
Alerte si une sauvegarde échoue ou n’a pas eu lieu dans les délais attendus.

Cette approche est traitée en détail dans le Volet 3 — Industrialiser (IaC).

Bonnes pratiques (par pilier Well-Architected)

1. Définir RPO/RTO avec le métier — pilier Reliability

La discipline non négociable : avant tout choix technique, déterminer avec le métier le RPO et le RTO acceptables. Cela évite à la fois la sur-ingénierie (sauvegarde temps réel sur un site vitrine) et le sous-dimensionnement (RPO de 24 h sur un système de paiement).

2. Règle 3-2-1 systématique — pilier Reliability

Sur tout système de production sérieux : 3 copies, 2 supports, 1 hors-site. La copie hors-site (compte audit ou autre sous-région) est ce qui résiste à un incident majeur.

3. Object lock sur les sauvegardes critiques — pilier Reliability

Pour les sauvegardes qui doivent résister à un ransomware ou à une suppression malveillante : object lock activé sur le bucket OOS de destination, avec une durée de rétention adaptée.

4. Test de restauration trimestriel — piliers Reliability + Operational Excellence

Sans test régulier, la sauvegarde est une superstition. Test trimestriel sur environnement de pré-production, avec mesure du RTO réel et documentation des écarts.

5. Runbook versionné en Git — pilier Operational Excellence

Le PRA est un document vivant versionné en Git, accessible aux astreintes. Mis à jour à chaque changement d’architecture, testé annuellement par game day.

6. Tagging discipliné — pilier Operational Excellence

Chaque snapshot, chaque export OOS doit porter les tags qui permettent de retrouver l’origine et la date : backup-type, backup-date, source-volume ou source-database, env, project.

7. Monitoring des sauvegardes — pilier Operational Excellence

Une sauvegarde qui n’a pas eu lieu doit lever une alerte dans les minutes ou les heures qui suivent — pas être découverte le jour de l’incident. Mécaniquement : métrique dans le système de monitoring + alerte si pas de nouvelle sauvegarde dans la fenêtre attendue.

Antipatterns à éviter

Antipattern	Conséquence	Discipline correcte
Pas de RPO/RTO défini	Sauvegarde « par défaut » qui ne sert pas le besoin réel	Définition explicite avec le métier en amont
Snapshots uniquement (pas de copie hors-site)	Compromission du compte = perte définitive	Règle 3-2-1 systématique
Sauvegardes non testées	Découverte de leur inutilité au moment de l’incident	Test trimestriel non négociable
Pas de runbook	Procédure improvisée en pleine crise	Runbook versionné, à jour, testé
Sauvegardes sans tags	Impossible de retrouver l’origine, ménage difficile	Tags `backup-date`, `source-*`, `env`
Pas de monitoring des sauvegardes	Échecs silencieux qui s’accumulent	Alerte sur sauvegarde manquée ou en échec
Object lock non activé sur les sauvegardes critiques	Ransomware peut chiffrer les sauvegardes	Object lock pour les sauvegardes long terme critiques

Sauvegardes sous l’angle Well-Architected

Reliability — l’objectif principal

Le pilier Reliability est entièrement servi par la stratégie de sauvegarde :

Continuité garantie en cas d’incident matériel, logique ou humain.
RPO et RTO mesurables et alignés avec les besoins métier.
Multiple niveaux de défense : snapshots locaux + exports cross-AZ + exports cross-account + object lock.

Les questions clés du pilier Reliability adressées par cette page :

Combien de données peut-on perdre dans le pire cas ? — RPO mesurable.
Combien de temps pour revenir en marche ? — RTO mesurable, testé trimestriellement.
Que se passe-t-il si le compte principal est compromis ? — exports OOS dans un compte audit.
Que se passe-t-il en cas de ransomware ? — object lock sur les sauvegardes critiques.

Operational Excellence — la sauvegarde n’est utile que si exploitable

Le pilier Operational Excellence s’applique à comment on opère la sauvegarde :

Industrialisation via pipelines CI/CD (pas de scripts manuels qu’on oublie).
Monitoring systématique avec alertes.
Runbook documenté et maintenu à jour.
Test trimestriel comme cycle de revue.

Une sauvegarde sans cette discipline opérationnelle est un coût stocké sans valeur de récupération réelle.

À retenir

RPO = quantité maximale de données acceptable à perdre. RTO = temps maximum acceptable avant reprise complète. Les deux sont des décisions métier, pas techniques.
Règle 3-2-1 : 3 copies, 2 supports, 1 hors-site — appliquée sur OUTSCALE via volume BSU + snapshot BSU + export OOS dans un compte séparé.
Articulation snapshots BSU (court / moyen terme) + exports OOS (long terme + hors-site) + object lock (immutabilité critique).
Test de restauration trimestriel non négociable — sans test, la sauvegarde n’est pas validée.
Runbook PRA versionné en Git, à jour, testé annuellement par game day.
Tagging des sauvegardes (backup-date, source-*, env) pour la traçabilité et le cleanup automatisé.
Monitoring + alertes sur les sauvegardes pour détecter les échecs silencieux.

Prochaines étapes

Stockage — BSU, volumes, IOPS Mécanique des snapshots BSU à la base du niveau 1 et 2 de la 3-2-1.

Stockage — OOS, versioning, lifecycle Cible pour les exports long terme + object lock pour l'immutabilité.

EIM patterns multi-comptes Compte audit / sauvegardes pour la copie hors-site logique.