Use um backup JSON quando precisar de uma cópia offline de dados de conteúdo selecionados. O EmDash não pode importar esse arquivo. Um plano de recuperação precisa de um backup bruto do banco de dados ou recuperação point-in-time e uma cópia separada dos binários de mídia.
O que está em um backup
Um backup JSON inclui:
- Todas as entradas de conteúdo, incluindo rascunhos, posts agendados e itens excluídos
- Definições de coleções e campos que compõem o modelo de conteúdo
- Definições de taxonomia, termos e os termos atribuídos a cada entrada
- Menus e itens de menu, seções, áreas de widgets e widgets, registros SEO, histórico de revisões, metadados de mídia e histórico de migração do banco de dados
- Configurações do site como título, slogan, URL, locale, logo, preferências de exibição, perfis sociais e padrões de SEO. Estes vêm dos grupos de configuração
site:,emdash:site_eemdash:locale.
Omite todas as outras tabelas do banco de dados, incluindo:
- Contas de usuário, sessões, passkeys, dados OAuth, tokens de API e outros dados de autenticação
- Armazenamento de plugins e configurações de plugins, incluindo segredos de plugins
- Comentários e reações, redirecionamentos e logs 404, assinaturas de autor, relações e referências de conteúdo, logs de auditoria, limites de taxa e estado de tarefas agendadas
- Pastas de mídia, registros de onde a mídia é usada, uploads incompletos ou em andamento e os arquivos de mídia em si
- Outras opções do site, incluindo o segredo de assinatura de preview e o cronograma de backup
Backups são arquivos JSON no mesmo formato de snapshot usado pelo sistema de preview do EmDash, versionados com a release do EmDash que os criou.
Download com um clique
Em Settings → Backups no admin, o botão Download backup gera um backup fresco e o baixa como arquivo JSON. Requer o papel de admin.
O download é para inspeção ou ferramentas de migração personalizadas. Antes de importações em massa, mudanças de esquema ou upgrades maiores, crie um backup restaurável do banco de dados usando uma das opções abaixo.
Backups automáticos para o armazenamento
Se seu site tem um backend de armazenamento configurado (R2 no Cloudflare, S3 ou armazenamento local), você pode habilitar backups diários automáticos:
-
Abra Settings → Backups no admin.
-
Ative Daily automatic backups.
-
Escolha quantos backups manter (1–30). Arquivos mais antigos são removidos automaticamente.
-
Salve. Backups rodam como parte da manutenção agendada do EmDash — não é necessária configuração cron adicional.
Arquivos são armazenados sob o prefixo backups/ no seu bucket como emdash-backup-<timestamp>-<random>.json. A lista Stored Backups no admin permite baixar ou excluir arquivos individuais, e Back up now cria um sob demanda.
Backups automáticos aproveitam o tick de manutenção agendada (o mesmo mecanismo que alimenta a publicação agendada) — no Cloudflare é o cron trigger do Worker, no Node o scheduler embutido. Se seu deployment não tem cron trigger configurado, use Back up now ou o botão de download.
Fazer backup e restaurar objetos de mídia
Buckets R2 e compatíveis com S3 precisam de um backup em nível de objeto além do banco de dados. O exemplo AWS CLI a seguir copia cada objeto, incluindo os arquivos backups/ do EmDash, para um diretório de backup local. Para AWS S3, omita --endpoint-url.
aws s3 sync s3://emdash-media ./emdash-media-backup \
--endpoint-url https://<account-id>.r2.cloudflarestorage.comUse credenciais de bucket somente leitura para jobs de backup rotineiros. Armazene o backup fora da conta de produção ou domínio de falha, e registre o backup do banco de dados ou ponto Time Travel criado ao mesmo tempo.
Restaure em um bucket de recuperação vazio em vez de sobrescrever a produção enquanto ela está servindo requisições:
aws s3 sync ./emdash-media-backup s3://emdash-media-recovery \
--endpoint-url https://<account-id>.r2.cloudflarestorage.comDê ao job de restauração acesso de escrita apenas ao bucket de recuperação. Aponte um deployment não-produção para esse bucket, abra várias URLs de mídia conhecidas e faça upload e exclua um arquivo descartável. Troque o binding de produção ou a configuração do bucket somente depois que o banco de dados restaurado e o conjunto de mídia passem suas verificações juntos.
Recuperar um banco de dados D1 com Time Travel
Antes de uma operação arriscada, peça ao Time Travel o bookmark atual e registre-o com o deployment ou registro de mudança:
npx wrangler d1 time-travel info my-databaseSe a recuperação for necessária, pare as escritas no site e inspecione o ponto de restauração disponível antes de executar o comando de restauração destrutivo:
npx wrangler d1 time-travel restore my-database --timestamp=2026-07-08T13:00:00ZTime Travel restaura todo o banco de dados, incluindo conteúdo, usuários, configurações, dados de plugins e registros de migração. Não restaura objetos de mídia R2. Após o comando ser concluído, faça deploy da versão da aplicação que corresponde ao banco de dados restaurado, reabra o tráfego e verifique login, leituras de conteúdo, mudanças de esquema e uma escrita.
Veja a documentação do D1 Time Travel para detalhes.
Criar um dump D1 offsite
Para um dump SQL completo do banco de dados bruto (incluindo tabelas de usuários e auth), use o Wrangler:
npx wrangler d1 export my-database --remote --output=backup.sqlGuarde o arquivo SQL com a versão da aplicação correspondente e o backup de mídia criado ao mesmo tempo. Teste a recuperação importando o dump em um banco de dados D1 vazio recém-provisionado, atualizando um binding não-produção para esse banco de dados e verificando o site.
Importe no banco de dados de recuperação vazio com o seguinte comando:
npx wrangler d1 execute my-recovery-database --remote --file=backup.sqlBackup e recuperação SQLite
Para um backup SQLite offline, pare todos os processos que escrevem no banco de dados e copie o arquivo do banco de dados. Para um backup online consistente, use o comando de backup do SQLite:
sqlite3 emdash.db ".backup backup.db"Faça backup do diretório de upload local ou bucket compatível com S3 separadamente. Para recuperar, pare todos os processos do servidor, mantenha uma cópia do banco de dados danificado, substitua-o pelo backup verificado, restaure quaisquer objetos de mídia necessários e inicie a versão da aplicação correspondente. Verifique login, conteúdo público, uma edição e uma leitura de mídia antes de reabrir o tráfego.
Exportações JSON não podem restaurar um site
O EmDash não tem ação de admin, endpoint de API ou comando CLI para restauração JSON. Use D1 Time Travel, um dump SQL bruto D1 ou uma cópia do banco de dados SQLite como descrito acima.