Tester une sauvegarde WordPress : comment vérifier qu’elle est réellement restaurable ?

Une sauvegarde WordPress peut être créée chaque nuit, apparaître comme « réussie » dans un tableau de bord et rester pourtant inutilisable le jour où le site tombe en panne. Une archive incomplète, une base de données impossible à importer, un mot de passe de chiffrement introuvable ou des fichiers qui ne correspondent pas à la même date peuvent bloquer toute reprise.

Le seul moyen de vérifier qu’une sauvegarde est réellement exploitable consiste à effectuer un test de restauration WordPress dans un environnement isolé, puis à contrôler non seulement l’affichage du site, mais aussi ses accès, ses médias, ses formulaires, ses tâches planifiées et ses fonctions métier.

Ce test ne doit pas remplacer ni modifier le site en production. Il doit reproduire une reprise réelle, avec un jeu cohérent de fichiers et de base de données, tout en empêchant les e-mails, paiements, webhooks ou indexations accidentels.

Ce guide complète la ressource consacrée à la fréquence et aux bonnes pratiques de sauvegarde WordPress. Ici, l’objectif est plus précis : démontrer, preuves à l’appui, que le site peut être remis en service dans un délai compatible avec votre activité.

Pourquoi une sauvegarde « réussie » ne prouve-t-elle pas la restauration ?

La plupart des outils confirment surtout qu’une tâche s’est terminée sans erreur bloquante. Cette confirmation ne démontre pas nécessairement que tous les fichiers ont été copiés, que l’export SQL est importable, que les archives correspondent entre elles ou que les secrets nécessaires à la reprise sont disponibles.

Plusieurs problèmes peuvent rester invisibles jusqu’au test :

• archive tronquée ou corrompue ;
• base de données absente, vide ou partielle ;
• répertoire uploads incomplet ;
• fichiers et base de données issus de moments différents ;
• extension premium, thème enfant ou code spécifique manquant ;
• clé de chiffrement ou mot de passe de l’archive introuvable ;
• version de PHP, de MySQL/MariaDB ou de serveur incompatible ;
• URL et chemins absolus qui empêchent le fonctionnement sur l’environnement restauré ;
• intégrations externes, licences ou secrets non documentés ;
• sauvegarde contenant déjà une erreur ou une compromission.

Qu’est-ce qu’une sauvegarde WordPress réellement restaurable ?

Une sauvegarde restaurable ne se limite pas à un fichier ZIP téléchargeable. Elle doit franchir plusieurs niveaux de validation.

Niveau	Question à résoudre	Preuve attendue
Accessible	Peut-on récupérer la sauvegarde sans dépendre d’un compte perdu ou d’un serveur indisponible ?	Archive téléchargée et accès documentés
Intègre	Les fichiers sont-ils lisibles, extractibles et non tronqués ?	Extraction complète, contrôle de taille et absence d’erreur
Complète	La sauvegarde contient-elle les fichiers, la base et les éléments spécifiques nécessaires ?	Inventaire validé du jeu de sauvegarde
Déployable	Peut-on restaurer l’ensemble sur une infrastructure propre ?	WordPress démarre, la base est importée et la configuration fonctionne
Fonctionnelle	Le site remplit-il réellement son rôle après restauration ?	Tests front-office, back-office et métier réussis
Opérationnelle	La reprise respecte-t-elle le délai et la perte de données acceptables ?	RTO et RPO mesurés et acceptés

Un test peut donc être techniquement réussi tout en étant opérationnellement insuffisant. Restaurer un site en douze heures peut être acceptable pour une vitrine peu critique et beaucoup trop long pour une boutique qui réalise l’essentiel de son chiffre d’affaires en ligne.

Que doit contenir le jeu de sauvegarde testé ?

La documentation officielle WordPress distingue deux ensembles indispensables : les fichiers et la base de données. Les sauvegarder séparément est possible, mais ils doivent rester associés comme un même jeu de reprise. WordPress recommande généralement de restaurer d’abord les fichiers, puis d’importer la base de données.

