Le mot cloud cache bien les détails. Les disques, serveurs et réseaux existent encore; on les commande autrement et ils sont chez quelqu’un d’autre. Pour protéger une donnée, il faut surtout distinguer disponibilité, réplication, sauvegarde et archivage. Ces mécanismes répondent à des pannes différentes.

Une base répliquée écrit ses changements sur une seconde copie. Si le nœud principal tombe, le service peut basculer. Mais si une commande DELETE valide efface dix mille lignes, la réplication transmet fidèlement cette suppression. Deux copies identiques du même accident ne sont pas une sauvegarde.

RPO et RTO rendent la discussion mesurable

Prenons un catalogue de commandes. L’entreprise accepte de perdre au plus quinze minutes de transactions et veut reprendre en deux heures. Son RPO est donc quinze minutes; son RTO, deux heures. Une copie nocturne ne respecte pas le RPO, même si elle termine toujours avec succès.

Une protection cohérente pourrait combiner :

1. journal transactionnel expédié fréquemment vers un stockage séparé;
2. sauvegarde complète quotidienne et différentielle en journée;
3. réplication vers une autre instance pour les pannes courtes;
4. copie hors du compte d’exploitation pour résister à une erreur d’administration;
5. exercice de restauration chronométré chaque trimestre.

La restauration suit un ordre. On crée une instance propre, restaure la dernière sauvegarde complète, applique les différentiels puis les journaux jusqu’au point choisi, vérifie l’intégrité et bascule l’application. Les clés de chiffrement et les comptes de service font partie du scénario; sans la clé, la copie chiffrée est inutilisable.

Le fournisseur et le client protègent des couches différentes

Le fournisseur peut remplacer un disque et alimenter plusieurs centres. Le client choisit la rétention, les droits, les exports et le comportement de son application. Dans un SaaS, il faut demander si une suppression utilisateur est récupérable, pendant combien de temps et à quel niveau de granularité. « Les données sont redondantes » ne répond pas à ces questions.

La reprise peut échouer de façons plates : sauvegarde tronquée, version incompatible, dépendance DNS oubliée, volume trop grand pour tenir dans le RTO ou script jamais mis à jour. Vérifier seulement le statut vert du job valide l’écriture d’un fichier, pas la capacité de remettre le service.

Une panne de région demande aussi de choisir la cohérence. Si les écritures répliquent de façon asynchrone, quelques transactions récentes peuvent manquer au site secondaire. Si elles attendent une confirmation lointaine, chaque opération devient plus lente. Le RPO indique quel compromis est acceptable.

Je conserverais enfin un export dans un format qu’on peut relire sans le fournisseur. Il faut tester le temps nécessaire, la complétude des relations et la capacité de reconstruire les pièces jointes. Un export de tables sans schéma ni identifiants est une fausse porte de sortie.

Dans un vrai projet cloud, je demanderais une démonstration de restauration avant une démonstration d’élasticité. On choisit une commande supprimée, on fixe un point dans le temps et on mesure jusqu’au retour fonctionnel. La plomberie devient rassurante quand elle a déjà ramené l’eau.