Introdução
Um backup só é útil se conseguir recuperar os dados da aplicação. Você exportará um banco de dados D1 pequeno para SQL, reconstruirá um segundo banco descartável a partir do arquivo exportado e comparará os dados e as restrições, mantendo o original inalterado.
Este laboratório começa de forma independente com dois tickets sintéticos e usa no máximo dois bancos de dados D1. O backup permanece na sua VM do LabEx; nenhuma conta ou bucket de armazenamento de objetos faz parte do fluxo de trabalho.
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 todas as dependências de avaliação em /home/labex/project/ticket-database. As versões das dependências diretas são fixadas; a instalação cria seu próprio lockfile. Nenhum login na nuvem nem trabalho de avaliação de banco de dados é executado durante a configuração. 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 dos limites gratuitos do D1. O uso existente da conta conta para esses limites. Nenhum domínio comprado é necessário. 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. Revise a página de consentimento real, incluindo o acesso em segundo plano (Background Access), antes de autorizar.
Abra o projeto preparado e verifique a versão fixada da CLI:
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 permite que você escolha como abrir o navegador:
npx wrangler login --device --browser=false --scopes account:read user:read d1:write
Abra a URL exibida no navegador, informe o código atual, confirme sua conta de aprendizado e as permissões e autorize o acesso. Aguarde a confirmação de sucesso no terminal. Nunca cole senhas ou tokens nos arquivos do projeto.
npx wrangler whoami --json
Verifique loggedIn: true. Depois, 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 conflitos com outros alunos. Um here-document grava o JSON entre as linhas JSON; $RUN é expandido 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-d06-$(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 usada nas operações na nuvem. O arquivo é um JSON comum, que também é um JSONC válido. Gravar esse arquivo não faz o deploy de nenhum Worker.
Preparar o banco de dados que será preservado
Nesta etapa, você criará um banco de dados original pequeno. A configuração fornece o esquema dos tickets; seu trabalho é exportá-lo e reconstruí-lo, incluindo suas restrições, sem alterar o original.
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 o binding salvo:
cat wrangler.jsonc
A entrada DB deve indicar o banco de dados desta execução. Um binding é 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 de dados SQLite separado nesta VM. Sempre inclua --local ou --remote nos comandos SQL.
cat schema.sql
npx wrangler d1 execute DB --remote --file schema.sql
Leia os dados e o esquema de origem antes de exportar:
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id; SELECT sql FROM sqlite_master WHERE type = 'table' AND name = 'tickets';"
Há dois tickets. Registre o que você espera: o ID 1 é Cannot sign in e está aberto; o ID 2 é Invoice copy e está fechado. Ambos têm seed como origem. O esquema contém uma chave primária, valores obrigatórios e uma restrição de status.
Exportar um backup SQL completo
Nesta etapa, você criará um arquivo SQL portátil. Uma exportação descreve as definições das tabelas e os dados como SQL; a importação desse arquivo pode reconstruir um banco de dados em outro local. Isso é diferente do D1 Time Travel, que restaura o histórico no próprio local.
--remote seleciona a origem na nuvem e --output define o arquivo gravado nesta VM. Mantenha o esquema e os dados omitindo --no-schema e --no-data:
npx wrangler d1 export DB --remote --output backup.sql
Confirme o banco de dados de origem exato se for solicitado. Inspecione o arquivo exportado, que é pequeno:
cat backup.sql
Procure CREATE TABLE e as instruções INSERT dos tickets. A formatação da exportação, as aspas das colunas e as instruções internas podem ser diferentes do SQL original escrito manualmente. Um download bem-sucedido, por si só, não prova que seja possível recuperar os dados; a próxima etapa testa o artefato reconstruindo o banco. Este arquivo contém apenas dados sintéticos. Mantenha-o na VM; nenhum bucket do R2 é necessário.
Reconstruir um banco de dados separado
Nesta etapa, você restaurará os dados em um segundo banco vazio, mantendo o original intocado. Um destino separado permite comparar os dados recuperados antes de alterar um binding da aplicação.
Crie um segundo recurso com o binding REBUILT. A atualização da configuração o adiciona ao lado de DB:
npx wrangler d1 create "$RUN-copy" --binding REBUILT --update-config --use-remote=false
cat wrangler.jsonc
Verifique se os dois bindings têm UUIDs de banco de dados diferentes e os nomes esperados, -db e -copy. Importe somente para REBUILT:
npx wrangler d1 execute REBUILT --remote --file backup.sql
Esse comando executa o SQL exportado no novo destino na nuvem. Confirme esse destino quando o prompt solicitar. Consulte-o:
npx wrangler d1 execute REBUILT --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id; PRAGMA table_info(tickets);"
As linhas e as definições das colunas devem corresponder às do original. Teste uma das restrições restauradas usando uma inserção inválida:
npx wrangler d1 execute REBUILT --remote --command "INSERT INTO tickets (id, subject, status, source) VALUES (3, 'Invalid', 'lost', 'probe');"
O resultado esperado é CHECK constraint failed. Essa falha intencional não deve adicionar uma terceira linha. Leia os dois bancos de dados novamente:
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
npx wrangler d1 execute REBUILT --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
Ambos ainda devem conter exatamente as duas linhas originais. Abra os dois nomes exatos dos recursos no Dashboard para uma verificação somente leitura; confirme os IDs diferentes antes de inspecionar a tabela reconstruída. Nunca substitua outro banco de dados para testar a recuperação.
Este exemplo mostra os dois tickets restaurados no banco -copy. O nome gerado identifica esta execução de exemplo; seus nomes de recursos e UUIDs serão diferentes. A captura confirma apenas as linhas visíveis. Os comandos de exportação e importação da CLI e as verificações independentes acima comprovam a reconstrução, a correspondência do esquema e a preservação das restrições.
Excluir os recursos descartáveis
Nesta etapa, você removerá somente os recursos deste laboratório enquanto a VM ainda estiver autorizada. Conclua primeiro todas as verificações funcionais. Mantenha a configuração até terminar de verificar a exclusão.
npx wrangler d1 delete REBUILT
npx wrangler d1 delete DB
Inspecione o prompt e confirme que apenas o banco de dados desta execução será excluído. Depois, liste os bancos de dados:
npx wrangler d1 list --json
Os dois nomes e UUIDs de banco de dados registrados devem estar ausentes em uma resposta bem-sucedida. Outros recursos podem continuar presentes. Um erro de autenticação ou de rede é inconclusivo: resolva o problema de acesso e repita a leitura antes de continuar. Execute a verificação desta etapa enquanto ainda estiver conectado.
Encerrar a autorização desta VM
Nesta etapa, encerre 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; fechar uma VM, por si só, 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 um 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 exportação e a reconstrução de um banco de dados. Verificou os resultados observáveis do banco, manteve explícitos a conta selecionada e o estado local e removeu os recursos descartáveis antes de sair da conta.
