Backup e ripristino

Usa un backup JSON quando ti serve una copia offline di dati di contenuto selezionati. EmDash non può importare quel file. Un piano di ripristino richiede un backup grezzo del database o point-in-time recovery e una copia separata dei binari media.

Per copiare contenuto, impostazioni e media di un sito in un nuovo sito EmDash, anche su un database diverso, usa invece un pacchetto sito.

Se il sito memorizza impostazioni plugin cifrate, conserva l’elenco completo di rotazione di EMDASH_ENCRYPTION_KEY in un backup separato del gestore di secret. La chiave non è mai memorizzata nel database, in D1 Time Travel, in un dump SQL o in un export JSON.

Cosa c’è in un backup

Un backup JSON include:

• Tutte le voci di contenuto, inclusi bozze, post programmati ed elementi nel cestino
• Definizioni di collection e campi che formano il modello di contenuto
• Definizioni di tassonomia, termini e i termini assegnati a ciascuna voce
• Menu e voci di menu, sezioni, aree widget e widget, record SEO, cronologia revisioni, metadati media e cronologia delle migrazioni del database
• Impostazioni del sito come titolo, tagline, URL, locale, logo, preferenze di visualizzazione, profili social e impostazioni SEO predefinite. Provengono dal gruppo di impostazioni site: e dalle impostazioni emdash:site_title, emdash:site_tagline e emdash:locale.

Omette tutte le altre tabelle del database, tra cui:

• Account utente, sessioni, passkey, dati OAuth, token API e altri dati di autenticazione
• Storage e impostazioni dei plugin, inclusi i secret dei plugin
• Commenti e reazioni, redirect e log 404, byline, relazioni e riferimenti di contenuto, log di audit, rate limit e stato delle attività programmate
• Cartelle media, record di dove i media sono usati, upload incompleti o in corso, e i file media stessi
• Altre opzioni del sito, incluso l’URL di deployment registrato all’impostazione (emdash:site_url), il secret di firma del preview e la pianificazione dei backup

I backup sono file JSON nello stesso formato di snapshot usato dal sistema di preview di EmDash, versionati con la release EmDash che li ha creati.

Download con un clic

In Settings → Backups nell’admin, il pulsante Download backup genera un backup fresco e lo scarica come file JSON. Richiede il ruolo admin.

Il download serve per ispezione o strumenti personalizzati. Prima di importazioni massive, modifiche allo schema o aggiornamenti importanti, crea un backup ripristinabile del database con una delle opzioni sotto. Per spostare il sito su un altro sito EmDash, esporta un pacchetto sito in Settings → Transfer.

Backup automatici sullo storage

Se il tuo sito ha un backend di storage configurato (R2 su Cloudflare, S3 o storage locale), puoi abilitare i backup automatici giornalieri:

Gli archivi sono memorizzati sotto il prefisso backups/ nel tuo bucket come emdash-backup-<timestamp>-<random>.json. L’elenco Stored Backups nell’admin ti consente di scaricare o eliminare singoli archivi, e Back up now ne crea uno su richiesta.

I backup automatici si appoggiano al tick di manutenzione programmata (lo stesso meccanismo che alimenta la pubblicazione programmata) — su Cloudflare è il trigger cron del Worker, su Node lo scheduler integrato. Se il tuo deployment non ha un trigger cron configurato, usa invece Back up now o il pulsante di download.

Backup e ripristino degli oggetti media

I bucket R2 e compatibili S3 necessitano di un backup a livello oggetto oltre al database. Il seguente esempio AWS CLI copia ogni oggetto, inclusi gli archivi backups/ di EmDash, in una directory di backup locale. Per AWS S3, ometti --endpoint-url.

aws s3 sync s3://emdash-media ./emdash-media-backup \
  --endpoint-url https://<account-id>.r2.cloudflarestorage.com

Usa credenziali di bucket in sola lettura per i job di backup di routine. Conserva il backup fuori dall’account di produzione o dal dominio di guasto, e registra il backup del database o il punto Time Travel creato nello stesso momento.

