Ta sauvegarde WordPress fonctionne-t-elle ? Restaurer dans une VM isolée

Un fichier de sauvegarde présent sur le serveur n’est pas encore une preuve de récupération. Pour le devenir, il faut restaurer le site, lire ses contenus, vérifier ses médias et retrouver ses fonctions utiles. Cet atelier construit un exercice sur une VM de laboratoire hébergée sur un serveur. La production reste la source de la copie ; aucune importation ni recherche-remplacement ne doit la viser.

Procédure préparée le 30 septembre 2026, à adapter à ton hébergement. Les commandes sont des exemples pédagogiques Linux ; cette restauration complète n’a pas été exécutée pour l’article. Ne lance les étapes d’écriture qu’après validation de l’isolation et des chemins du laboratoire.

Télécharger le mémo : sauvegarde et restauration WordPress

1. Définir ce que « récupéré » signifie

Écris deux objectifs avant le test. Le RPO correspond à la quantité de données récentes que tu acceptes de perdre, exprimée en durée. Le RTO correspond au temps visé pour remettre un service utilisable. Exemple d’exercice, sans promesse de performance : « au plus quatre heures de publications perdues et site lisible en deux heures ». Une boutique ou un site de réservation peut nécessiter une cohérence beaucoup plus stricte qu’un blog.

Choisis des témoins : un article récent, une image, un fichier à télécharger, une rubrique, un utilisateur de test et une fonction de formulaire. Note leurs références avant la sauvegarde. Chronomètre toute la récupération, depuis la recherche de l’archive et de sa clé jusqu’aux vérifications finales. Si déchiffrer une archive exige un compte inaccessible pendant la panne, ton RTO doit inclure cette difficulté.

2. Réunir fichiers, base et informations d’exploitation

Le guide de sauvegarde WordPress rappelle que base et fichiers sont nécessaires. La base contient notamment articles et réglages ; les fichiers comprennent thèmes, extensions, uploads et configuration. Ajoute les informations permettant de reconstruire l’environnement : versions PHP/base, configuration web, tâches serveur et chemin des volumes. Conserve les secrets à part, chiffrés et avec un accès limité.

Pour illustrer la création d’un lot sur un serveur autorisé, les exemples suivants lisent les données du site et écrivent dans un répertoire privé déjà créé. Les chemins sont fictifs. Vérifie que /srv/backups/wp-atelier est hors du répertoire servi par HTTP et appartient au compte de sauvegarde :

umask 077
wp --path=/srv/www/site db export /srv/backups/wp-atelier/database.sql --single-transaction
tar -czf /srv/backups/wp-atelier/files.tar.gz -C /srv/www/site .
cd /srv/backups/wp-atelier
sha256sum database.sql files.tar.gz > SHA256SUMS

La commande d’export WP-CLI s’appuie sur l’outil de la base. --single-transaction aide pour les tables transactionnelles compatibles ; il ne rend pas atomiques une base et une arborescence qui continuent de changer. Prévois une courte pause maîtrisée des écritures ou un mécanisme de snapshot cohérent, adapté au stockage. Ne lance pas de migration ou de changement de structure pendant le lot.

Copie le lot vers un stockage séparé, chiffre-le et vérifie sa lecture. Une empreinte SHA-256 détecte une différence si le fichier de référence est fiable ; elle ne prouve pas l’authenticité d’un lot que l’attaquant pourrait remplacer avec ses empreintes. Garde plusieurs générations protégées : une copie récente peut déjà contenir une compromission.

3. Construire un laboratoire qui ne peut pas écrire ailleurs

Prépare une VM serveur dédiée avec les versions nécessaires, puis place-la sur un réseau de laboratoire sans route vers Internet ni vers les réseaux de production. Son accès passe par une console ou un poste de test sur ce même réseau isolé. Elle ne doit recevoir ni base partagée, ni volume de production, ni clés SSH de déploiement. Installe les dépendances avant d’apporter la copie sensible, puis applique l’isolation.

Teste cette frontière avant de démarrer WordPress. Depuis la VM, un service témoin externe autorisé et un service témoin sur le réseau de production doivent être injoignables ; évite toute écriture réelle. Confirme le refus dans les journaux du filtrage et vérifie l’absence de route inattendue, y compris IPv6. Un simple échec DNS n’est pas une preuve : un programme peut utiliser une adresse directement.

Pour une variante Docker sur serveur, la documentation Compose fournit internal: true. Il faut encore vérifier tous les réseaux attachés, les ports publiés, les accès à l’hôte et l’absence de montage du socket Docker. Le petit fragment suivant décrit un principe, pas un environnement complet prêt à lancer :

networks:
  restore_lab:
    internal: true
# Tous les services de la copie utilisent exclusivement restore_lab.
# Aucun réseau externe, volume de production ou socket Docker.

4. Neutraliser les effets secondaires de la copie

