Sauvegardes et récupération

Utilisez une sauvegarde JSON lorsque 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 la base de données ou une récupération point-in-time et une copie séparée des binaires multimédias.

Pour copier le contenu, les paramètres et les médias d’un site vers un nouveau site EmDash, y compris sur une autre base de données, utilisez plutôt un paquet de site.

Si le site stocke des paramètres de plugin chiffrés, conservez la liste complète de rotation de EMDASH_ENCRYPTION_KEY dans une sauvegarde séparée du gestionnaire de secrets. La clé n’est jamais stockée dans la base de données, D1 Time Travel, un dump SQL ou une exportation JSON.

Contenu d’une sauvegarde

Une sauvegarde JSON inclut :

• Toutes les entrées de contenu, y compris les brouillons, les publications planifiées et les éléments à la corbeille
• Les définitions de collection et de champs qui constituent le modèle de contenu
• Les définitions de taxonomie, les termes et les termes assignés à chaque entrée
• Les menus et éléments de menu, sections, zones de widgets et widgets, enregistrements SEO, historique des révisions, métadonnées multimédias et historique des migrations de base de données
• Les paramètres du site tels que le titre, le slogan, l’URL, la locale, le logo, les préférences d’affichage, les profils sociaux et les valeurs SEO par défaut. Ils proviennent du groupe de paramètres site: et des paramètres emdash:site_title, emdash:site_tagline et emdash:locale.

Elle omet toutes les autres tables de la base de données, notamment :

• Les comptes utilisateur, sessions, passkeys, données OAuth, jetons d’API et autres données d’authentification
• Le stockage et les paramètres des plugins, y compris les secrets de plugins
• Les commentaires et réactions, redirections et journaux 404, bylines, relations et références de contenu, journaux d’audit, limites de débit et état des tâches planifiées
• Les dossiers multimédias, les enregistrements d’utilisation des médias, les uploads incomplets ou en cours, et les fichiers multimédias eux-mêmes
• Les autres options du site, y compris l’URL de déploiement enregistrée à la configuration (emdash:site_url), le secret de signature de preview et le planning de sauvegarde

Les sauvegardes sont des fichiers JSON au même format de snapshot que le système de preview d’EmDash, versionnés avec la version EmDash qui les a créés.

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. Nécessite le rôle admin.

Le téléchargement sert à l’inspection ou à des outils personnalisés. Avant les imports en masse, les changements de schéma ou les mises à niveau majeures, créez une sauvegarde de base de données restaurable avec l’une des options ci-dessous. Pour déplacer le site vers un autre site EmDash, exportez un paquet de site sous Settings → Transfer.

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 automatiques quotidiennes :

Les archives sont stockées sous le préfixe backups/ dans votre bucket comme 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 planifiée (le même mécanisme qui alimente la publication planifiée) — sur Cloudflare c’est le déclencheur cron du Worker, sous Node le planificateur intégré. Si votre déploiement n’a pas de déclencheur cron configuré, utilisez plutôt Back up now ou le bouton de téléchargement.

Sauvegarder et restaurer les objets multimédias

Les buckets R2 et compatibles S3 ont besoin d’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, vers 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 jobs de sauvegarde de routine. Stockez la sauvegarde hors du compte de production ou du domaine de défaillance, et notez la sauvegarde de base de données ou le point Time Travel créé au même moment.

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 job 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 URL multimédias connues, et téléversez puis supprimez un fichier jetable. Ne changez le binding ou la configuration du bucket de production qu’après que la base de données et l’ensemble multimédia restaurés aient passé leurs contrôles ensemble.

Récupérer une base de données D1 avec Time Travel

Avant une opération risquée, demandez à Time Travel le bookmark actuel et enregistrez-le avec le déploiement ou le journal de changement :

npx wrangler d1 time-travel info my-database

Si une récupération est requise, arrêtez les écritures sur 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 multimédias R2 ni EMDASH_ENCRYPTION_KEY. Avant de tester les intégrations de plugins, restaurez chaque clé de chiffrement référencée par les paramètres de plugin récupérés. Après la fin de la commande, 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, un paramètre de plugin chiffré 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, la sauvegarde multimédia créée au même moment, et une copie stockée séparément de la liste de rotation de EMDASH_ENCRYPTION_KEY. Testez la récupération en important le dump dans une base D1 vide nouvellement provisionnée, en restaurant les clés d’exécution, en mettant à jour un binding hors production vers cette base, et en vérifiant le site.

Importez dans la base 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 tout processus qui écrit la base de données et copiez le fichier de base avec tous les fichiers -wal et -shm à côté. Le fichier -wal peut contenir des changements validés qui ne sont pas encore dans le fichier principal. Pour une sauvegarde en ligne cohérente, utilisez la commande de sauvegarde de SQLite :

sqlite3 emdash.db ".backup backup.db"

Sauvegardez séparément le répertoire local d’upload ou le bucket compatible S3 et la liste de rotation de EMDASH_ENCRYPTION_KEY. Pour récupérer, arrêtez tout processus serveur, conservez une copie de la base endommagée, remplacez-la par la sauvegarde vérifiée, restaurez les clés d’exécution et tout objet multimédia requis, et démarrez la version d’application correspondante. Vérifiez la connexion, le contenu public, un paramètre de plugin chiffré, une édition et une lecture multimédia avant de rouvrir le trafic.

Les exportations JSON ne peuvent pas restaurer un site

EmDash n’a aucune action admin, endpoint d’API ni commande CLI pour la restauration JSON. Utilisez D1 Time Travel, un dump SQL D1 brut ou une copie de la base SQLite comme décrit ci-dessus.

Pour reconstruire le contenu d’un site dans un nouveau site EmDash vide, exportez un paquet de site depuis le site d’origine tant qu’il est encore disponible et importez-le dans le nouveau site. Un paquet de site ne restaure pas les utilisateurs, jetons d’API, données de plugins ni secrets, et ne remplace donc pas une sauvegarde de base de données pour la reprise après sinistre.