Une sauvegarde protège une copie. Un plan de reprise protège la capacité de travailler à nouveau. Entre les deux, il faut retrouver les clés, reconstruire les accès, rétablir les dépendances et vérifier les données. L’immutabilité réduit certains risques de suppression, mais elle ne garantit ni la qualité de la copie ni la réussite de la reprise.
En résumé
- Le PCA organise la continuité ; le PRA organise la reprise après une interruption.
- Le RPO exprime la perte de données admissible et le RTO le délai de reprise visé.
- L’immutabilité doit être décrite par son périmètre, sa durée et les privilèges capables de la contourner.
- S3 Object Lock protège des versions d’objets ; ses modes Governance et Compliance ont des effets différents.
- La preuve finale est une restauration suivie d’un test du service métier, avec les dépendances et les accès.
1. Définir ce que le métier doit retrouver
Le plan de continuité d’activité, ou PCA, décrit comment poursuivre les activités prioritaires pendant une perturbation. Le plan de reprise d’activité, ou PRA, prépare leur rétablissement. Le RPO représente la perte de données maximale acceptable dans le scénario étudié ; le RTO est l’objectif de temps pour reprendre. Ces valeurs se décident avec le métier, puis se confrontent aux possibilités techniques.
Exemple fictif : une équipe accepte de ressaisir une heure de commandes et veut reprendre en quatre heures. Une copie toutes les heures ne suffit pas à démontrer le RPO : la dernière sauvegarde peut avoir échoué ou contenir des données incohérentes. Le chronomètre de reprise doit inclure l’identification de la bonne copie, la restauration, les dépendances et la recette métier.
- ProductionDonnées et applications
- SauvegardeComptes et administration séparés
- Copie protégéeVersions, rétention et clés maîtrisées
- Zone de repriseEnvironnement isolé pour restaurer
- Validation métierAccès, cohérence et opérations prioritaires
2. Décrire précisément l’immutabilité
Une copie immuable ne peut pas être modifiée ou supprimée pendant une période donnée, dans les limites du mécanisme choisi. Il faut préciser quels administrateurs sont concernés, ce qui se passe si le compte est compromis et comment les clés de chiffrement sont protégées. Une simple séparation réseau n’est pas un stockage hors ligne ; les deux peuvent contribuer à une stratégie sans être équivalents.
Sur Linux, un attribut de fichier comme chattr +i ne constitue pas à lui seul une protection contre un administrateur capable de retirer cet attribut. Un dépôt renforcé fourni par un produit doit être évalué selon son architecture complète, ses privilèges et ses procédures de maintenance. Ne déduisez pas sa résistance du seul système de fichiers XFS.
La règle 3-2-1 et ses extensions donnent des repères pour diversifier les copies. Le « 0 erreur » parfois ajouté doit renvoyer à des vérifications réalisées, pas à une promesse d’absence d’erreur future. Conservez le résultat daté des restaurations et leurs limites.
3. Comprendre S3 Object Lock
La documentation AWS distingue Governance, qui peut être contourné avec des permissions spécifiques et la demande correspondante, et Compliance, qui interdit la suppression d’une version protégée pendant sa rétention, y compris au compte root dans le cadre décrit. Le verrouillage porte sur des versions d’objets. Ajouter une version ou un marqueur de suppression n’est pas supprimer la version protégée.
Ne commencez pas un essai avec une longue rétention Compliance : cette durée ne se raccourcit pas librement. Object Lock ne remplace pas la protection du compte et des clés de chiffrement. Vérifiez aussi les coûts, les règles de cycle de vie et l’accès aux versions à restaurer. Les considérations de gestion AWS détaillent les permissions et contraintes.
| Contrôle | Question à résoudre |
|---|---|
| Version | Quelle version exacte est protégée et jusqu’à quand ? |
| Privilèges | Qui possède un droit de contournement Governance ? |
| Chiffrement | Qui peut désactiver ou supprimer la clé ? |
| Restauration | Peut-on relire cette version depuis la zone de reprise ? |
4. Préparer l’essai avant toute configuration
Utilisez des données fictives, un compte ou projet dédié et un budget maîtrisé. Consignez le produit de sauvegarde, sa version, le stockage, la région, le mode de rétention et les rôles. Préparez une copie témoin, une version récente volontairement erronée et une liste de résultats attendus. Les commandes de création de stockage ne sont pas proposées comme une recette universelle : les paramètres et les effets durables doivent être validés pour votre fournisseur.
Séparez les essais de suppression selon les rôles. Un refus pour un utilisateur ordinaire ne prouve pas le refus pour l’administrateur de sauvegarde. Inversement, un succès avec le rôle de contournement Governance peut correspondre au fonctionnement prévu. Notez l’identité, l’objet, sa version et la réponse exacte.
5. Rejouer une vraie reprise
- Choisir un point de restauration et expliquer pourquoi il précède l’incident simulé.
- Restaurer dans une zone isolée, avec les clés et comptes prévus par le PRA.
- Vérifier les dépendances : annuaire, DNS, certificats, licences, réseau et secrets applicatifs.
- Faire exécuter au métier une opération complète, par exemple retrouver une commande et produire un document.
- Mesurer la perte de données constatée et la durée réelle, puis comparer avec les objectifs.
- Consigner les erreurs, les interventions manuelles et les informations manquantes.
Un démarrage de machine virtuelle ne suffit pas. Une base peut être accessible alors que ses données sont incohérentes avec un autre service. Le contrôle métier doit donc porter sur une transaction représentative et sur les échanges essentiels.
6. Limites, retour arrière et validation
La recette attendue couvre une restauration réussie, une suppression refusée selon le mode choisi, une tentative avec un rôle trop privilégié et une indisponibilité simulée du compte d’administration habituel. La compatibilité doit être vérifiée pour les versions de produits utilisées dans votre environnement.
Pour revenir à l’état initial, retirez les accès de test et arrêtez les ressources de reprise selon la procédure prévue. Une rétention Compliance déjà engagée peut imposer de conserver les objets et leurs coûts jusqu’à expiration. Le nettoyage doit respecter cette contrainte. Ne supprimez pas une clé pour « nettoyer » une sauvegarde verrouillée : vous pourriez la rendre illisible sans résoudre la rétention.
Sources et références
Références consultées le 10 octobre 2026. Les schémas sont des représentations pédagogiques ; les exemples et recettes proposés doivent être adaptés au périmètre réel.
Besoin de relier ces contrôles à votre environnement ? Parler de votre projet avec Kenawek.