STATUS IS UPWIKI D'OPTIMISATION DE SITE
49Récupérer
Sécurité et reprise / Récupérer

Sauvegarde et restauration de site Web : créez un chemin de reprise testable

Construisez un processus testé pour récupérer les données, fichiers, configurations et décisions nécessaires après une mauvaise modification, une suppression ou un incident de sécurité.

Sauvegarde et restauration de site Web : créez un chemin de reprise testable — GUIDE VISUEL
LIRE
8 minutes
SOURCES
7
RÉVALIDER
2027-03-27
examiné
Relecteur résilience et sécurité des sites Web
LA RÉPONSE COURTE

Commencez par la décision.

Considérez la sauvegarde et la restauration comme une seule capacité de reprise, pas comme un achat de stockage. Identifiez les services dont les visiteurs et le personnel ont besoin, puis créez une copie temporellement cohérente du contenu, de la base de données, des médias, du code, de la configuration et des informations de build nécessaires pour les reconstruire. Conservez des copies protégées hors de l’environnement de production, limitez qui peut les supprimer et rendez les instructions accessibles quand les outils normaux sont indisponibles.

Fixez la fréquence de sauvegarde à partir de deux choix : l’objectif de point de récupération, ou RPO, est la dernière modification que vous pouvez accepter de perdre ; l’objectif de temps de reprise, ou RTO, est la durée maximale d’interruption de service acceptable. Restaurez dans un environnement séparé, mesurez le résultat par rapport aux deux objectifs et conservez des preuves. Un travail de sauvegarde marqué « réussi » n’est pas une preuve que la reprise fonctionnera.

GUIDE VISUEL

Voyez le travail comme un système.

Utilisez cette carte pour relier les décisions de l'article avant d'agir sur des tactiques isolées.

SIURécupérer
01Définir ce que « le site » inclut
02Fixer la fréquence et la rétention selon la tolérance métier
03Séparer et protéger les copies de reprise
04Rédiger un runbook de reprise et attribuer l’autorité
01

Définir ce que « le site » inclut

Commencez par un inventaire des services. Pour chaque site, portail, boutique ou campagne, enregistrez le propriétaire métier, le propriétaire technique, le compte d’hébergement, le contrôle du domaine et du DNS, le dépôt, les magasins de contenu et de médias, les intégrations et les identifiants essentiels. Indiquez ce qui peut être reconstruit depuis le contrôle de version et ce qui contient des enregistrements uniques.

Incluez la configuration intentionnellement : redirections, paramètres CDN ou pare-feu, tâches planifiées, modèles et fichiers d’infrastructure-as-code. Ne copiez pas les secrets en direct dans un manifeste général ; pointez plutôt vers le système de secrets approuvé et le processus d’accès d’urgence. La documentation WordPress montre l’écart courant : un site typique a besoin à la fois de ses fichiers et d’une base de données séparée.

Service viable minimum

Définissez la plus petite version sûre qui puisse fournir les informations ou transactions essentielles.

Jeu de sauvegarde

Donnez aux exports compatibles de base de données, fichiers, médias et configuration une étiquette de timestamp ou de version unique.

02

Fixer la fréquence et la rétention selon la tolérance métier

Choisissez la fréquence en fonction du rythme et de la valeur des changements. Rédigez le RPO en langage clair, puis vérifiez que chaque magasin unique est capturé assez souvent. Une copie de fichiers nocturne ne satisfera pas un RPO de quatre heures pour une base de données à forte cadence de changement.

Définissez l’RTO séparément. Incluez l’approbation, l’infrastructure propre, la restauration, la validation, les modifications de trafic et la communication interne. Mesurez-le lors d’un exercice plutôt qu’en vous fiant à une affirmation du fournisseur. Conservez des points plus anciens suffisamment longtemps pour revenir en arrière avant une erreur ou une découverte tardive, puis revoyez la rétention avec les spécialistes de la confidentialité, des archives ou du juridique lorsque des données l’exigent.

Vérification de la fréquence

Comparez l’intervalle entre les points de reprise complets avec le RPO de chaque service.

Vérification de la rétention

Vérifiez qu’une personne autorisée peut retrouver un point de restauration approuvé ancien.

03

Séparer et protéger les copies de reprise

Utilisez plusieurs copies dans des emplacements ou services différents afin qu’un seul compte, événement local ou erreur humaine n’élimine toutes les options. La CISA recommande des sauvegardes automatisées régulières, une copie hors site, le chiffrement et des copies hors ligne. Le NCSC déconseille les dispositifs de sauvegarde en connexion permanente et recommande plus d’une solution ou d’un emplacement de sauvegarde.

