Resposta rápida
Se um banco Cloudflare D1 foi apagado, envie imediatamente uma requisição POST para /accounts/ACCOUNT_ID/d1/database/DATABASE_ID/undelete usando o UUID original do banco e um API Token com o menor escopo necessário. Desde 23 de outubro de 2026, a API só aceita bancos excluídos nas últimas 168 horas, equivalentes a sete dias. Depois desse prazo, o pedido falha.
Não use Time Travel para tentar trazer de volta um banco que já foi excluído. Primeiro faça o undelete. Se o nome original já pertence a outro banco, envie new_name no corpo da requisição. Após recuperar, confirme o banco, as tabelas, uma amostra de dados e todos os bindings antes de reabrir gravações da aplicação.
Primeiro confirme o que foi apagado
Separe exclusão do banco de uma exclusão de linhas. Se o banco ainda aparece no painel e a aplicação perdeu registros por DELETE, UPDATE, migração ou importação incorreta, o caminho aplicável é Time Travel. Se o banco inteiro desapareceu após uma operação de exclusão, use o endpoint de undelete.
Registre o horário aproximado, o account ID, o UUID do banco, o nome anterior e os ambientes que apontavam para ele. O UUID é indispensável. Procure-o no wrangler.toml ou wrangler.jsonc, em configurações de deploy, inventários, logs de auditoria e registros de infraestrutura. Não crie imediatamente outro banco com o mesmo nome sem preservar essas evidências.
- Pause deploys, migrações, jobs e gravações que possam aumentar a inconsistência.
- Confirme se o banco sumiu ou se apenas os dados mudaram.
- Recupere o database_id original sem publicar tokens, dumps ou conteúdo sensível.
- Calcule o prazo a partir do momento real da exclusão e não espere o sétimo dia.
- Consulte o Cloudflare Status para separar incidente amplo de uma exclusão administrativa.
Como enviar o pedido de undelete
A documentação oficial expõe o endpoint POST /accounts/{account_id}/d1/database/{database_id}/undelete. Prefira um API Token ao Global API key, use HTTPS e evite salvar o segredo em histórico, ticket ou log. A resposta devolve os detalhes do banco restaurado; registre o resultado sem registrar o cabeçalho Authorization.
Se não existe conflito de nome, envie um objeto JSON vazio. Se outro banco já usa o nome anterior, inclua um novo nome, por exemplo {"new_name":"restored-db"}. O banco recuperado volta a contar nos limites da conta, portanto confirme capacidade antes do pedido quando a conta estiver próxima da cota.
- Crie ou selecione um API Token com acesso somente à conta e ao D1 necessários.
- Envie POST para https://api.cloudflare.com/client/v4/accounts/ACCOUNT_ID/d1/database/DATABASE_ID/undelete.
- Adicione Authorization: Bearer API_TOKEN e Content-Type: application/json nos cabeçalhos.
- Use {} no corpo ou {"new_name":"restored-db"} quando houver conflito de nome.
- Guarde o código HTTP, success, errors, messages e os metadados retornados, sempre sem o token.
Limite importante do Time Travel depois do undelete
Depois que o banco é recuperado, o Time Travel não consegue restaurá-lo para um bookmark ou horário anterior ou igual ao momento do undelete. Na prática, recuperar o contêiner do banco não abre acesso aos estados de Time Travel anteriores à recuperação. Essa restrição está na própria referência da API.
Time Travel continua útil para um banco que não foi excluído e sofreu uma alteração acidental. Nesse caso, obtenha um bookmark com wrangler d1 time-travel info NOME_DO_BANCO e só execute a restauração depois de confirmar o horário. O restore altera o banco existente no lugar e cancela consultas em andamento, por isso exija janela de mudança, validação e plano de recuperação.
Como validar o banco recuperado
Não considere o caso encerrado apenas porque a API respondeu success. Liste os bancos, consulte os metadados do recuperado e compare o identificador esperado. Depois faça consultas somente de leitura para verificar esquema, tabelas críticas, contagens aproximadas e alguns registros conhecidos. Não use dados pessoais em capturas ou relatórios de validação.
Revise cada binding de Worker, Pages, ambiente de preview e produção. Um nome restaurado não prova que a aplicação está apontando para o database ID correto. Reabra o tráfego em etapas e acompanhe erros de consulta, latência, filas, cron jobs e divergências de leitura antes de liberar gravações em massa.
- Execute npx wrangler d1 list --json e localize o banco recuperado.
- Rode npx wrangler d1 info NOME_DO_BANCO e confirme nome, UUID e região esperados.
- Consulte sqlite_schema e uma amostra somente de leitura das tabelas críticas.
- Compare os bindings do projeto com o database_id retornado pela API.
- Reative primeiro leituras e health checks; só depois retome jobs e escritas.
O que fazer se o prazo de sete dias acabou
Pedidos enviados mais de sete dias depois da exclusão são rejeitados pela API oficial. A documentação não promete exceção por plano ou intervenção de suporte. Abra um caso apenas para esclarecer o incidente, sem tratar isso como estratégia de restauração e sem adiar a reconstrução a partir de uma cópia externa já existente.
Se você possui um export SQL válido, crie um banco novo e importe o arquivo com Wrangler. Verifique antes as limitações de tamanho, tabelas virtuais, precisão numérica e chaves estrangeiras documentadas pela Cloudflare. Um export em andamento bloqueia outras requisições, portanto futuros backups também precisam de janela e monitoramento.
Como evitar que a próxima exclusão vire perda permanente
Time Travel oferece retenção de até 30 dias no Workers Paid e sete dias no Workers Free, mas não substitui uma cópia independente e não recupera o histórico anterior ao undelete. Para retenção maior, a Cloudflare documenta exportações automáticas do D1 para R2 por REST API e Workflows. Teste periodicamente a importação em um banco descartável, pois um arquivo que nunca foi restaurado é apenas uma hipótese de backup.
Restrinja a permissão de exclusão, mantenha database ID e ambiente em inventário seguro e exija confirmação humana fora dos scripts administrativos rotineiros. Não use --skip-confirmation em tarefas comuns. Registre exclusões e alterações de binding no audit log e tenha um procedimento que comece por pausar gravações, localizar o UUID e enviar undelete.
Limitações e próxima ação útil
Este guia foi verificado em 25 de outubro de 2026. O prazo de sete dias, o endpoint e a restrição de Time Travel refletem a documentação oficial disponível nesta data. Planos, limites, comandos e comportamento da API podem mudar. A página de status confirma incidentes amplos, mas não comprova a integridade do banco restaurado ou dos bindings privados.
A próxima ação é localizar agora o database ID e o horário da exclusão. Se ainda estiver dentro das 168 horas, pause gravações, envie o undelete, valide tabelas e bindings e só então reabra o tráfego. Se o prazo venceu, pare de repetir a API e inicie uma restauração controlada a partir do export externo mais recente que já exista.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- D1 database undelete requests limited to the last 7 daysCloudflare Changelog
- Undelete D1 DatabaseCloudflare API
- Time Travel and backupsCloudflare Docs
- D1 limitsCloudflare Docs
- Wrangler commandsCloudflare Docs
- Import and export dataCloudflare Docs
- Cloudflare StatusCloudflare