Les fichiers WordPress

Le test doit disposer des fichiers réellement nécessaires au site :

• wp-content/uploads et les autres médias ou documents ;
• thème actif et thème enfant ;
• extensions, y compris les extensions premium ou installées manuellement ;
• mu-plugins, fichiers de cache ou chargeurs spécifiques lorsqu’ils sont indispensables ;
• wp-config.php, règles serveur et fichiers personnalisés utiles ;
• scripts, répertoires ou applications complémentaires liés au site.

La base de données

La base contient les contenus, réglages, utilisateurs, menus et nombreuses données créées par les extensions. Sur un WooCommerce, elle peut aussi contenir les commandes, comptes clients, stocks, coupons et informations opérationnelles. Une copie des fichiers ne sauvegarde généralement pas cette base, car MySQL ou MariaDB fonctionne séparément du répertoire WordPress.

Les secrets et dépendances externes

Une restauration peut également dépendre d’éléments qui ne sont pas toujours inclus dans le backup :

• mots de passe de chiffrement ;
• accès au stockage distant ;
• clés API, secrets de webhooks et certificats ;
• licences d’extensions ou de thèmes ;
• configuration DNS, CDN, pare-feu et messagerie ;
• paramètres de tâches cron serveur ;
• comptes de services externes comme le CRM, la réservation ou le paiement.

Le test doit distinguer ce qui est restauré automatiquement de ce qui doit être reconfiguré ou réactivé manuellement.

Composant	Ce qu’il faut vérifier	Risque en cas d’oubli
Base de données	Export complet, encodage, tables des extensions et import réel	Contenus, réglages ou commandes absents
Médias	Présence, taille, arborescence et affichage	Images, PDF et fichiers produits manquants
Thèmes et code spécifique	Thème enfant, fonctions personnalisées et dépendances	Mise en page cassée ou fonctions perdues
Extensions	Versions, extensions premium, mu-plugins et licences	Erreurs, fonctionnalités absentes ou incompatibilités
Configuration	wp-config, règles serveur, PHP, cache et permissions	Erreur de connexion, boucle ou écran blanc
Services externes	API, webhooks, SMTP, paiement, CRM et DNS	Site visible mais processus métier interrompus

Définir la perte de données et le temps d’arrêt acceptables

Le test doit être comparé à deux objectifs simples. Sans eux, il est impossible de savoir si le résultat est réellement satisfaisant.

Le RPO : combien de données peut-on perdre ?

Le Recovery Point Objective correspond au point de reprise acceptable. Si la dernière sauvegarde exploitable date de vingt-quatre heures, l’activité créée depuis cette date peut devoir être reconstituée manuellement ou être perdue.

Pour un site vitrine peu modifié, une journée de décalage peut être tolérable. Pour une boutique, un site de réservation ou un générateur de leads, quelques heures peuvent déjà représenter de nombreuses commandes ou demandes.

Le RTO : combien de temps peut durer la reprise ?

Le Recovery Time Objective correspond au délai maximal souhaité pour remettre le service en état. Le test doit chronométrer le téléchargement des archives, la préparation de l’environnement, la restauration, les corrections et les validations.

Un objectif théorique de deux heures n’a aucune valeur si la première restauration réelle en demande huit.

Type de site	Perte de données à évaluer	Objectif de test indicatif
Vitrine peu modifiée	Contenus, médias et réglages récents	Restauration complète annuelle et avant changement majeur
Site générateur de leads	Demandes de devis, inscriptions et formulaires stockés	Test semestriel et contrôle des intégrations
Réservation ou espace membres	Comptes, réservations, droits et notifications	Test trimestriel ou après évolution importante
WooCommerce actif	Commandes, paiements, stocks, remboursements et e-mails	Test trimestriel avec scénario métier contrôlé
Site critique ou parc d’agence	Données métier et capacité de reprise à grande échelle	Exercices planifiés et procédure industrialisée