Protégez l’administration des sauvegardes avec le principe du moindre privilège, l’authentification multi‑facteur quand elle est disponible, des comptes d’administration distincts et des revues d’accès. Utilisez la protection contre la suppression, l’historique de versions ou le stockage immuable uniquement après avoir compris leur coût et leur comportement de récupération. Chiffrez les données stockées et testez la garde des clés. Un chiffrement sans clés accessibles est inutilisable ; un accès trop largement partagé affaiblit chaque copie.

Hors site signifie distinct

La copie doit avoir un mode de défaillance significativement différent de la production.

Revue des accès

Listez qui peut lire, modifier, supprimer et restaurer les sauvegardes ; retirez les accès obsolètes.

04

Rédiger un runbook de reprise et attribuer l’autorité

Un runbook est la procédure de reprise testée. Conservez-en une copie accessible sans le site affecté, le fournisseur d’identité de production ou le système de chat habituel. Incluez les contacts et leurs remplaçants, l’autorité, la priorité des systèmes, les emplacements de sauvegarde, les prérequis, l’ordre de restauration, les contrôles de validation et les conditions d’arrêt.

Nommez un propriétaire de reprise responsable et un suppléant pour chaque service critique. Définissez qui autorise la restauration en production, les changements DNS et la validation des données métiers. Si des données de carte de paiement, des données personnelles sensibles ou des enregistrements réglementés sont concernés, obtenez l’avis qualifié de la sécurité, de la confidentialité, du juridique et, le cas échéant, de PCI avant de décider quoi préserver, notifier ou restaurer.

Journal de décision

Enregistrez le point de restauration choisi, la personne ayant approuvé, les systèmes touchés, le résultat de la validation et les exceptions.

Accès d’urgence (break‑glass)

Documentez l’accès d’urgence contrôlé ; ne dépendez jamais de l’appareil ou de la mémoire d’un seul employé.

05

Restaurer en sécurité après une compromission suspectée

N’écrasez pas automatiquement la production avec la copie la plus récente lorsqu’un accès non autorisé, un logiciel malveillant ou une suppression suspecte est possible. Suivez le processus d’incident, évaluez quels comptes et sauvegardes peuvent être affectés, sélectionnez un point à partir des éléments de preuve et reconstruisez ou isolez l’environnement de reprise avant de le reconnecter.

La CISA oriente la reprise selon l’ordre de priorité des services critiques et met en garde contre la réinfection de systèmes propres. Le NCSC recommande de ne connecter les sauvegardes qu’à des appareils connus propres et de les scanner avant restauration. Ces étapes réduisent le risque, elles ne garantissent pas la propreté. Montez en charge vers une aide qualifiée en réponse aux incidents quand l’investigation, la conservation de preuves ou les obligations de notification peuvent s’appliquer.

Ordre sûr

Restaurez le service de plus haute priorité sur une infrastructure propre, validez-le, puis continuez selon l’ordre des dépendances.

Valider complètement

Vérifiez les parcours utilisateurs, les données, les tâches, les intégrations, l’administration, la journalisation et la nouvelle couverture de sauvegarde.

06

Utiliser des exercices comme preuve et source d’amélioration

Exécutez des restaurations partielles, des reconstructions complètes isolées, des exercices de perte de dépendance ou des table‑tops selon le niveau de risque. Commencez par un test sûr et signifiant et augmentez le réalisme au fil du temps. La CISA recommande des tests de restauration complets et partiels ; le NCSC recommande des exercices pour clarifier les rôles, les responsabilités des tiers et les priorités.

Mesurez l’âge du point de restauration par rapport au RPO et le temps de reprise écoulé par rapport à l’RTO. Enregistrez l’identifiant du set, les participants, le résultat de validation, les étapes échouées et un propriétaire pour chaque correction. Retestez après la fermeture des lacunes et après tout changement matériel de plateforme, d’identité, de base de données ou de fournisseur. SIU peut organiser ce travail préventif de remédiation ; ce n’est pas un système de sauvegarde ni un service de surveillance en direct.

Preuve

Conservez un compte rendu concis de ce qui a été restauré, où, ce qui a réussi, ce qui a échoué et qui l’a accepté.

Déclencheur de retest

Répétez les tests ciblés après un changement matériel de l’architecture ou des fournisseurs.

