Sauvegarder et restaurer un site EmDash

EmDash offre trois niveaux de protection qui ne se remplacent pas : l’archive de contenu téléchargeable depuis l’administration, les archives automatiques déposées quotidiennement dans votre stockage objet, et la restauration à un instant donné de la base sur Cloudflare D1. Le point que l’on découvre trop tard : l’archive de contenu ne contient ni les comptes, ni les secrets, ni les fichiers médias. Une sauvegarde complète est donc toujours au moins trois éléments distincts.

Cet article est vérifié contre la documentation officielle d’EmDash au 23 août 2026, sur la ligne de version 0.34.x. Les écrans d’administration et les options de commande évoluent vite : revérifiez-les sur votre version.

Ce que contient une archive, et ce qu’elle laisse dehors

L’archive produite par EmDash est un fichier JSON au même format d’instantané que celui du système de prévisualisation, marqué de la version qui l’a créée. Elle contient de quoi reconstruire le contenu du site, mais elle s’arrête volontairement à la frontière des données sensibles et des fichiers binaires.

Dans l’archive	Hors de l’archive
Toutes les entrées, y compris brouillons, contenus programmés et corbeille	Comptes, sessions, clés d’accès et jetons d’API
Définitions des collections et des champs — votre modèle de contenu	Secrets : clé de signature de prévisualisation, configuration des extensions
Taxonomies et affectations de termes	Fichiers médias eux-mêmes
Menus, widgets, sections, réglages de référencement
Révisions et métadonnées des médias
Réglages du site : titre, accroche, préférences d’affichage

Les trois exclusions sont des choix explicites. Les données d’authentification ne sont ni portables ni sûres dans un fichier qu’on télécharge. Les secrets non plus. Les fichiers médias, eux, vivent dans votre stockage objet — l’archive n’en transporte que les métadonnées, ce qui suffit pour que les références restent intactes si les fichiers sont toujours là.

Retenez la conséquence pratique : restaurer l’archive dans un stockage vide vous rend un site dont toutes les images sont cassées. Le stockage se sauvegarde séparément, avec les outils de votre fournisseur.

Niveau 1 — l’archive téléchargée à la main

Dans l’administration, Réglages → Sauvegardes, le bouton de téléchargement produit une archive fraîche et l’envoie dans votre navigateur. L’opération demande le rôle administrateur.

C’est l’outil des opérations risquées, et la documentation le présente ainsi : import en masse, changement de modèle de contenu, montée de version majeure. Prenez-la juste avant, pas la veille. C’est aussi la seule copie qui n’a aucune date d’expiration et qui survit à la suppression du compte d’hébergement ou de la base : elle est sur votre disque, elle vous appartient.

Le réflexe utile : renommer le fichier avec la date et la version en service au moment de la prise. Le nom d’origine ne dit pas contre quelle version du produit l’instantané a été fait, et cette information devient décisive au moment de s’en servir.

Niveau 2 — les archives automatiques dans le stockage

Si le site a un stockage objet configuré — R2 sur Cloudflare, un service compatible S3, ou le stockage local —, l’administration permet d’activer une sauvegarde quotidienne automatique. On choisit combien d’archives conserver, de 1 à 30 ; les plus anciennes sont supprimées au fur et à mesure.

Les archives sont déposées sous le préfixe backups/ du dépôt, nommées emdash-backup-<horodatage>-<aléa>.json. La liste des archives conservées s’affiche dans l’administration, avec téléchargement et suppression à l’unité, et un bouton pour en produire une immédiatement.

Deux limites à connaître avant de compter sur ce niveau.

Il dépend du déclencheur planifié. Les sauvegardes automatiques s’appuient sur le même battement de maintenance que la publication programmée : sur Cloudflare, le déclencheur cron du Worker ; sur Node, l’ordonnanceur intégré. Si votre déploiement n’a pas de déclencheur planifié configuré, rien ne se déclenchera — utilisez alors le bouton manuel, et sachez que vous n’avez pas de sauvegarde automatique malgré l’interrupteur activé.

Les archives partagent le dépôt avec vos médias. EmDash refuse de servir quoi que ce soit sous backups/ par sa route média, et les noms portent un suffixe aléatoire. Mais si vous exposez le dépôt lui-même derrière un domaine R2 public ou un réseau de diffusion, tout ce qu’il contient devient accessible par URL, archives comprises. Servez les médias à travers EmDash, ou restreignez le domaine public au seul préfixe des médias.

Niveau 3 — la restauration à un instant donné sur D1

Si le site tourne sur Cloudflare D1, vous disposez déjà d’une restauration à un instant donné de la base, active en permanence et sans configuration. C’est le filet de sécurité des incidents.

# Relever le repère courant, avant une opération risquée
npx wrangler d1 time-travel info ma-base

# Restaurer la base à un horodatage précis
npx wrangler d1 time-travel restore ma-base --timestamp=2026-08-23T13:00:00Z

L’historique couvre 30 jours sur le plan payant et 7 jours sur le plan gratuit, avec une granularité à la minute. Elle restaure toute la base : contenu, comptes, réglages. C’est exactement ce qu’on veut après un import qui a mal tourné, et exactement ce qu’on ne veut pas pour récupérer un seul article supprimé la semaine dernière.