Comment préparer un environnement de restauration isolé ?

L’environnement de test doit être suffisamment proche de la production pour révéler les incompatibilités, mais suffisamment isolé pour ne pas déclencher d’actions réelles.

• hébergement, machine virtuelle, conteneur ou staging dédié ;
• version de PHP et moteur de base compatibles avec la production ;
• base de données distincte et vide ;
• nom de domaine ou sous-domaine de test ;
• authentification HTTP ou restriction réseau ;
• directive empêchant l’indexation par les moteurs de recherche ;
• e-mails interceptés, désactivés ou redirigés vers une boîte de test ;
• paiements placés en bac à sable ou totalement neutralisés ;
• webhooks et API sortants bloqués ou remplacés par des destinations de test ;
• tâches cron et automatisations inspectées avant leur exécution.

Le clone peut contenir des données personnelles ou commerciales. L’accès doit donc rester limité aux personnes nécessaires, et les copies de test doivent être supprimées ou conservées selon une procédure maîtrisée après l’exercice.

Que faut-il préparer avant de lancer le test ?

Rassemblez les éléments suivants avant de démarrer :

• date et heure exactes de la sauvegarde ;
• source des fichiers et source de la base de données ;
• taille annoncée et taille téléchargée ;
• mot de passe ou clé de déchiffrement ;
• version de WordPress, PHP et base de données ;
• liste des extensions et thèmes critiques ;
• accès au stockage, à l’hébergement et au DNS de test ;
• liste des fonctions métier à valider ;
• procédure de blocage des e-mails et intégrations ;
• heure de début prévue afin de mesurer le temps de reprise.

Conservez aussi la production intacte. Le test ne doit pas devenir une migration improvisée ni modifier les sauvegardes d’origine.

Étape 1 : inventorier et identifier le jeu de sauvegarde

Commencez par vérifier que les éléments appartiennent au même point de reprise. Une base de données du lundi associée à des fichiers du vendredi peut produire des médias absents, des extensions incohérentes ou un schéma de base incompatible avec le code restauré.

Notez au minimum :

• nom des archives ;
• horodatage de début et de fin ;
• site ou environnement source ;
• version de l’outil ayant créé la sauvegarde ;
• type de sauvegarde : complète, incrémentale, différentielle ou base seule ;
• emplacement et durée de conservation ;
• empreinte ou somme de contrôle si elle est fournie ;
• erreurs ou avertissements enregistrés pendant la tâche.

Étape 2 : vérifier les archives avant la restauration

Une simple ouverture de l’archive ne suffit pas, mais elle permet de détecter rapidement plusieurs anomalies. Extrayez les fichiers dans un répertoire temporaire et contrôlez :

• l’absence d’erreur d’extraction ;
• la présence des répertoires attendus ;
• le nombre et le volume approximatifs des médias ;
• la présence du thème enfant et des extensions spécifiques ;
• la présence d’un export de base de données lorsque le format l’intègre ;
• l’absence de fichiers à taille nulle manifestement anormaux ;
• les journaux ou manifestes produits par l’outil de sauvegarde.

Pour la base de données, le contrôle décisif reste l’import dans une base vide. Un fichier SQL lisible dans un éditeur peut encore échouer à cause d’un export interrompu, d’un encodage, d’une limite serveur ou d’une instruction incompatible.

Étape 3 : restaurer les fichiers WordPress

Déployez les fichiers dans le répertoire de test prévu. Contrôlez immédiatement les propriétaires, les permissions, les liens symboliques et les fichiers de configuration spécifiques à l’ancien hébergement.

Certains éléments doivent être adaptés plutôt que copiés aveuglément :

• chemins de cache liés au serveur précédent ;
• règles .htaccess ou configuration Nginx ;
• paramètres de CDN ou de stockage objet ;
• fichiers de configuration contenant les identifiants de production ;
• extensions propres à l’hébergeur précédent ;
• chargeurs PHP ou caches incompatibles avec l’environnement de test.