ACTION / VÉRIFIER

Votre guide pratique des actions à mener.

ACTION / VÉRIFIERVÉRIFIER
Cartographier services et donnéesListez chaque service critique, ses magasins uniques, sa configuration, ses intégrations et ses propriétaires.L’inventaire nomme une source et un propriétaire pour chaque élément récupérable.
Fixer RPO et RTORédigez des objectifs de point de récupération et de temps de reprise approuvés par l’entreprise pour chaque service critique.Les plannings et l’ordre de reprise peuvent satisfaire les objectifs documentés.
Créer des ensembles cohérentsCapturez ensemble fichiers compatibles, données, médias, configuration et définitions de build.Un ensemble d’exemple contient les éléments, timestamps et ordre de restauration.
Sécuriser des copies séparéesUtilisez des copies protégées hors de l’environnement principal avec accès contrôlé et chiffrement.Une revue d’accès identifie une option de reprise avec un mode de défaillance différent.
Préparer le runbookDocumentez l’autorité, les contacts, les besoins d’environnement propre, les étapes de restauration et l’escalade.Un remplaçant peut trouver le runbook et l’accès de reprise sans le service affecté.
Exécuter une restauration isoléeRestaurez un point sélectionné hors production ou exercez une étape de reprise réelle en sécurité.L’équipe enregistre l’âge réel du point, le temps écoulé et les résultats de validation.
Valider les comportements critiquesVérifiez parcours core, données pertinentes, tâches, intégrations, administration, logs et nouvelle couverture de sauvegarde.Les propriétaires métier et techniques acceptent les vérifications ou consignent les exceptions.
Corriger et retester les lacunesAttribuez les échecs d’exercice, mettez à jour le runbook et répétez le test affecté.Chaque lacune a un propriétaire, une date d’échéance, une preuve d’achèvement et un résultat de retest.
Revoir après changementRevenez sur la portée, les accès, la rétention et les objectifs après un changement matériel.Le plan indique une date de revue actuelle et un historique des changements.
ACTION / VÉRIFIER

Votre guide pratique des actions à mener.

  1. 01

    Cartographier services et données

    Listez chaque service critique, ses magasins uniques, sa configuration, ses intégrations et ses propriétaires.

    VÉRIFIER: L’inventaire nomme une source et un propriétaire pour chaque élément récupérable.
  2. 02

    Fixer RPO et RTO

    Rédigez des objectifs de point de récupération et de temps de reprise approuvés par l’entreprise pour chaque service critique.

    VÉRIFIER: Les plannings et l’ordre de reprise peuvent satisfaire les objectifs documentés.
  3. 03

    Créer des ensembles cohérents

    Capturez ensemble fichiers compatibles, données, médias, configuration et définitions de build.

    VÉRIFIER: Un ensemble d’exemple contient les éléments, timestamps et ordre de restauration.
  4. 04

    Sécuriser des copies séparées

    Utilisez des copies protégées hors de l’environnement principal avec accès contrôlé et chiffrement.

    VÉRIFIER: Une revue d’accès identifie une option de reprise avec un mode de défaillance différent.
  5. 05

    Préparer le runbook

    Documentez l’autorité, les contacts, les besoins d’environnement propre, les étapes de restauration et l’escalade.

    VÉRIFIER: Un remplaçant peut trouver le runbook et l’accès de reprise sans le service affecté.
  6. 06

    Exécuter une restauration isolée

    Restaurez un point sélectionné hors production ou exercez une étape de reprise réelle en sécurité.

    VÉRIFIER: L’équipe enregistre l’âge réel du point, le temps écoulé et les résultats de validation.
  7. 07

    Valider les comportements critiques

    Vérifiez parcours core, données pertinentes, tâches, intégrations, administration, logs et nouvelle couverture de sauvegarde.

    VÉRIFIER: Les propriétaires métier et techniques acceptent les vérifications ou consignent les exceptions.
  8. 08

    Corriger et retester les lacunes

    Attribuez les échecs d’exercice, mettez à jour le runbook et répétez le test affecté.

    VÉRIFIER: Chaque lacune a un propriétaire, une date d’échéance, une preuve d’achèvement et un résultat de retest.
  9. 09

    Revoir après changement

    Revenez sur la portée, les accès, la rétention et les objectifs après un changement matériel.

    VÉRIFIER: Le plan indique une date de revue actuelle et un historique des changements.
SUJETS DE DISCUSSION

Comparez les compromis, pas les données privées.