Ripristina in un bucket di recovery vuoto invece di sovrascrivere la produzione mentre serve richieste:

aws s3 sync ./emdash-media-backup s3://emdash-media-recovery \
  --endpoint-url https://<account-id>.r2.cloudflarestorage.com

Dai al job di ripristino accesso in scrittura solo al bucket di recovery. Punta un deployment non di produzione a quel bucket, apri diverse URL media note e carica ed elimina un file usa e getta. Cambia il binding o la configurazione del bucket di produzione solo dopo che il database e l’insieme media ripristinati hanno superato insieme i controlli.

Recuperare un database D1 con Time Travel

Prima di un’operazione rischiosa, chiedi a Time Travel il bookmark corrente e registralo con il deployment o il record della modifica:

npx wrangler d1 time-travel info my-database

Se è richiesto il recupero, interrompi le scritture sul sito e ispeziona il punto di ripristino disponibile prima di eseguire il comando di ripristino distruttivo:

npx wrangler d1 time-travel restore my-database --timestamp=2026-07-08T13:00:00Z

Time Travel ripristina l’intero database, inclusi contenuto, utenti, impostazioni, dati dei plugin e record di migrazione. Non ripristina oggetti media R2 né EMDASH_ENCRYPTION_KEY. Prima di testare le integrazioni dei plugin, ripristina ogni chiave di cifratura referenziata dalle impostazioni plugin recuperate. Dopo il completamento del comando, distribuisci la versione dell’applicazione che corrisponde al database ripristinato, riapri il traffico e verifica accesso, letture di contenuto, modifiche allo schema, un’impostazione plugin cifrata e una scrittura.

Vedi la documentazione D1 Time Travel per i dettagli.

Creare un dump D1 offsite

Per un dump SQL completo del database grezzo (incluse tabelle utenti e auth), usa Wrangler:

npx wrangler d1 export my-database --remote --output=backup.sql

Conserva il file SQL con la versione corrispondente dell’applicazione, il backup media creato nello stesso momento e una copia memorizzata separatamente dell’elenco di rotazione di EMDASH_ENCRYPTION_KEY. Testa il ripristino importando il dump in un database D1 vuoto appena provisionato, ripristinando le chiavi di runtime, aggiornando un binding non di produzione a quel database e verificando il sito.

Importa nel database di recovery vuoto con il seguente comando:

npx wrangler d1 execute my-recovery-database --remote --file=backup.sql

Backup e ripristino SQLite

Per un backup SQLite offline, ferma ogni processo che scrive il database e copia il file del database insieme a eventuali file -wal e -shm accanto. Il file -wal può contenere modifiche confermate non ancora nel file principale. Per un backup online coerente, usa il comando di backup di SQLite:

sqlite3 emdash.db ".backup backup.db"

Esegui il backup separatamente della directory di upload locale o del bucket compatibile S3 e dell’elenco di rotazione di EMDASH_ENCRYPTION_KEY. Per recuperare, ferma ogni processo server, conserva una copia del database danneggiato, sostituiscilo con il backup verificato, ripristina le chiavi di runtime e eventuali oggetti media richiesti, e avvia la versione corrispondente dell’applicazione. Verifica accesso, contenuto pubblico, un’impostazione plugin cifrata, una modifica e una lettura media prima di riaprire il traffico.

Gli export JSON non possono ripristinare un sito

EmDash non ha azione admin, endpoint API né comando CLI per il ripristino JSON. Usa D1 Time Travel, un dump SQL D1 grezzo o una copia del database SQLite come descritto sopra.

Per ricostruire il contenuto di un sito in un nuovo sito EmDash vuoto, esporta un pacchetto sito dal sito originale mentre è ancora disponibile e importalo nel nuovo sito. Un pacchetto sito non ripristina utenti, token API, dati dei plugin né secret, quindi non sostituisce un backup del database per il disaster recovery.