L’objectif n’est pas seulement d’obtenir une copie des fichiers, mais un environnement dont le comportement reste maîtrisé.

Étape 4 : importer réellement la base de données

Créez une base vide réservée au test, avec un utilisateur et des droits dédiés. Importez ensuite l’export complet. WP-CLI fournit les commandes wp db export et wp db import pour exporter et importer une base à partir des identifiants présents dans wp-config.php.

wp db import /chemin/vers/sauvegarde.sql

Après l’import, vérifiez :

• le nombre de tables attendu ;
• le préfixe réellement utilisé ;
• l’absence d’erreur d’import ;
• la présence des tables créées par les extensions critiques ;
• la taille globale de la base par rapport à la source ;
• les utilisateurs et contenus attendus à la date de reprise.

Ne réutilisez jamais la base de production comme cible du test. Une commande d’import peut écraser ou remplacer des données existantes.

Étape 5 : adapter la configuration et les URL sans corrompre les données

Mettez à jour les identifiants de la base, les chemins et les constantes spécifiques à l’environnement. Si le domaine de test diffère, certaines URL doivent également être remplacées.

Une recherche-remplacement SQL brute peut endommager les données sérialisées utilisées par WordPress et ses extensions. WP-CLI propose une commande qui sait traiter ces structures et permet d’effectuer d’abord une simulation avec --dry-run.

wp search-replace 'https://www.exemple.fr' 'https://test.exemple.fr' \
  --all-tables-with-prefix \
  --skip-columns=guid \
  --dry-run

Analysez le rapport avant toute modification réelle. Sur un multisite, un site utilisant des tables hors préfixe standard ou une extension complexe, le périmètre doit être adapté avec prudence.

Étape 6 : vérifier que WordPress démarre correctement

Avant les tests métier, vérifiez les fondations :

• code HTTP correct sur la page d’accueil et le back-office ;
• absence d’écran blanc, boucle de redirection ou erreur de connexion à la base ;
• connexion avec un compte administrateur de test autorisé ;
• version de WordPress, extensions et thème cohérentes avec le point de reprise ;
• permalien et réécriture fonctionnels ;
• absence d’erreurs PHP bloquantes dans les journaux ;
• médias affichés sans erreur 404 ni URL de production inattendue ;
• absence d’indexation publique de l’environnement de test.

L’écran Santé du site peut fournir des informations complémentaires, mais il ne remplace pas les scénarios fonctionnels ni l’analyse des journaux.

Étape 7 : tester les fonctions réellement importantes

La page d’accueil peut s’afficher alors que le formulaire de contact, le checkout, les tâches planifiées ou l’espace client sont inutilisables. Préparez une matrice correspondant au rôle du site.

Zone	Tests à effectuer	Preuve à conserver
Front-office	Accueil, pages stratégiques, navigation, recherche, mobile et erreurs 404	Captures et liste des URL validées
Back-office	Connexion, rôles, édition, médias, réglages et mises à jour visibles	Compte de test et journal des contrôles
Médias	Images originales, miniatures, PDF et téléchargements protégés	Échantillon comparé à la production
Formulaires	Validation, enregistrement, notification neutralisée et intégration CRM de test	Entrée de test et trace de traitement
SEO	Canonique, robots, sitemap, redirections et absence d’indexation du staging	Contrôle du code source et des en-têtes
API et webhooks	Authentification, routes nécessaires et destinations de test	Journal d’appel sans effet réel
Tâches planifiées	Liste des événements, fonctionnement du déclenchement et absence d’action dangereuse	Rapport cron et journaux
Fonction métier	Commande, réservation, inscription, espace membre ou téléchargement selon le site	Scénario complet validé

Comment tester les e-mails, formulaires et CRM sans envoyer de vrais messages ?

Les e-mails sortants doivent être interceptés par un outil de test, redirigés vers une boîte contrôlée ou désactivés au niveau de l’environnement. Ne vous contentez pas de désactiver un plugin d’e-mail si un fournisseur SMTP, une API ou un script indépendant peut encore envoyer.

