Introducción
Un ticket desaparece después de una eliminación accidental mediante SQL, pero la configuración de la aplicación sigue siendo correcta. En este laboratorio, capturará un marcador de D1 Time Travel, reproducirá la pérdida con un único registro sintético y restaurará la misma base de datos conservando un ticket que no se vio afectado.
Este ejercicio independiente de recuperación utiliza una base de datos remota desechable y un Worker proporcionado, de solo lectura. Verificará el estado de ausencia antes de restaurarlo y comprobará el acceso de la aplicación después de la restauración.
Utilice su propia cuenta de aprendizaje y una VM nueva. La configuración instala primero Node.js 22.22.0 y después ejecuta npm install para instalar Wrangler 4.131.1 de forma local en el proyecto, junto con las dependencias necesarias para la evaluación, en /home/labex/project/ticket-database. Las versiones de las dependencias directas están fijadas; la instalación crea su propio archivo de bloqueo. Durante la configuración no se inicia ninguna sesión en la nube ni se realizan operaciones evaluadas sobre la base de datos. En una máquina personal, instale la misma versión de Wrangler con npm install --save-dev wrangler@4.131.1 dentro de su proyecto.
Este ejercicio utiliza registros sintéticos pequeños dentro de las asignaciones gratuitas de D1. El uso existente de la cuenta cuenta para esas asignaciones. No necesita un dominio comprado. Conserve esta VM hasta comprobar la eliminación de los recursos y el cierre de sesión.
Autorice esta VM 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 VM. El permiso de D1 permite crear, modificar mediante SQL y eliminar bases de datos; el permiso de Workers permite realizar implementaciones, y el permiso de KV permite que Wrangler recopile el inventario necesario para la limpieza. 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 CLI cuya versión está fijada:
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 workers_scripts:write workers_kv:write
Abra en el navegador la URL mostrada, 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 los archivos del proyecto.
npx wrangler whoami --json
Compruebe loggedIn: true y lea los valores name e id de la cuenta, incluso si solo aparece una cuenta. Copie el ID previsto en la configuración siguiente. La variable de shell siguiente utiliza 6 bytes aleatorios, es decir, 12 caracteres hexadecimales, para evitar conflictos con otros estudiantes. Un documento aquí escribe el JSON situado entre las líneas JSON; $RUN se expande dentro de ese bloque.
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-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
Reemplace YOUR_ACCOUNT_ID antes de ejecutar el bloque. Mantenga abierto este terminal para que RUN siga disponible. name identifica esta ejecución; account_id selecciona la cuenta que se utilizará en las operaciones en la nube. El archivo es JSON normal, que también es válido como JSONC. Al escribirlo no se implementa ningún Worker.
Establezca un punto de restauración conocido
En este paso, creará la base de datos desechable y una API de tickets proporcionada, de solo lectura. Time Travel restaura el estado anterior de una base de datos en el mismo lugar. No crea una base de datos de reemplazo y puede sobrescribir los cambios realizados después del punto elegido. Aquí debe utilizarlo únicamente en este recurso del laboratorio recién creado.
Cree una base de datos desechable en la nube. --binding DB proporciona al código de 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 la vinculación guardada:
cat wrangler.jsonc
La entrada DB debe indicar la base de datos de esta ejecución. Una vinculación 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 VM. Incluya siempre --local o --remote en los comandos SQL.
npx wrangler d1 execute DB --remote --file schema.sql
npx wrangler deploy
Copie la URL implementada y lea los dos tickets sintéticos:
URL='YOUR_DEPLOYED_HTTPS_URL'
curl -i "$URL/tickets/1"
curl -i "$URL/tickets/2"
Debe recibir 200 para el ticket 1 (Cannot sign in, abierto) y para el ticket 2 (Invoice copy, cerrado). Si la implementación todavía se está propagando, repita estas lecturas durante un máximo de un minuto, hasta que el estado HTTP y el JSON coincidan con lo esperado.
Consulte la información de la base de datos y guarde su marcador actual como artefacto de recuperación. Un marcador es una posición opaca del historial de la base de datos. La redirección con > escribe la respuesta JSON en el archivo indicado:
npx wrangler d1 info DB
npx wrangler d1 time-travel info DB --json > recovery.json
cat recovery.json
Verifique que la base de datos utiliza el backend de producción y que recovery.json contiene un bookmark no vacío. Mantenga este archivo sin cambios durante todo el ejercicio. Time Travel está siempre habilitado para D1 en producción; Free conserva los datos durante 7 días y Paid durante 30 días. Esta recuperación dentro de la misma sesión solo necesita unos minutos de historial. Una línea de ayuda de la CLI que mencione 30 días no modifica la retención de su plan.
Reproduzca una eliminación accidental acotada
En este paso, eliminará únicamente el ticket sintético 1 de la base de datos de este laboratorio y demostrará el síntoma en la aplicación. Primero, inspeccione wrangler.jsonc y compruebe que DB coincide con el nombre y el UUID que acaba de crear. No ejecute este comando contra una base de datos de una aplicación existente.
cat wrangler.jsonc
npx wrangler d1 execute DB --remote --command "DELETE FROM tickets WHERE id = 1;"
Lea la API y el registro que no se vio afectado:
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;"
El ticket 1 debe devolver 404 con {"error":"not_found"}. El ticket 2 debe seguir devolviendo su respuesta 200 original; la consulta SQL debe contener únicamente el ticket 2. Un error de red o una página 404 de la plataforma no demuestra que la eliminación se haya producido.
Complete la verificación de este paso antes de restaurar. Esta comprobación confirma el estado real de la fila ausente; restaurar sin observar el fallo omitiría las evidencias del incidente.
Restaure el historial y verifique el acceso de la aplicación
En este paso, restaurará la misma base de datos a su marcador guardado. Lea recovery.json, copie la cadena exacta de bookmark en BOOKMARK y vuelva a comprobar la identidad de la base de datos configurada:
cat recovery.json
BOOKMARK='YOUR_SAVED_BOOKMARK'
cat wrangler.jsonc
npx wrangler d1 time-travel restore DB --bookmark "$BOOKMARK"
El comando advierte que sobrescribirá los datos y cancelará las consultas en curso. Confirme únicamente esta base de datos desechable. Debe aparecer un mensaje de restauración correcta y un marcador para deshacer la operación. No vuelva a crear la base de datos, no vuelva a importar el esquema ni inserte la fila que falta: esas acciones evitarían utilizar la técnica de recuperación.
Consulte la base de datos restaurada y la vinculación existente de la aplicación:
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"
Deben volver a aparecer las dos filas originales y las respuestas de ambas llamadas a la API. El Worker sigue apuntando al mismo UUID y no necesita una vinculación de reemplazo. Si una lectura no está disponible brevemente durante la restauración, repita la lectura; no sustituya silenciosamente la restauración por una nueva carga inicial de datos.
En el Dashboard, abra la base de datos D1 exacta, confirme que su ID no ha cambiado e inspeccione los tickets restaurados mediante una vista de solo lectura. Este punto de control relaciona los datos recuperados con el recurso; los resultados de SQL y de la API son la evidencia funcional. En Audit Logs de la cuenta, filtre Resource ID por el UUID de esta base y seleccione un intervalo que incluya la recuperación. Abra el evento haciendo clic en su marca de tiempo, expanda Resource en los detalles e inspeccione type: database.time_travel.restore. Haga coincidir el ID del recurso y la operación correcta con la salida de la restauración. Los registros de auditoría pueden tardar en aparecer; no deduzca que la operación falló a partir de una lista temporalmente vacía. Las comprobaciones de datos demuestran el estado recuperado, mientras que la salida real de la restauración y el evento de auditoría documentan la operación de recuperación.
Este ejemplo muestra los dos tickets originales después de la recuperación en la misma base. El nombre generado identifica esta ejecución de ejemplo; tu nombre y UUID serán distintos. La captura muestra las filas restauradas. Las comprobaciones SQL/API verifican el acceso recuperado, mientras que la salida real del comando Time Travel y el evento de auditoría correspondiente confirman la operación de recuperación.
El encabezado usa la acción genérica create. En la sección Resource expandida, type: database.time_travel.restore identifica la recuperación. Compruebe el resultado correcto, el UUID exacto y la hora; estos valores pertenecen a esta ejecución de ejemplo.
Elimine los recursos desechables
En este paso, eliminará únicamente los recursos de este laboratorio mientras la VM todavía está autorizada. Termine primero todas las comprobaciones funcionales. Conserve la configuración hasta completar la verificación de la eliminación.
npx wrangler delete
Confirme que solo aparece el nombre del Worker de la configuración de esta ejecución.
npx wrangler d1 delete DB
Inspeccione la solicitud de confirmación y confirme únicamente la base de datos de esta ejecución. Después, enumere las bases de datos:
npx wrangler d1 list --json
El nombre y el UUID de la base de datos que registró deben estar ausentes en una respuesta correcta. Es posible que otros recursos sigan existiendo. Un error de autenticación o de red no permite sacar conclusiones: resuelva el problema de acceso y repita la lectura antes de continuar. Realice la verificación de este paso mientras todavía tenga la sesión iniciada.
Finalice la autorización de esta VM
En este paso, finalizará la autorización únicamente después de que la comprobación independiente de la eliminación se complete correctamente. El cierre de sesión elimina la autorización de Wrangler almacenada en esta VM; cerrar una VM por sí solo no limpia los recursos de la nube.
npx wrangler logout
npx wrangler whoami --json
Debe aparecer loggedIn: false. Esta consulta sin autenticación puede finalizar con un código distinto de cero; eso solo es esperado 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ó la recuperación de la eliminación accidental de un ticket. 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.
