Utilisez une sauvegarde JSON quand vous avez besoin d’une copie hors ligne de données de contenu sélectionnées. EmDash ne peut pas importer ce fichier. Un plan de récupération nécessite une sauvegarde brute de base de données ou une récupération à un point dans le temps et une copie séparée des binaires médias.
Ce que contient une sauvegarde
Une sauvegarde JSON inclut :
- Toutes les entrées de contenu, y compris les brouillons, publications programmées et éléments supprimés
- Les définitions de collections et de champs qui composent le modèle de contenu
- Les définitions de taxonomie, termes et les termes assignés à chaque entrée
- Menus et éléments de menu, sections, zones de widgets et widgets, enregistrements SEO, historique des révisions, métadonnées médias et historique des migrations de base de données
- Paramètres du site comme le titre, slogan, URL, locale, logo, préférences d’affichage, profils sociaux et valeurs SEO par défaut. Ceux-ci proviennent des groupes de paramètres
site:,emdash:site_etemdash:locale.
Elle omet toutes les autres tables de la base de données, y compris :
- Comptes utilisateur, sessions, passkeys, données OAuth, tokens API et autres données d’authentification
- Stockage de plugins et paramètres de plugins, y compris les secrets de plugins
- Commentaires et réactions, redirections et logs 404, signatures d’auteurs, relations et références de contenu, logs d’audit, limites de débit et état des tâches programmées
- Dossiers médias, enregistrements d’où les médias sont utilisés, uploads incomplets ou en cours et les fichiers médias eux-mêmes
- Autres options du site, y compris le secret de signature de prévisualisation et le programme de sauvegarde
Les sauvegardes sont des fichiers JSON dans le même format de snapshot utilisé par le système de prévisualisation d’EmDash, versionnés avec la version d’EmDash qui les a créées.
Téléchargement en un clic
Sous Settings → Backups dans l’admin, le bouton Download backup génère une sauvegarde fraîche et la télécharge en fichier JSON. Requiert le rôle admin.
Le téléchargement est destiné à l’inspection ou aux outils de migration personnalisés. Avant des imports en masse, des changements de schéma ou des mises à jour majeures, créez une sauvegarde restaurable de base de données en utilisant l’une des options ci-dessous.
Sauvegardes automatiques vers le stockage
Si votre site a un backend de stockage configuré (R2 sur Cloudflare, S3 ou stockage local), vous pouvez activer les sauvegardes quotidiennes automatiques :
-
Ouvrez Settings → Backups dans l’admin.
-
Activez Daily automatic backups.
-
Choisissez combien de sauvegardes conserver (1–30). Les archives plus anciennes sont purgées automatiquement.
-
Enregistrez. Les sauvegardes s’exécutent dans le cadre de la maintenance programmée d’EmDash — pas besoin de configuration cron supplémentaire.
Les archives sont stockées sous le préfixe backups/ dans votre bucket sous la forme emdash-backup-<timestamp>-<random>.json. La liste Stored Backups dans l’admin vous permet de télécharger ou supprimer des archives individuelles, et Back up now en crée une à la demande.
Les sauvegardes automatiques s’appuient sur le tick de maintenance programmée (le même mécanisme qui alimente la publication programmée) — sur Cloudflare c’est le cron trigger du Worker, sur Node le scheduler intégré. Si votre déploiement n’a pas de cron trigger configuré, utilisez Back up now ou le bouton de téléchargement à la place.
Sauvegarder et restaurer les objets médias
Les buckets R2 et compatibles S3 nécessitent une sauvegarde au niveau objet en plus de la base de données. L’exemple AWS CLI suivant copie chaque objet, y compris les archives backups/ d’EmDash, dans un répertoire de sauvegarde local. Pour AWS S3, omettez --endpoint-url.
aws s3 sync s3://emdash-media ./emdash-media-backup \
--endpoint-url https://<account-id>.r2.cloudflarestorage.com
Utilisez des identifiants de bucket en lecture seule pour les tâches de sauvegarde routinières. Stockez la sauvegarde en dehors du compte de production ou du domaine de défaillance, et enregistrez la sauvegarde de base de données ou le point Time Travel créé en même temps.
Restaurez dans un bucket de récupération vide plutôt que d’écraser la production pendant qu’elle sert des requêtes :
aws s3 sync ./emdash-media-backup s3://emdash-media-recovery \
--endpoint-url https://<account-id>.r2.cloudflarestorage.com
Donnez au travail de restauration un accès en écriture uniquement au bucket de récupération. Pointez un déploiement hors production vers ce bucket, ouvrez plusieurs URLs de médias connus, et téléchargez et supprimez un fichier jetable. Changez le binding de production ou la configuration du bucket uniquement après que la base de données restaurée et l’ensemble de médias aient passé leurs vérifications ensemble.
Récupérer une base de données D1 avec Time Travel
Avant une opération risquée, demandez à Time Travel le signet actuel et enregistrez-le avec le déploiement ou l’enregistrement de changement :
npx wrangler d1 time-travel info my-database
Si une récupération est nécessaire, arrêtez les écritures vers le site et inspectez le point de restauration disponible avant d’exécuter la commande de restauration destructive :
npx wrangler d1 time-travel restore my-database --timestamp=2026-07-08T13:00:00Z
Time Travel restaure toute la base de données, y compris le contenu, les utilisateurs, les paramètres, les données de plugins et les enregistrements de migration. Il ne restaure pas les objets médias R2. Une fois la commande terminée, déployez la version de l’application qui correspond à la base de données restaurée, rouvrez le trafic et vérifiez la connexion, les lectures de contenu, les changements de schéma et une écriture.
Voir la documentation D1 Time Travel pour les détails.
Créer un dump D1 hors site
Pour un dump SQL complet de la base de données brute (y compris les tables utilisateurs et auth), utilisez Wrangler :
npx wrangler d1 export my-database --remote --output=backup.sql
Conservez le fichier SQL avec la version d’application correspondante et la sauvegarde média créée en même temps. Testez la récupération en important le dump dans une base de données D1 vide nouvellement provisionnée, en mettant à jour un binding hors production vers cette base de données et en vérifiant le site.
Importez dans la base de données de récupération vide avec la commande suivante :
npx wrangler d1 execute my-recovery-database --remote --file=backup.sql
Sauvegarde et récupération SQLite
Pour une sauvegarde SQLite hors ligne, arrêtez tous les processus qui écrivent dans la base de données et copiez le fichier de base de données. Pour une sauvegarde en ligne cohérente, utilisez la commande de sauvegarde de SQLite :
sqlite3 emdash.db ".backup backup.db"
Sauvegardez le répertoire d’upload local ou le bucket compatible S3 séparément. Pour récupérer, arrêtez tous les processus serveur, conservez une copie de la base de données endommagée, remplacez-la par la sauvegarde vérifiée, restaurez tous les objets médias nécessaires et démarrez la version d’application correspondante. Vérifiez la connexion, le contenu public, une modification et une lecture média avant de rouvrir le trafic.
Les exportations JSON ne peuvent pas restaurer un site
EmDash n’a pas d’action admin, d’endpoint API ni de commande CLI pour la restauration JSON. Utilisez D1 Time Travel, un dump SQL brut D1 ou une copie de la base de données SQLite comme décrit ci-dessus.