Les deux mécanismes se complètent plutôt qu’ils ne se doublent : la restauration à un instant donné est votre secours des 30 derniers jours, les archives téléchargées sont des copies sans expiration que vous détenez.

Le vidage complet de la base, et le cas Node

L’archive JSON ne couvre pas les comptes. Pour une copie brute et complète de la base, tables d’authentification comprises, passez par l’export de la base :

npx wrangler d1 export ma-base --remote --output=sauvegarde.sql

Sur un déploiement Node, la base est un fichier unique. Copiez-le serveur arrêté, ou à chaud avec sqlite3 emdash.db ".backup sauvegarde.db", qui produit une copie cohérente sans interrompre le service. Si vous êtes sur PostgreSQL, les outils de vidage de PostgreSQL s’appliquent normalement ; les particularités de cette configuration sont traitées dans notre dossier sur EmDash sans Cloudflare.

Il reste un élément que rien de tout cela ne sauvegarde, et sa perte est irréversible : la clé de chiffrement des secrets d’extensions, fournie par vous dans l’environnement et générée avec npx emdash secrets generate. Elle n’est jamais stockée en base — seul le texte chiffré l’est. La perdre, c’est perdre tous les secrets chiffrés avec elle. Rangez-la dans un gestionnaire de mots de passe ou un coffre à secrets, pas dans le dépôt de code.

Restaurer, et pourquoi c’est plus dur que sauvegarder

La restauration d’une archive JSON n’est volontairement pas exposée comme un bouton dans l’administration : écraser une base en service mérite plus de frottement qu’un clic. Aujourd’hui, trois voies existent selon ce que vous voulez récupérer.

Ce que vous voulez récupérer	La voie
L’état de la base il y a quelques heures ou jours (Cloudflare)	Restauration à un instant donné sur D1
Une base complète depuis un vidage SQL	`npx wrangler d1 execute ma-base --remote --file=sauvegarde.sql`
Le contenu depuis une archive JSON	Restauration guidée en ligne de commande prévue, pas encore livrée

Ce dernier point est une limite réelle du produit au 23 août 2026, et il faut la connaître avant d’appuyer sa stratégie sur les seules archives JSON. Le suivi se fait dans la discussion 142 du dépôt du projet.

D’où la règle de conduite : sur Cloudflare, faites de la restauration à un instant donné votre plan principal et des archives votre plan de survie. Sur Node, la copie de base est votre plan principal, et elle doit être testée.

Le test que personne ne fait

Une sauvegarde non restaurée n’est pas une sauvegarde, c’est une intention. Le test tient en trois étapes et se fait une fois, puis à chaque changement d’hébergement.

Montez un environnement séparé : une base D1 distincte, ou une copie du conteneur Node avec son propre fichier de base.
Restaurez-y votre vidage SQL ou votre copie de fichier, puis démarrez le site.
Vérifiez trois choses : la page d’accueil s’affiche, une image s’affiche — c’est le test du stockage, pas celui de la base —, et la connexion à l’administration fonctionne. Ce troisième point échoue si vous avez restauré une archive de contenu sans les tables d’authentification.

Notez le temps que l’opération a pris. C’est votre délai réel de reprise, et c’est le seul chiffre honnête à donner quand on vous demande combien de temps le site resterait indisponible. Le reste de la préparation d’un site en service est traité dans notre dossier sur la mise en production d’EmDash, et la sauvegarde avant montée de version dans le guide de mise à jour d’EmDash.

Questions fréquentes

Une archive EmDash suffit-elle à reconstruire mon site ?

Non, pas seule. Elle contient le contenu, le modèle de contenu et les réglages, mais ni les comptes, ni les secrets, ni les fichiers médias. Une reconstruction complète demande l’archive, une copie du stockage objet et la clé de chiffrement des secrets, conservée à part.

Les sauvegardes automatiques fonctionnent-elles sans configuration supplémentaire ?

Elles s’appuient sur le battement de maintenance planifié du déploiement — le déclencheur cron du Worker sur Cloudflare, l’ordonnanceur intégré sur Node. Si aucun déclencheur planifié n’est configuré, l’interrupteur peut être activé sans qu’aucune archive ne se crée. Vérifiez la présence d’archives dans la liste plutôt que de vous fier à l’interrupteur.

Peut-on restaurer une archive JSON depuis l’administration ?

Pas au 23 août 2026 : la restauration d’archive n’est pas exposée comme une action de l’administration, par choix de conception. Sur Cloudflare, la restauration à un instant donné de D1 remplit ce rôle ; pour un vidage SQL, la commande d’exécution de Wrangler l’importe. Une restauration guidée en ligne de commande est annoncée mais pas livrée.

Où faut-il stocker les archives téléchargées ?

Ailleurs que sur le site lui-même, et ailleurs que sur le seul poste de travail qui les a produites. Le principe est celui de toute sauvegarde : au moins deux emplacements, dont un hors du fournisseur qui héberge le site, pour qu’un incident de compte n’emporte pas les copies avec le site.