Avant de démarrer PHP sur les fichiers restaurés, remplace la configuration du laboratoire : base locale dédiée, compte local sans droits sur la production, URL http://wp-lab.test, nouveaux secrets et identifiants d’intégration de test. Retire les secrets opérationnels des fichiers et, après l’import isolé, des réglages stockés en base avant de charger les modules. Désactive les tâches planifiées du laboratoire et les agents serveur d’import, d’email ou de publication sociale.

Dans le wp-config.php du laboratoire uniquement, place define('DISABLE_WP_CRON', true); avant le chargement de WordPress. Cela ne coupe pas un cron système ni les files exécutées par d’autres mécanismes : vérifie aussi ces couches. Si le site semble compromis, n’exécute pas ses extensions sur un hôte sensible ; travaille sur une copie isolée et compare avec des sources propres.

Une seconde couche utile est un fichier wp-content/mu-plugins/lab-no-outbound.php, chargé automatiquement comme must-use plugin :

<?php
/** Plugin Name: Laboratoire - pas de sorties */
add_filter('pre_wp_mail', function ($result, $atts) {
    return false;
}, 10, 2);
add_filter('pre_http_request', function ($pre, $args, $url) {
    return new WP_Error('lab_outbound_blocked', 'Sortie HTTP bloquée dans le laboratoire');
}, 10, 3);

Les filtres pre_wp_mail et pre_http_request arrêtent les parcours WordPress correspondants. Ils ne bloquent pas un appel cURL direct, une bibliothèque SMTP indépendante ou les requêtes d’un navigateur : l’isolation réseau reste la barrière principale. Navigue depuis le client de test isolé et contrôle les références à des médias externes.

5. Restaurer et adapter les URL sans casser les données sérialisées

Inspecte d’abord la liste des chemins de l’archive et ses liens. Extrais seulement dans l’arborescence neuve du laboratoire ; une archive inconnue peut contenir des chemins indésirables. Vérifie les empreintes et prépare un wp-config.php local avant toute importation. Le fichier SQL peut être importé avec WP-CLI db import dans la base dédiée :

wp --path=/srv/lab/wp config get DB_HOST
wp --path=/srv/lab/wp config get DB_NAME
wp --path=/srv/lab/wp db import /srv/lab/backups/database.sql
wp --path=/srv/lab/wp --skip-plugins --skip-themes search-replace   'https://example.com' 'http://wp-lab.test'   --all-tables-with-prefix --skip-columns=guid --dry-run

Compare l’hôte et le nom de base avec la fiche du laboratoire avant l’import. Ces contrôles n’affichent pas le mot de passe. Le search-replace WP-CLI traite les données PHP sérialisées, contrairement à un remplacement aveugle dans un fichier SQL. Le dry-run affiche les changements envisagés sans les enregistrer. Examine tables et compteurs, sauvegarde l’état importé, puis répète exactement la dernière commande sans --dry-run dans le laboratoire seulement.

--skip-plugins ne saute pas les must-use plugins : la couche de blocage continue donc à charger. Pour un multisite, des domaines secondaires ou des tables partagées, définis explicitement le périmètre ; ces exemples supposent un site simple et une base réservée au laboratoire. Configure le nom de test sur le réseau isolé, sans modifier le DNS public ni le domaine de production.

6. Prouver la restauration, puis mesurer

Lis les témoins préparés, ouvre les médias et le PDF, parcours les rubriques, vérifie les liens et connecte l’utilisateur de test. Vérifie qu’un formulaire ne provoque aucune sortie réseau ni mail réel ; avec le filtre proposé, un envoi peut échouer volontairement. Pour tester une réussite d’email, utilise un collecteur SMTP strictement interne avec des données fictives et une configuration explicitement limitée au labo.

Identifie la borne de cohérence du lot et compare les écritures attendues aux éléments effectivement retrouvés : tu mesures la perte constatée et la compares au RPO. L’âge du dernier article, sans vérifier s’il y avait des écritures depuis, ne suffit pas. Note le temps total et compare-le au RTO. Classe les écarts : lot incomplet, clé inaccessible, version incompatible, URLs restantes ou documentation insuffisante. Refais la restauration après correction.

7. Garder une routine vérifiable sur serveur

Automatise éventuellement la création et le contrôle des lots sur un serveur, avec alerte sur un échec réel et une rétention adaptée. Programme aussi un exercice de restauration régulier : un contrôle de taille ou d’empreinte seul ne valide pas les fonctions. Après l’atelier, retire la VM et les copies de test selon le périmètre vérifié, en conservant le rapport minimal ; aucune commande de destruction de volume de production n’est nécessaire.

Sources

Documentation consultée le 30 septembre 2026 : WordPress : sauvegardes, export WP-CLI, import WP-CLI, URLs et sérialisation, réseaux Docker Compose, blocage wp_mail et blocage de l’API HTTP WordPress. Complète avec le guide des formulaires et des moteurs.