[Accueil](https://hmbastion.com/fr/) [Blog](https://hmbastion.com/fr/blog/) Sécurité Sécurité 5 min de lecture # Réalisez un exercice de restauration : transformez RPO et RTO en procédure de récupération Une tâche de sauvegarde réussie indique qu'une copie a été créée. Un exercice de restauration répond à une question plus utile : l'équipe peut-elle rétablir un service fonctionnel, avec une perte de données acceptable, dans le délai que le projet peut tolérer ? HM Bastion Éditorial Publié 2026-10-26 ## Dans ce guide - [Distinguez l'objectif de perte de données de l'objectif de délai de récupération](https://hmbastion.com/fr/blog/backup-restore-drill-rpo-rto/#define-two-targets) - [Sauvegardez tout ce qui est nécessaire pour recréer un service cohérent](https://hmbastion.com/fr/blog/backup-restore-drill-rpo-rto/#build-coherent-copy) - [Rendez la copie de récupération indépendante et accessible](https://hmbastion.com/fr/blog/backup-restore-drill-rpo-rto/#separate-copy-access) - [Restaurez dans un environnement sûr et exécutez un test concret](https://hmbastion.com/fr/blog/backup-restore-drill-rpo-rto/#perform-safe-drill) - [Transformez le résultat de l'exercice en un dossier de récupération maintenu](https://hmbastion.com/fr/blog/backup-restore-drill-rpo-rto/#close-recovery-loop) [Tous les guides d'hébergement](https://hmbastion.com/fr/blog/) ## L'essentiel à retenir Fixez des objectifs de récupération explicites, restaurez une copie cohérente dans un environnement isolé, testez le comportement des applications importantes et consignez les résultats mesurés au lieu de supposer que la planification suffit. ## Distinguez l'objectif de perte de données de l'objectif de délai de récupération L'objectif de point de reprise, ou RPO, décrit le moment jusqu'auquel les données doivent pouvoir être récupérées. L'objectif de délai de reprise, ou RTO, concerne la durée de récupération avant que l'interruption n'ait un effet inacceptable. Traduisez les deux en termes métier avant de choisir un logiciel. Un site vitrine peut tolérer une interruption différente d'un service qui accepte de nouvelles commandes chaque minute. Prenons l'exemple illustratif d'une application de réservation dont le propriétaire accepte au plus une heure de mises à jour perdues et vise un rétablissement du service sous deux heures. Une copie nocturne seule ne peut pas démontrer l'objectif d'une heure de données : un incident survenu vers la fin de l'intervalle quotidien pourrait entraîner la perte de travaux bien plus récents. Les objectifs de cet exemple appartiennent à ce projet ; ils ne constituent pas un engagement de récupération de HM Bastion. Choisissez une limite de mesure précise. Notez quand le service est devenu indisponible, quand l'incident a été identifié et quand le service testé est revenu. Lors d'un exercice planifié, distinguez le temps passé à reconstruire du temps également nécessaire pour remarquer un incident, obtenir une autorisation et récupérer des identifiants. Ne rapporter que l'étape d'importation la plus rapide masque le travail qui retarde une récupération réelle. ## Sauvegardez tout ce qui est nécessaire pour recréer un service cohérent | Composant de récupération | À conserver | Omission courante | | --- | --- | --- | | Application | Identifiant de version, dépendances et instructions de déploiement | Le code source existe mais la version requise ne peut pas être reconstruite | | Base de données | Une sauvegarde cohérente prise en charge, ainsi que les rôles ou la configuration requis | On suppose qu'une copie des fichiers de base de données en production est restaurable | | Contenu utilisateur | Téléversements, documents et permissions de stockage | Les lignes de la base de données pointent vers des fichiers manquants | | Configuration privée | Secrets récupérables et accès à leurs clés de chiffrement | La clé n'est disponible que sur le serveur défaillant | | Opérations | Détails DNS, tâches planifiées et exigences envers des services externes | Le site restauré envoie inopinément des messages réels | Utilisez une méthode de sauvegarde prise en charge par le moteur de base de données. Les dumps logiques PostgreSQL offrent une vue cohérente de la base de données, tandis que les rôles à l'échelle du cluster nécessitent un traitement distinct. La sauvegarde au niveau fichier et l'archivage continu répondent à des exigences différentes. Un dump logique n'est pas interchangeable avec la sauvegarde de base et les WAL archivés nécessaires à la récupération à un instant précis. Choisissez et testez une méthode documentée plutôt que de combiner des éléments incompatibles. Coordonnez la capture de la base de données et des fichiers téléversés. Si un client téléverse un document pendant la copie, une sauvegarde de la base de données et une archive de fichiers bien plus ancienne peuvent décrire des états applicatifs différents. Définissez une stratégie de maintenance ou de cohérence adaptée à l'application, et incluez une pièce jointe récente dans les vérifications de restauration. Le simple nombre de fichiers ne permet pas d'établir que les bons fichiers correspondent aux enregistrements restaurés. ## Rendez la copie de récupération indépendante et accessible Conservez une copie de récupération en dehors du chemin de défaillance que vous anticipez. Un autre répertoire sur le même disque ne sert à rien si ce disque est perdu. Une copie contrôlée par les mêmes identifiants applicatifs compromis peut aussi être supprimée par un attaquant. Choisissez délibérément l'accès au stockage, la rétention et les éventuels contrôles d'immuabilité, puis confirmez leur comportement réel plutôt que de vous fier à l'appellation d'un produit. Chiffrez les copies contenant des informations sensibles et gardez la clé de récupération disponible via une procédure contrôlée séparément. Autorisez les personnes qui doivent les restaurer et testez la récupération avec les permissions dont elles disposeront lors d'un incident. Intégrez la croissance du stockage de sauvegarde et le temps de transfert au plan. Une copie qui existe techniquement mais que l'opérateur de récupération ne peut pas télécharger n'est pas prête à l'emploi. ## Restaurez dans un environnement sûr et exécutez un test concret - Sélectionnez une sauvegarde terminée et consignez son horodatage de récupération, sa taille et les preuves de son intégrité. - Préparez une destination isolée avec les versions logicielles requises et suffisamment d'espace de stockage temporaire. - Bloquez les e-mails réels, les appels de paiement, les tâches planifiées et les webhooks avant de démarrer l'application restaurée. - Restaurez la base de données, les fichiers et la configuration privée selon la procédure documentée. - Vérifiez la connexion, des enregistrements représentatifs, un fichier téléversé et une écriture synthétique dans la copie isolée. - Consignez le dernier point de données récupéré, la durée des étapes, les échecs et les décisions de l'opérateur. Pour l'exemple de réservation, trouvez une réservation connue juste avant la limite de la sauvegarde et vérifiez le client et la pièce jointe associés. Confirmez que la réservation récente attendue apparaît et qu'un enregistrement de test volontairement plus tardif n'apparaît pas. Créez ensuite une réservation synthétique dans la copie isolée. Cela teste les relations et la capacité d'écriture sans contacter un vrai client ni modifier la production. Utilisez un journal d'étapes : récupération des identifiants, préparation de la destination, téléchargement, vérification, import, démarrage de l'application et contrôles d'acceptation. Supposez que l'import prenne vingt minutes mais que l'approbation d'accès en prenne cinquante. La prochaine amélioration concerne la procédure d'accès, pas nécessairement un plan de base de données plus rapide. Conservez le résultat mesuré même s'il manque l'objectif ; une répétition échouée a identifié du travail à faire pendant que le service est encore sain. ## Transformez le résultat de l'exercice en un dossier de récupération maintenu Attribuez un responsable à chaque contrôle échoué et répétez la partie concernée après correction. Des téléversements manquants exigent un meilleur jeu de sauvegardes ; des extensions non prises en charge exigent un inventaire logiciel reproductible. Répétez un exercice complet après des changements importants d'application ou de stockage et à une fréquence justifiée par le projet. Indiquez la date de la dernière récupération réussie dans les notes d'exploitation. Lisez les fonctionnalités de sauvegarde de l'hébergeur séparément de votre propre procédure de récupération. La réplication, les instantanés et les sauvegardes conservées ont des rôles et des limites de défaillance différents. Confirmez avec l'équipe les fonctionnalités et la portée de restauration associées à votre service souscrit. Une procédure de récupération applicative testée reste précieuse même lorsque l'infrastructure offre des outils de récupération supplémentaires. Les exemples de produits s'appuient sur le catalogue HM Bastion publié. La disponibilité, les prix et les options sélectionnables s'affichent lorsque vous configurez une commande. ## Choisissez votre prochaine fondation. [Comprendre les couches de récupération et de protection](https://hmbastion.com/fr/blog/ddos-protection-and-backups/) [Planifier une migration d'hébergement maîtrisée](https://hmbastion.com/fr/blog/hosting-migration-cutover-rollback/) [Confirmer une exigence de récupération de service](https://hmbastion.com/fr/support/) ## Sources et compléments de lecture - [Glossaire NIST : objectif de point de reprise](https://csrc.nist.gov/glossary/term/recovery_point_objective) - [Glossaire NIST : objectif de temps de reprise](https://csrc.nist.gov/glossary/term/recovery_time_objective) - [PostgreSQL : sauvegarde et restauration logiques](https://www.postgresql.org/docs/current/backup-dump.html) - [PostgreSQL : archivage continu et récupération à un instant précis](https://www.postgresql.org/docs/current/continuous-archiving.html) ## Continuez l'exploration [ Planification 5 min de lecture ## Migrez votre hébergement avec une bascule testée et un plan de retour arrière réaliste Planifiez les données applicatives, les vérifications sur la destination, les changements de DNS et le point au-delà duquel un retour arrière exige une réconciliation des données. ](https://hmbastion.com/fr/blog/hosting-migration-cutover-rollback/) [ Planification 5 min de lecture ## Exécutez Docker sur un VPS avec un plan d'exploitation de production Planifiez les ressources des conteneurs, les données persistantes, les ports publiés, les versions et les journaux bornés avant de déployer une application Compose. ](https://hmbastion.com/fr/blog/docker-vps-production-checklist/)