Sauvegarder et restaurer un site EmDash

Une sauvegarde WordPress se résume à deux objets : un dump SQL et le dossier wp-content. Sur EmDash, la question est différente — non pas plus compliquée, mais découpée autrement. Le contenu, les médias, la configuration et l’état des plugins ne vivent pas au même endroit, et une sauvegarde qui n’en couvre que trois sur quatre donne une restauration qui démarre sans fonctionner.

Voici ce qu’il faut réellement copier, dans quel ordre restaurer, et surtout comment vérifier qu’une sauvegarde est exploitable avant d’en avoir besoin.

Les quatre choses à sauvegarder

Le contenu structuré. Pages, articles, taxonomies, utilisateurs et leurs rôles. C’est la base de données, et c’est le seul élément dont la perte est irrattrapable.

Les médias. Images, documents, fichiers téléversés. Ils vivent dans un stockage objet, séparé de la base. La base ne contient que des références.

La configuration du site. Réglages globaux, routes, redirections, paramètres de thème. Une partie est en base, une autre dans les variables d’environnement du déploiement.

L’état des plugins. La liste des extensions installées, leur version, et surtout les permissions accordées à chacune. C’est la partie qu’on oublie, et elle est spécifique à EmDash : un plugin restauré sans ses permissions s’exécute mais ne fait rien, silencieusement. Le modèle de permissions et ses implications sont détaillés dans notre article sur les limites du bac à sable des plugins.

Ce qu’une plateforme gérée fait déjà

Si le site tourne sur l’infrastructure gérée, une partie du travail est faite : la base est répliquée, le stockage objet est durable, et des points de restauration existent.

Deux précisions qui changent tout.

Réplication n’est pas sauvegarde. Une base répliquée protège de la panne matérielle. Elle ne protège pas d’une suppression accidentelle ni d’un plugin qui écrase du contenu : l’erreur est répliquée aussi fidèlement que le reste.

Un point de restauration a une profondeur limitée. Elle couvre les incidents détectés rapidement, pas une corruption qui remonte à trois mois. Pour un site dont le contenu représente un travail réel, une sauvegarde externe reste nécessaire.

L’export de contenu

L’export produit un fichier structuré contenant l’intégralité des entrées, avec leurs métadonnées et leurs relations. C’est le cœur de la sauvegarde.

Deux règles.

Exporter au format natif, pas en HTML rendu. Un export HTML perd la structure et rend la réimportation manuelle. Le format natif conserve les relations entre entrées, les taxonomies et les champs personnalisés.

Stocker l’export hors de l’infrastructure du site. Une sauvegarde qui vit sur le même compte que le site ne protège pas de la perte de ce compte. C’est la règle des trois copies, deux supports, une hors site — la même que celle qui s’applique à n’importe quel actif numérique.

Les médias, le poste qui pèse

Sur un site de plusieurs années, les médias représentent l’essentiel du volume. Deux stratégies.

La copie miroir, via un client compatible avec le protocole de stockage objet, vers un autre fournisseur ou un disque local. C’est la méthode complète, à faire une fois puis en incrémental.

La sauvegarde des originaux seulement. EmDash génère les déclinaisons — vignettes, formats responsive, conversions — à la demande. Sauvegarder uniquement les fichiers originaux divise le volume par trois ou quatre, au prix d’une régénération au premier affichage après restauration. Sur un site avec beaucoup d’images, c’est le bon arbitrage ; le fonctionnement du pipeline média est décrit dans notre article sur les images et médias dans EmDash.

La configuration : le fichier qu’on oublie

C’est la cause la plus fréquente de restauration qui échoue.

Les variables d’environnement — clés d’API, identifiants de stockage, secrets de session — ne figurent dans aucun export de contenu. Elles vivent dans la configuration du déploiement, et elles ne sont pas récupérables après coup : une clé secrète perdue se régénère, avec les conséquences que cela implique sur les sessions en cours et les intégrations tierces.

Tenez une liste des variables — les noms, pas les valeurs — dans votre documentation projet, et stockez les valeurs dans un gestionnaire de secrets. C’est cinq minutes de travail qui évitent une journée de reconstitution.

L’ordre de restauration

Il n’est pas interchangeable.

Créer l’instance vierge avec la même version d’EmDash que celle de la sauvegarde. Restaurer un export ancien sur une version récente peut fonctionner, mais c’est une migration, pas une restauration — et cela se prépare comme telle, selon la procédure décrite dans mettre à jour EmDash.
Restaurer les variables d’environnement, avant tout le reste. Sans elles, la connexion au stockage échoue et l’import des médias part en erreur.
Restaurer les médias, avant le contenu. Un contenu importé avant ses médias affiche des images cassées jusqu’au prochain passage de régénération.
Importer le contenu.
Réinstaller les plugins et réaccorder leurs permissions. C’est manuel, et c’est le moment où la liste tenue en amont sert.
Vérifier. Voir ci-dessous.

Vérifier qu’une sauvegarde est bonne

Une sauvegarde non testée n’est pas une sauvegarde. La vérification tient en quatre contrôles, à faire sur une instance de test, pas en production.

Contrôle	Ce qu’il révèle
Compter les entrées publiées	Un export tronqué
Ouvrir trois pages au hasard, dont une avec galerie	Médias non restaurés, références cassées
Se connecter avec un compte non administrateur	Rôles et permissions mal restaurés
Déclencher une action d’un plugin	Permissions non réaccordées

Le quatrième est le plus souvent oublié, et c’est celui qui échoue le plus. Un plugin sans permission ne lève pas d’erreur visible : il ne fait rien.

La fréquence raisonnable

Elle se déduit d’une seule question : combien de contenu acceptez-vous de perdre ?

Site publiant quotidiennement : export de contenu quotidien, médias en incrémental hebdomadaire.
Site publiant quelques fois par mois : export hebdomadaire suffit.
Site vitrine stable : export mensuel, plus un export manuel avant toute mise à jour majeure ou installation de plugin.

Cette dernière habitude est la plus rentable de toutes : un export avant chaque changement structurel. Il coûte une minute et transforme une mise à jour ratée en simple retour en arrière.

Ce que la sauvegarde ne couvre pas

Deux choses, qu’il faut traiter séparément.

Les données analytiques. Si vous mesurez l’audience, ces données vivent ailleurs et se sauvegardent selon leur propre logique — le sujet est traité dans notre article sur mesurer l’audience sans bandeau cookies.

Le nom de domaine et sa zone DNS. Une restauration parfaite sur une instance dont personne ne connaît la configuration DNS ne remet rien en ligne. Gardez une copie de votre zone, au même endroit que la liste de vos variables d’environnement.

En résumé

Quatre objets à copier, un ordre à respecter, quatre contrôles à faire. Le point spécifique à EmDash, celui qui n’existe nulle part ailleurs, est la restauration des permissions de plugins : c’est là que se jouent la plupart des restaurations qui « fonctionnent » sans fonctionner.

Testez-en une maintenant, sur une instance jetable. C’est le seul moyen de savoir ce que vaut réellement votre sauvegarde.