Exportar y reconstruir una base de datos

CloudflareBeginner
Practicar Ahora

Introducción

Una copia de seguridad solo es útil si permite recuperar los datos de la aplicación. En este laboratorio, exportará una base de datos D1 pequeña a SQL, reconstruirá una segunda base de datos desechable a partir del archivo exportado y comparará los datos y las restricciones sin modificar la base de datos original.

Este laboratorio comienza de forma independiente con dos tickets sintéticos y utiliza como máximo dos bases de datos D1. La copia de seguridad permanece en su máquina virtual de LabEx; el flujo de trabajo no incluye ninguna cuenta ni ningún bucket de almacenamiento de objetos.

Utilice su propia cuenta de aprendizaje y una máquina virtual nueva. La configuración prepara Node.js 22.22.0 y después ejecuta npm install para instalar Wrangler 4.131.1, específico del proyecto, y las dependencias de evaluación en /home/labex/project/ticket-database. Las versiones de las dependencias directas están fijadas y la instalación crea su propio archivo de bloqueo. La configuración no inicia sesión en la nube ni ejecuta operaciones evaluadas sobre bases de datos. En una máquina personal, instale la misma versión de Wrangler con npm install --save-dev wrangler@4.131.1 en su proyecto.

Este ejercicio utiliza registros sintéticos pequeños dentro de los límites gratuitos de D1. El uso existente de la cuenta cuenta para esos límites. No necesita un dominio comprado. Conserve esta máquina virtual hasta comprobar tanto la eliminación de los recursos como el cierre de sesión.

Autorice esta máquina virtual y seleccione la cuenta

En este paso, conectará este terminal nuevo a su propia cuenta de aprendizaje. Iniciar sesión en el Dashboard por sí solo no autoriza la máquina virtual. Los permisos de D1 permiten crear, modificar mediante SQL y eliminar bases de datos. Revise la página de consentimiento real, incluido el acceso en segundo plano (Background Access), antes de autorizar.

Abra el proyecto preparado e inspeccione la versión fijada de la CLI:

cd /home/labex/project/ticket-database
npx wrangler --version

Debe aparecer 4.131.1. Inicie la autorización mediante dispositivo. --device muestra un código para el navegador y --browser=false le permite elegir cómo abrir el navegador:

npx wrangler login --device --browser=false --scopes account:read user:read d1:write

Abra en el navegador la URL que se muestra, introduzca el código actual, confirme su cuenta de aprendizaje y los permisos, y autorice el acceso. Espere a que el terminal confirme que la operación se realizó correctamente. Nunca pegue contraseñas ni tokens en archivos del proyecto.

npx wrangler whoami --json

Compruebe loggedIn: true y lea el name y el id de la cuenta, aunque solo aparezca una cuenta. Copie el ID previsto en la configuración siguiente. La variable de shell siguiente utiliza 6 bytes aleatorios (12 caracteres hexadecimales) para evitar colisiones con otros estudiantes. Un documento here escribe el JSON situado entre las líneas JSON; $RUN se expande dentro de él.

La barra invertida delante de $schema conserva esa clave JSON literalmente; $RUN sigue expandiéndose al nombre único de esta ejecución.

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

Sustituya YOUR_ACCOUNT_ID antes de ejecutar el bloque. Mantenga abierto este terminal para que RUN siga disponible. name identifica esta ejecución y account_id selecciona la cuenta para las operaciones en la nube. El archivo es JSON estándar, que también es válido como JSONC. Escribir este archivo no despliega ningún Worker.

Prepare la base de datos que conservará

En este paso, creará una base de datos original pequeña. La configuración proporciona el esquema de tickets; su tarea consiste en exportarlo y reconstruirlo, incluidas sus restricciones, sin modificar la base de datos original.

Cree una base de datos desechable en la nube. --binding DB proporciona a la aplicación un nombre corto, --update-config registra su nombre real y su UUID en wrangler.jsonc, y --use-remote=false mantiene el desarrollo en local:

npx wrangler d1 create "$RUN-db" --binding DB --update-config --use-remote=false

Lea el nombre y el ID creados y, después, inspeccione el binding guardado:

cat wrangler.jsonc

La entrada DB debe indicar la base de datos de esta ejecución. Un binding es una conexión configurada entre el código y un recurso. Su UUID identifica la base de datos en la nube, mientras que --local utiliza una base de datos SQLite independiente en esta máquina virtual. Incluya siempre --local o --remote en los comandos SQL.

cat schema.sql
npx wrangler d1 execute DB --remote --file schema.sql

Lea los datos y el esquema de origen antes de exportarlos:

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';"

Hay dos tickets. Anote lo que espera encontrar: el ID 1 es Cannot sign in y está abierto; el ID 2 es Invoice copy y está cerrado. Ambos tienen seed como origen. El esquema contiene una clave primaria, valores obligatorios y una restricción sobre el estado.

