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

Le tableau ci-dessous traduit la règle en services OUTSCALE. Lisez-le de haut en bas comme un éloignement progressif du volume de production : la première ligne est la donnée vivante, la dernière celle qui survit à la perte du compte. La colonne Localisation est celle qui décide : deux copies qui partagent la même sous-région, ou pire le même compte EIM, ne comptent que pour une seule au regard du risque.

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

Empiler quatre niveaux n'est pas une coquetterie : chaque fréquence répond à un type d'incident différent, et la colonne Rétention est celle qui pilote la facture. Un point d'attention avant de recopier ce tableau : les rétentions se cumulent, le niveau 1 conserve en permanence sept snapshots par volume protégé. Sur une flotte de trente volumes, cela représente déjà deux cent dix snapshots facturés en continu, dimensionnez donc le niveau 1 sur les volumes réellement critiques plutôt que sur tout le parc.

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

Trois familles de contraintes tirent la durée de rétention dans des directions opposées, et c'est la plus longue qui gagne, pas la moyenne. Le point délicat est que les contraintes réglementaires poussent parfois dans les deux sens sur un même jeu de données : le RGPD impose de purger une donnée personnelle quand sa finalité est éteinte, une obligation de conservation comptable impose de la garder. La sortie de ce conflit passe par la granularité : séparez dans des sauvegardes distinctes ce qui relève de chaque régime, sinon la plus longue rétention s'applique de fait à tout.

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

Le test n'a de valeur que s'il mesure quelque chose. Deux étapes portent tout l'exercice : la vérification d'intégrité (étape 3), qui distingue une restauration qui rend des fichiers d'une restauration qui rend des données exploitables, et la mesure du RTO réel (étape 4), qui confronte l'architecture à l'engagement pris avec le métier. Chronométrez à partir de la décision de restaurer, pas du premier appel API : le temps de diagnostic et de validation compte dans le RTO vécu par le métier.

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

Rejouer chaque trimestre le même scénario facile ne valide qu'un seul chemin de restauration. Faites tourner les cas de manière à couvrir sur l'année les quatre briques de la colonne de droite, en commençant par les plus rapides. Les deux dernières lignes sont celles qui échouent le plus souvent en conditions réelles, parce qu'elles supposent des droits EIM et une infrastructure cible qui n'existent que sur le papier tant que personne ne les a exercés.

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

Le critère de qualité d'un runbook tient en une phrase : la personne d'astreinte à 3 h du matin doit pouvoir l'exécuter sans appeler son auteur. Cela disqualifie les formulations du type « restaurer le dernier snapshot » et impose des commandes copiables, avec les identifiants de ressources ou la façon exacte de les retrouver. Le point le plus souvent oublié n'est pas technique : ce sont les conditions de déclenchement, sans lesquelles l'astreinte passe une heure à se demander si elle a le droit de lancer la procédure.

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

Les deux scripts qui suivent sont les briques de base des niveaux 1 à 3 décrits plus haut. Ils sont volontairement courts, mais tous deux appliquent la même exigence : échouer bruyamment plutôt que se terminer sur un code de retour 0 trompeur, et relire l'état réel après avoir agi. Une sauvegarde qui se termine « en succès » sans avoir rien produit est le scénario qui coûte le plus cher.

Snapshot BSU automatisé en `oapi-cli`

Trois détails font la différence entre ce script et un oapi-cli CreateSnapshot lancé en cron. set -euo pipefail avec pipefail stoppe l'exécution si oapi-cli échoue alors que jq réussit, cas classique où le pipe masque l'erreur. Le test sur $SNAPSHOT_ID attrape la réponse d'API valide mais vide. Enfin, l'appel final à ReadSnapshots vérifie que le snapshot existe côté OUTSCALE, ce qui est la seule preuve utilisable dans un rapport de sauvegarde. Le snapshot est créé en mode asynchrone : il apparaît d'abord à l'état in-queue ou pending, l'état completed peut mettre plusieurs minutes selon la taille du volume.

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

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')

if [ -z "$SNAPSHOT_ID" ] || [ "$SNAPSHOT_ID" = "null" ]; then
  echo "ERREUR : aucun SnapshotId retourné pour $VOLUME_ID" >&2
  exit 1
fi

# 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\"}
  ]"

# Relire l'état réel du snapshot côté API avant de déclarer le succès
oapi-cli ReadSnapshots \
  --Filters "{\"SnapshotIds\": [\"$SNAPSHOT_ID\"]}" \
  | jq -r '.Snapshots[0] | "\(.SnapshotId) \(.State) \(.Progress)%"'

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

Export OOS depuis une VM

Ce second script produit la copie hors-site du niveau 3. Le point de vigilance est le pg_dump en tête de pipe : sans pipefail, un dump interrompu à mi-chemin produit une archive gzip valide mais tronquée que aws s3 cp téléversera sans broncher. La ligne aws s3api head-object qui suit le téléversement sert à confirmer que l'objet est bien arrivé et à comparer sa taille, avant de supprimer la copie locale. Le paramètre --endpoint-url est obligatoire : sans lui, l'aws-cli viserait les points d'accès AWS et non OOS.

# Sur la VM, dump de la base de données puis upload vers OOS
set -euo pipefail

DATE=$(date +%Y-%m-%d)
DUMP_FILE="/tmp/db-prod-$DATE.sql.gz"
BUCKET="monprojet-audit-backups"
KEY="db-prod/$DATE.sql.gz"
OOS_ENDPOINT="https://oos.eu-west-2.outscale.com"

# 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://$BUCKET/$KEY" --endpoint-url "$OOS_ENDPOINT"

# Relire l'objet distant avant de supprimer la copie locale
aws s3api head-object --bucket "$BUCKET" --key "$KEY" \
  --endpoint-url "$OOS_ENDPOINT" \
  --query 'ContentLength' --output text

# 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

Ces sept écarts ont un point commun : aucun ne provoque d'incident visible au moment où on les commet. Ils se paient tous le jour de la restauration, ce qui explique leur persistance. Servez-vous de la colonne Conséquence comme grille de relecture de votre propre dispositif, ligne par ligne. Les trois premières lignes sont celles qui transforment un incident récupérable en perte définitive, traitez-les avant les autres.

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.

Pour aller plus loin

Référence Terraform sur OUTSCALE : Décrire en code les snapshots, les buckets d'export et leurs politiques de rétention.
Inventaire dynamique Ansible : Cibler les VMs à sauvegarder par tag plutôt que par une liste d'identifiants qui se périme.
Pilier Reliability : Les points d'audit qui vérifient RPO, RTO, règle 3-2-1 et runbook de reprise.