Utilisez ces propositions avec votre équipe ou la communauté de propriétaires de sites. Partagez des méthodes et des enseignements, mais ne collez jamais d'identifiants, d'enregistrements clients ou de détails d'infrastructure non publics.

  1. 01

    Quelle dépendance du site rendrait votre sauvegarde actuelle inutilisable si elle disparaissait, et comment pourriez‑vous tester cette hypothèse sans exposer de données clients ?

  2. 02

    Qu’a révélé un exercice de restauration ou de rollback récent sur la différence entre une inversion rapide de code et une reprise complète du service ?

  3. 03

    Comment avez‑vous rendu l’autorité de reprise et l’accès d’urgence opérationnels lorsque le propriétaire clé est indisponible ?

RESSOURCES POPULAIRES / DE RÉFÉRENCE

Consultez le matériel source.

Cybersecurity and Infrastructure Security AgencyBack Up Business Data ↗

Un guide gouvernemental concis pour inventorier les données critiques, utiliser des copies protégées et tester la restauration complète et partielle.

Examiné le 2026-09-27
Cybersecurity and Infrastructure Security AgencyStopRansomware Guide ↗

Explique le concept de sauvegardes chiffrées hors ligne, des restaurations propres, des images dorées et des priorités de restauration en cas de ransomware.

Examiné le 2026-09-27
UK National Cyber Security CentreMitigating malware and ransomware attacks ↗

Conseils pratiques sur la séparation des copies de sauvegarde, le scan avant restauration, la MFA pour l’administration des sauvegardes et les exercices.

Examiné le 2026-09-27
National Institute of Standards and TechnologyContingency Planning Guide for Federal Information Systems, SP 800-34 Rev. 1 ↗

Référence de planification pour évaluer les besoins, priorités et processus de contingence pour la reprise.

Examiné le 2026-09-27
WordPress DocumentationBackups ↗

Montre pourquoi une récupération WordPress typique nécessite à la fois la base de données et les fichiers du site, avec des exemples de périmètre pratiques.

Examiné le 2026-09-27
OWASP Cheat Sheet SeriesLogging Cheat Sheet ↗

Utile pour concevoir les preuves de restauration et d’exercices tout en considérant les contrôles d’accès et l’exposition des données sensibles dans les logs.

Examiné le 2026-09-27
Cloudflare DevelopersRollbacks ↗

Exemple de documentation de rollback de déploiement qui aide à distinguer l’inversion de code de la reprise des données et services.

Examiné le 2026-09-27

Politique des sources. Cet article utilise des guides gouvernementaux officiels, des normes, des documentations de plateformes et des recommandations de sécurité consultés le 2026-09-27. Les ressources aident les lecteurs à agir et ne constituent pas des endorsements. Les affirmations des plateformes se limitent à la documentation publiée ; les choix juridiques, de confidentialité, de paiement et de réponse aux incidents nécessitent un examen qualifié.

CLARIFICATIONS RAPIDES

Questions fréquentes.

À quelle fréquence dois‑je sauvegarder mon site Web ?

Sauvegardez chaque source de données unique assez souvent pour satisfaire son RPO écrit. Un site à faible changement peut tolérer un intervalle plus long qu’une boutique, un portail membre ou un système de publication. Le planning doit couvrir les bases de données et les médias ainsi que les fichiers de déploiement, et il doit être prouvé par un exercice de restauration.

La sauvegarde du fournisseur d’hébergement suffit‑elle ?

Elle peut être une option de reprise, mais ne supposez pas qu’elle couvre chaque composant du site, qu’elle soit accessible dans votre RTO ou qu’elle soit protégée contre la même défaillance de compte ou de plateforme. Vérifiez la portée, la rétention, l’accès, les protections contre la suppression et les étapes réelles de restauration. Maintenez une option récupérable indépendamment quand le risque du service le justifie.

Puis‑je utiliser un rollback de déploiement à la place d’une sauvegarde ?

Un rollback peut être utile pour annuler un mauvais déploiement en production. Ce n’est pas automatiquement une sauvegarde des bases de données, des médias uploadés, des paramètres tiers ou des enregistrements supprimés. Intégrez l’inversion de déploiement au runbook, mais testez un chemin de restauration de bout en bout séparé pour le service complet.

Status Is UP Editorial Team · Rédacteurs Uptime Enablement

Examiné par Relecteur résilience et sécurité des sites Web. Publié 2026-09-27; mis à jour 2026-09-30.