Pour chaque formulaire important, vérifiez :

• l’affichage et la validation des champs ;
• la création éventuelle d’une entrée dans WordPress ;
• la notification, sans destinataire réel ;
• la transmission à un CRM ou un outil tiers de test ;
• le consentement, les pièces jointes et les messages d’erreur ;
• la présence des données attendues après restauration.

Le test doit révéler si les demandes reçues entre le point de sauvegarde et l’incident seraient perdues ou récupérables depuis un autre système.

Comment vérifier WP-Cron et les tâches planifiées ?

Les sauvegardes restaurent souvent les événements planifiés enregistrés dans la base. Ils peuvent donc reprendre leur exécution dans le clone. Avant de les laisser fonctionner, identifiez les tâches liées aux e-mails, synchronisations, abonnements, imports, exports et webhooks.

WP-CLI permet notamment de tester le mécanisme WP-Cron et de lister les événements programmés :

wp cron test
wp cron event list

La présence d’un événement ne prouve pas que son traitement aboutit. Les tâches critiques doivent être exécutées de façon contrôlée, avec leurs destinations externes neutralisées et leurs journaux observés.

Quelles vérifications supplémentaires pour WooCommerce ?

Une restauration WooCommerce doit préserver la continuité entre les données du site et les opérations enregistrées chez les prestataires externes. Le site restauré ne doit jamais initier un paiement ou un remboursement réel pendant le test.

Commandes et clients

Comparez un échantillon de commandes avec la production ou les exports disponibles : numéro, date, statut, client, lignes, taxes, livraison et notes. Vérifiez aussi les comptes clients, adresses et droits d’accès.

Paiements

Passez les passerelles en mode test ou désactivez-les. Un statut WooCommerce ne doit pas être utilisé comme seule preuve du paiement réel : le rapprochement avec le prestataire reste nécessaire en situation de reprise.

Checkout et e-mails

Testez le panier, les coupons, les frais, les taxes et le tunnel complet avec une commande de test. WooCommerce recommande d’effectuer les tests de paiement exclusivement sur un site de staging afin d’éviter les complications sur la production.

Abonnements et actions programmées

Les renouvellements, prélèvements récurrents, relances et tâches Action Scheduler exigent un contrôle spécifique. Ne supposez pas qu’un changement de domaine neutralise toutes les extensions ou tous les prestataires.

Comment savoir si la sauvegarde contient déjà l’incident ?

Un test de restauration démontre que le site peut être remis en fonctionnement, mais pas automatiquement qu’il est sain. Si la sauvegarde a été créée après le début d’un piratage non détecté, elle peut restaurer le malware, un administrateur inconnu, une tâche persistante ou une extension vulnérable.

En contexte de sécurité, vérifiez notamment :

• la date probable du premier signal ;
• les comptes, rôles et sessions présents dans la sauvegarde ;
• les fichiers ajoutés ou modifiés anormalement ;
• les tâches planifiées et règles serveur ;
• les versions vulnérables des extensions et thèmes ;
• les injections dans la base de données ;
• les autres installations présentes sur le même hébergement.

Si le malware réapparaît après une restauration, consultez le guide Site WordPress réinfecté après nettoyage : pourquoi le malware revient-il ?. La restauration ne doit intervenir qu’avec une analyse du point d’entrée et des versions disponibles.

Comment mesurer la fraîcheur réelle des données restaurées ?

Ne vous fiez pas uniquement au nom du fichier. Vérifiez dans le site restauré des marqueurs concrets proches de l’heure annoncée :

• dernier article ou dernière page modifiée ;
• dernier média téléversé ;
• dernière entrée de formulaire ;
• dernière commande ou réservation ;
• dernier utilisateur créé ;
• dernière modification d’un réglage critique.

Comparez ces éléments à la production, aux e-mails, au CRM, au prestataire de paiement ou aux exports disponibles. Cette étape permet d’estimer la perte réelle en cas de reprise sur ce point.