Exporte una copia de seguridad SQL completa

En este paso, creará un archivo SQL portable. Una exportación describe las definiciones de las tablas y los datos mediante SQL; importar ese archivo permite reconstruir una base de datos en otro lugar. Esto es diferente de D1 Time Travel, que restaura el historial en el mismo lugar.

--remote selecciona el origen en la nube y --output indica el archivo que se escribirá en esta máquina virtual. Conserve tanto el esquema como los datos omitiendo --no-schema y --no-data:

npx wrangler d1 export DB --remote --output backup.sql

Confirme la base de datos de origen exacta si se le solicita. Inspeccione el archivo exportado, que es pequeño:

cat backup.sql

Busque CREATE TABLE y las instrucciones INSERT de los tickets. El formato de la exportación, las comillas de las columnas y las instrucciones internas pueden diferir del SQL escrito originalmente. Una descarga correcta por sí sola no demuestra que sea posible recuperar los datos; el siguiente paso comprobará el artefacto mediante la reconstrucción de la base de datos. Este archivo solo contiene datos sintéticos. Consérvelo en la máquina virtual; no necesita ningún bucket de R2.

Reconstruya una base de datos independiente

En este paso, restaurará los datos en una segunda base de datos vacía y dejará intacta la original. Un destino independiente le permite comparar los datos recuperados antes de cambiar un binding de la aplicación.

Cree un segundo recurso con el binding REBUILT. La actualización de la configuración lo añadirá junto a DB:

npx wrangler d1 create "$RUN-copy" --binding REBUILT --update-config --use-remote=false
cat wrangler.jsonc

Compruebe que los dos bindings tienen UUID de base de datos diferentes y los nombres esperados -db y -copy. Importe únicamente en REBUILT:

npx wrangler d1 execute REBUILT --remote --file backup.sql

Esto ejecuta el SQL exportado en el nuevo destino de la nube. Confirme ese destino cuando se le solicite. Consúltelo:

npx wrangler d1 execute REBUILT --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id; PRAGMA table_info(tickets);"

Las filas y las definiciones de las columnas deben coincidir con las de la base de datos original. Pruebe una de las restricciones restauradas mediante una inserción no válida:

npx wrangler d1 execute REBUILT --remote --command "INSERT INTO tickets (id, subject, status, source) VALUES (3, 'Invalid', 'lost', 'probe');"

Debe aparecer CHECK constraint failed. El error intencionado no debe añadir una tercera fila. Vuelva a leer ambas bases de datos:

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;"

Ambas deben seguir teniendo exactamente las dos filas originales. Abra en el Dashboard los dos nombres exactos de los recursos para realizar una comprobación de solo lectura; verifique que sus ID sean distintos antes de inspeccionar la tabla reconstruida. Nunca sobrescriba otra base de datos para probar una recuperación.

Tickets reconstruidos en la base D1 independiente

Este ejemplo muestra los dos tickets restaurados en la base -copy. El nombre generado identifica esta ejecución de ejemplo; tus nombres y UUID serán distintos. La captura solo confirma las filas visibles. Los comandos de exportación e importación de la CLI y las comprobaciones independientes anteriores verifican la reconstrucción, la coincidencia del esquema y la conservación de las restricciones.

Elimine los recursos desechables

En este paso, eliminará únicamente los recursos de este laboratorio mientras la máquina virtual siga autorizada. Termine primero todas las comprobaciones funcionales. Conserve la configuración hasta completar la verificación de la eliminación.

npx wrangler d1 delete REBUILT
npx wrangler d1 delete DB

Revise la solicitud de confirmación y confirme que solo se trata de la base de datos de esta ejecución. Después, enumere las bases de datos:

npx wrangler d1 list --json

En una respuesta correcta no deben aparecer ni los nombres ni los UUID registrados de ninguna de las dos bases de datos. Es posible que queden otros recursos. Un error de autenticación o de red no permite sacar conclusiones: resuelva el problema de acceso y repita la consulta antes de continuar. Ejecute la verificación de este paso mientras siga conectado.

Finalice la autorización de esta máquina virtual

En este paso, finalizará la autorización solo después de que la comprobación independiente de la eliminación se haya realizado correctamente. Cerrar una máquina virtual no limpia los recursos en la nube; cerrar sesión elimina la autorización de Wrangler almacenada en esta máquina virtual.

npx wrangler logout
npx wrangler whoami --json

Debe aparecer loggedIn: false. Esta consulta sin autenticación puede terminar con un código distinto de cero; eso solo es correcto cuando la respuesta estructurada indica explícitamente que ha cerrado sesión. Complete la verificación y después cierre el entorno del laboratorio.

Resumen

Practicó cómo exportar y reconstruir una base de datos. Comprobó resultados observables de la base de datos, mantuvo explícitos la cuenta seleccionada y el estado local, y eliminó los recursos desechables antes de cerrar sesión.