Introdução
Um ticket desaparece após uma exclusão acidental por SQL, mas a configuração da aplicação continua correta. Você vai capturar um bookmark do D1 Time Travel, reproduzir a perda usando um único registro sintético e restaurar o mesmo banco de dados, preservando um ticket que não foi afetado.
Este exercício independente de recuperação usa um banco de dados remoto descartável e um Worker fornecido, somente para leitura. Você vai verificar o estado ausente antes da restauração e verificar o acesso da aplicação depois dela.
Use sua própria conta de aprendizado e uma VM nova. A configuração prepara o Node.js 22.22.0 e depois executa npm install para instalar o Wrangler 4.131.1 local ao projeto e quaisquer dependências da avaliação em /home/labex/project/ticket-database. As versões das dependências diretas estão fixadas; a instalação cria seu próprio lockfile. A configuração não faz login na nuvem nem executa operações avaliadas no banco de dados. Em uma máquina pessoal, instale a mesma versão do Wrangler com npm install --save-dev wrangler@4.131.1 no seu projeto.
Este exercício usa registros sintéticos pequenos dentro das franquias gratuitas do D1. O uso existente da conta conta para essas franquias. Não é necessário ter um domínio comprado. Mantenha esta VM até verificar a exclusão dos recursos e o logout.
Autorizar esta VM e selecionar a conta
Nesta etapa, você conecta este terminal novo à sua própria conta de aprendizado. Fazer login no Dashboard, por si só, não autoriza a VM. A permissão do D1 permite criar, alterar e excluir bancos de dados; a permissão do Workers permite fazer deploy; e a permissão do KV dá suporte ao inventário de limpeza do Wrangler. Revise a página de consentimento real, incluindo Background Access, antes de autorizar.
Abra o projeto preparado e verifique a CLI fixada:
cd /home/labex/project/ticket-database
npx wrangler --version
O resultado esperado é 4.131.1. Inicie a autorização por dispositivo; --device exibe um código para o navegador, e --browser=false deixa a escolha do navegador por sua conta:
npx wrangler login --device --browser=false --scopes account:read user:read d1:write workers_scripts:write workers_kv:write
Abra a URL exibida no navegador, informe o código atual, confirme sua conta de aprendizado e as permissões e autorize. Aguarde a confirmação de sucesso no terminal. Nunca cole senhas ou tokens em arquivos do projeto.
npx wrangler whoami --json
Verifique loggedIn: true e leia o name e o id da conta, mesmo que apenas uma conta seja listada. Copie o ID pretendido para a configuração abaixo. A variável de shell a seguir usa 6 bytes aleatórios, ou 12 caracteres hexadecimais, para evitar colisões com outros alunos. Um here-document grava o JSON entre as linhas JSON; $RUN é expandida dentro dele.
A barra invertida antes de $schema mantém essa chave JSON literal; $RUN continua sendo expandido para o nome único desta execução.
RUN=labex-c04-d07-$(openssl rand -hex 6)
cat > wrangler.jsonc <<JSON
{
"\$schema": "./node_modules/wrangler/config-schema.json",
"name": "$RUN",
"account_id": "YOUR_ACCOUNT_ID",
"main": "src/index.js",
"compatibility_date": "2026-09-15",
"workers_dev": true,
"preview_urls": false
}
JSON
Substitua YOUR_ACCOUNT_ID antes de executar o bloco. Mantenha este terminal aberto para que RUN continue disponível. name identifica esta execução; account_id seleciona a conta para as operações na nuvem. O arquivo é um JSON comum, que também é um JSONC válido. Escrevê-lo não faz deploy de nenhum Worker.
Estabelecer um ponto de restauração conhecido
Nesta etapa, você cria o banco de dados descartável e uma API de tickets fornecida, somente para leitura. O Time Travel restaura o estado anterior de um banco de dados no próprio local. Ele não cria um banco de dados substituto e pode sobrescrever alterações feitas depois do ponto escolhido. Use-o aqui somente no recurso novo criado para o laboratório.
Crie um banco de dados descartável na nuvem. --binding DB fornece um nome curto para o código da aplicação, --update-config registra o nome real e o UUID em wrangler.jsonc, e --use-remote=false mantém o desenvolvimento local:
npx wrangler d1 create "$RUN-db" --binding DB --update-config --use-remote=false
Leia o nome e o ID criados e depois verifique a vinculação salva:
cat wrangler.jsonc
A entrada DB deve indicar o banco de dados desta execução. Uma vinculação é uma conexão configurada entre o código e um recurso. O UUID identifica o banco de dados na nuvem, enquanto --local usa um banco SQLite separado nesta VM. Sempre inclua --local ou --remote nos comandos SQL.
npx wrangler d1 execute DB --remote --file schema.sql
npx wrangler deploy
Copie a URL do deploy e leia os dois tickets sintéticos:
URL='YOUR_DEPLOYED_HTTPS_URL'
curl -i "$URL/tickets/1"
curl -i "$URL/tickets/2"
Espere o status 200 para o ticket 1 (Cannot sign in, aberto) e para o ticket 2 (Invoice copy, fechado). Se o deploy ainda estiver sendo propagado, repita essas leituras por até um minuto, até que o status e o JSON estejam de acordo.
Verifique as informações do banco de dados e salve o bookmark atual como artefato de recuperação. Um bookmark é uma posição opaca no histórico do banco de dados. O redirecionamento com > grava a resposta JSON no arquivo indicado:
npx wrangler d1 info DB
npx wrangler d1 time-travel info DB --json > recovery.json
cat recovery.json
Verifique se o banco de dados usa o backend de produção e se recovery.json contém um bookmark não vazio. Mantenha este arquivo inalterado durante todo o exercício. O Time Travel está sempre ativado para o D1 de produção; o plano Free mantém os dados por 7 dias e o Paid por 30 dias. Esta recuperação na mesma sessão precisa apenas de alguns minutos de histórico. Uma linha de ajuda da CLI mencionando 30 dias não substitui a retenção do seu plano.
Reproduzir uma exclusão acidental controlada
Nesta etapa, você remove somente o ticket sintético 1 deste banco de dados do laboratório e comprova o sintoma na aplicação. Primeiro, verifique wrangler.jsonc e confirme que DB corresponde ao nome e ao UUID que você acabou de criar. Não execute isso em um banco de dados de uma aplicação existente.
cat wrangler.jsonc
npx wrangler d1 execute DB --remote --command "DELETE FROM tickets WHERE id = 1;"
Leia a API e o registro que não foi afetado:
curl -i "$URL/tickets/1"
curl -i "$URL/tickets/2"
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
O ticket 1 deve retornar 404 com {"error":"not_found"}. O ticket 2 ainda deve retornar sua resposta 200 original; a consulta SQL deve conter somente o ticket 2. Uma falha de rede ou uma página 404 da plataforma não comprova que a exclusão ocorreu.
Conclua a verificação desta etapa antes de restaurar. Ela verifica o estado real da linha ausente; restaurar sem observar a falha faria você ignorar as evidências do incidente.
Restaurar o histórico e verificar o acesso da aplicação
Nesta etapa, você restaura o mesmo banco de dados usando o bookmark salvo. Leia recovery.json, copie a string bookmark exata para BOOKMARK e verifique novamente a identidade do banco de dados configurado:
cat recovery.json
BOOKMARK='YOUR_SAVED_BOOKMARK'
cat wrangler.jsonc
npx wrangler d1 time-travel restore DB --bookmark "$BOOKMARK"
O comando avisa que sobrescreverá os dados e cancelará as consultas em andamento. Confirme somente este banco de dados descartável. Espere uma mensagem de sucesso da restauração e um bookmark de desfazer. Não recrie o banco de dados, não reimporte o esquema nem insira a linha ausente: essas ações ignorariam a técnica de recuperação.
Consulte o banco de dados restaurado e a vinculação existente da aplicação:
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
curl -i "$URL/tickets/1"
curl -i "$URL/tickets/2"
As duas linhas originais e as duas respostas da API devem retornar. O Worker ainda aponta para o mesmo UUID e não precisa de uma nova vinculação. Se uma leitura ficar temporariamente indisponível durante a restauração, repita a leitura; não substitua silenciosamente a restauração por uma nova carga inicial.
No Dashboard, abra o banco de dados D1 exato, confirme que o ID não mudou e inspecione os tickets restaurados em uma visualização somente para leitura. Este ponto de verificação conecta os dados recuperados ao recurso; os resultados de SQL/API são as evidências funcionais. Nos Audit Logs da conta, filtre Resource ID pelo UUID deste banco e selecione um intervalo que inclua a recuperação. Clique no horário do evento para abrir os detalhes, expanda Resource e inspecione type: database.time_travel.restore. Compare o ID do recurso e a operação bem-sucedida com a saída da restauração. Os registros de auditoria podem demorar para aparecer; não conclua que houve falha por uma lista temporariamente vazia. As verificações dos dados comprovam o estado recuperado, enquanto a saída real da restauração e o evento de auditoria documentam a operação de recuperação.
Este exemplo mostra os dois tickets originais após a recuperação no mesmo banco. O nome gerado identifica esta execução de exemplo; seu nome e UUID serão diferentes. A captura mostra as linhas restauradas. As verificações SQL/API comprovam o acesso recuperado, enquanto a saída real do comando Time Travel e o evento de auditoria correspondente confirmam a operação de recuperação.
O cabeçalho usa a ação genérica create. Na seção Resource expandida, type: database.time_travel.restore identifica a recuperação. Confira o sucesso, o UUID exato do banco e o horário; esses valores pertencem a esta execução de exemplo.
Excluir os recursos descartáveis
Nesta etapa, você remove somente os recursos deste laboratório enquanto a VM ainda está autorizada. Conclua primeiro todas as verificações funcionais. Mantenha a configuração até concluir a verificação da exclusão.
npx wrangler delete
Confirme somente o nome do Worker presente na configuração desta execução.
npx wrangler d1 delete DB
Inspecione o prompt e confirme somente o banco de dados desta execução. Em seguida, liste os bancos de dados:
npx wrangler d1 list --json
O nome e o UUID do banco de dados registrados por você devem estar ausentes em uma resposta bem-sucedida. Outros recursos podem permanecer. Um erro de autenticação ou de rede é inconclusivo: resolva o acesso e repita a leitura antes de continuar. Faça a verificação desta etapa enquanto ainda estiver conectado.
Encerrar a autorização desta VM
Nesta etapa, você encerra a autorização somente depois que a verificação independente da exclusão for aprovada. O logout remove a autorização do Wrangler armazenada nesta VM; apenas fechar a VM não faz a limpeza na nuvem.
npx wrangler logout
npx wrangler whoami --json
O resultado esperado é loggedIn: false. Essa consulta sem autenticação pode terminar com código diferente de zero; isso é esperado somente quando a resposta estruturada informa explicitamente que você saiu da conta. Conclua a verificação e depois feche o ambiente do laboratório.
Resumo
Você praticou a recuperação de uma exclusão acidental de ticket. Verificou resultados observáveis do banco de dados, manteve explícitos a conta selecionada e o estado local e removeu os recursos descartáveis antes de sair da conta.