Comment mesurer le temps réel de restauration ?

Chronométrez séparément :

• l’accès et le téléchargement des sauvegardes ;
• la préparation de l’environnement ;
• la restauration des fichiers ;
• l’import de la base ;
• les adaptations de configuration ;
• les corrections techniques ;
• les tests fonctionnels ;
• la validation métier et la décision de remise en ligne.

Le temps de téléchargement peut devenir déterminant pour un site riche en médias. L’import d’une base volumineuse peut également dépasser les limites d’un panneau web alors qu’une restauration en ligne de commande reste possible. Le test révèle ces contraintes avant l’urgence.

Comment classer le résultat du test ?

Résultat	Critères	Décision
Validé	Restauration complète, fonctions critiques opérationnelles, écarts documentés, RPO et RTO acceptables	Conserver la procédure et planifier le prochain exercice
Validé avec réserves	Site restauré mais étapes manuelles, fonctions secondaires ou délai à améliorer	Corriger le plan et refaire un test ciblé
Partiel	Front-office visible mais données, médias, accès ou fonctions métier incomplets	Ne pas considérer la sauvegarde comme solution de reprise complète
Échec	Archive inutilisable, import impossible, site non démarrable ou données critiques absentes	Corriger immédiatement le dispositif de sauvegarde
Non sain	Restauration fonctionnelle mais présence probable d’une compromission ou d’une erreur connue	Analyser et nettoyer avant d’utiliser ce point de reprise

La mention « restaurable » doit être associée à une date de test, un périmètre et une version de sauvegarde précis. Une validation ancienne ne garantit pas les sauvegardes actuelles après une migration, un changement d’outil ou l’ajout de WooCommerce.

À quelle fréquence tester la restauration ?

La fréquence dépend de la criticité, du rythme de changement et de la maturité du dispositif. Un test complet doit aussi être déclenché après certains événements.

• changement d’hébergeur ou d’architecture ;
• remplacement de l’outil de sauvegarde ;
• activation d’un stockage distant ou du chiffrement ;
• ajout de WooCommerce, d’un espace membre ou d’une réservation ;
• refonte importante ou changement de thème ;
• migration de la base ou activation d’un nouveau mode de stockage ;
• incident, restauration réelle ou suspicion de sauvegarde incomplète ;
• modification des accès, clés de chiffrement ou procédures internes.

Entre deux exercices complets, contrôlez au minimum la date, le volume, les erreurs, la présence du fichier de base et la disponibilité des copies hors site. Ces contrôles ne remplacent pas la restauration, mais ils détectent plus tôt certaines dérives.

Que doit contenir le rapport de test ?

Le rapport doit permettre à une autre personne de comprendre ce qui a été testé et de reproduire la reprise.

• site et environnement concernés ;
• date du test et personnes présentes ;
• identifiant, date et type de sauvegarde ;
• emplacement et méthode de récupération ;
• versions techniques de l’environnement ;
• étapes réellement exécutées ;
• temps consacré à chaque phase ;
• tests fonctionnels réussis et échoués ;
• écarts de données observés ;
• actions correctives, responsable et échéance ;
• classification finale et date du prochain test.

Évitez d’inscrire les mots de passe et secrets directement dans le rapport. Référencez plutôt le coffre ou la procédure permettant de les obtenir.

Les erreurs qui donnent une fausse impression de sécurité

Se contenter d’ouvrir le fichier ZIP

L’extraction prouve seulement que l’archive est lisible. Elle ne valide ni l’import de la base, ni la configuration, ni les fonctions métier.

Tester uniquement la page d’accueil

Un site peut afficher l’accueil avec un cache tout en ayant un back-office inaccessible, des médias absents ou un checkout cassé.

Restaurer les fichiers et oublier la base

Les contenus, utilisateurs, réglages, commandes et données dynamiques risquent alors de manquer.

Utiliser le même hébergement comme seul environnement de test

Le test ne vérifie pas la capacité à reprendre lorsque le compte d’hébergement, le serveur ou le stockage principal est indisponible.

Laisser les e-mails et webhooks actifs

Le clone peut contacter de vrais clients, créer des doublons dans le CRM ou déclencher des actions irréversibles.

Ne pas mesurer le temps

Une restauration techniquement possible mais trop lente ne répond pas nécessairement au besoin de l’entreprise.

Oublier les accès et les clés de déchiffrement

Un fichier parfaitement intact reste inutilisable si personne ne peut le télécharger, le déchiffrer ou accéder au compte nécessaire.

Confondre restauration et assainissement

Une sauvegarde peut restaurer un site compromis. Après un piratage, le point de reprise doit être analysé et la cause corrigée.

Les informations à préparer pour faire tester une sauvegarde

• URL et type de site ;
• hébergeur et environnement technique ;
• outil ou service de sauvegarde utilisé ;
• emplacement des copies et durée de conservation ;
• date de la dernière sauvegarde complète ;
• présence de WooCommerce, réservations, membres ou formulaires stockés ;
• intégrations externes critiques ;
• temps d’arrêt et perte de données acceptables ;
• ancien rapport de restauration ou incident connu ;
• personne autorisée à valider les fonctions métier.

Ne transmettez pas les mots de passe dans le formulaire initial. Les accès nécessaires doivent être demandés séparément et limités à la durée de l’intervention.

Questions fréquentes

Peut-on tester une sauvegarde WordPress sans toucher au site en ligne ?

Oui. C’est même la méthode recommandée. La sauvegarde doit être restaurée sur un staging, un hébergement séparé, une machine virtuelle ou un environnement local suffisamment proche de la production.

Une archive qui s’extrait sans erreur est-elle restaurable ?

Pas nécessairement. L’extraction valide seulement une partie du contrôle. Il faut encore importer la base, démarrer WordPress et tester les fonctions réelles.

Faut-il restaurer les fichiers ou la base en premier ?

La documentation WordPress indique un ordre typique consistant à restaurer les fichiers, puis à importer la base. Le point essentiel est surtout d’utiliser un jeu cohérent et d’adapter la configuration à l’environnement cible.

Combien de temps dure un test de restauration WordPress ?

La durée dépend du volume des médias, de la taille de la base, des accès, de l’environnement et du nombre de fonctions à valider. Le test sert justement à mesurer ce délai au lieu de l’estimer.

À quelle fréquence faut-il faire un test complet ?

Un site professionnel peu critique peut être testé une fois par an. Un WooCommerce, une réservation ou un site central pour l’activité mérite généralement des exercices plus rapprochés, ainsi qu’un nouveau test après chaque changement majeur du dispositif.

Comment tester un WooCommerce sans encaisser un paiement ?

Le test doit avoir lieu sur un staging avec les passerelles en mode bac à sable ou neutralisées. Les e-mails, webhooks, abonnements et actions programmées doivent être contrôlés avant de simuler une commande.

Une sauvegarde peut-elle être restaurable mais infectée ?

Oui. La restauration peut fonctionner parfaitement et remettre en place une compromission déjà présente à la date du backup. En contexte d’incident, il faut contrôler la chronologie et analyser la sauvegarde avant de la remettre en production.

Que faire si le test échoue ?

Documentez le point de blocage, corrigez le périmètre, le stockage, les accès ou la procédure, puis créez une nouvelle sauvegarde et recommencez. Une sauvegarde ayant échoué au test ne doit pas rester le seul plan de reprise.

Sources officielles

• WordPress : sauvegardes, fichiers, base de données et ordre de restauration ;
• WordPress : sauvegarder les fichiers ;
• WordPress : sauvegarder et restaurer la base de données ;
• WP-CLI : importer une base de données ;
• WP-CLI : recherche-remplacement avec gestion des données sérialisées et simulation ;
• WP-CLI : tester et inspecter WP-Cron ;
• WooCommerce : réaliser les tests de commande sur un site de staging.