Time Travel: restaurar en el tiempo

El backup tradicional es un ritual de miedo: programas una tarea, rezas para que corra, y descubres si funcionaba justo el día que ya es tarde. D1 elimina el ritual con Time Travel, que trata el historial de la base como un continuo: en lugar de instantáneas que tú tomas, la base recuerda cada estado por el que pasó y te deja volver a cualquier minuto de los últimos treinta días. No hay backup que programar, ni que olvidar, ni que verificar.

Copias que ya no haces

Time Travel no se activa: está siempre encendido, sin coste adicional, sin que tengas que iniciar ni recordar nada. Bajo el capó, D1 mantiene el historial de cambios de tu base y crea marcadores —bookmarks— por su cuenta. Restaurar no cuesta; el historial no cuesta. La diferencia con los backups clásicos no es de grado sino de naturaleza: no hay un artefacto separado que pueda corromperse o quedar desactualizado, porque el mecanismo de recuperación es una propiedad continua de la propia base.

Esto cambia la relación con el error. Una migración fallida, un DELETE sin WHERE, un UPDATE que arrasó una columna: antes eran catástrofes que dependían de si tenías un backup reciente y bueno. Con Time Travel, son un viaje de vuelta a treinta segundos antes del desastre. El miedo que rodeaba a los cambios de esquema en producción se disuelve cuando sabes que cualquier minuto de los últimos treinta días es un destino alcanzable.

Esto no elimina la disciplina, la reordena. Con backups frágiles, el trabajo estaba en hacerlos y rezar; con Time Travel, el trabajo está en saber a qué instante volver, que es una pregunta mucho mejor. Un incidente deja de ser una carrera por encontrar una copia utilizable y se vuelve un ejercicio de precisión: identificar el minuto anterior al error y nombrarlo.

Hay, eso sí, una condición que no conviene olvidar: Time Travel restaura la base, no el mundo. Si tu Worker envió un correo, cobró una tarjeta o llamó a otro servicio entre el error y la restauración, rebobinar la base no deshace esos efectos externos. Es una máquina del tiempo para tus datos, no para las consecuencias que ya salieron de ellos.

Bookmarks y marcas de tiempo

Para volver a un instante hay que nombrarlo. Time Travel acepta dos formas de hacerlo. Un bookmark es el identificador nativo de un punto exacto del historial; son ordenables lexicográficamente, de modo que ordenarlos alfabéticamente es ordenarlos en el tiempo. Una marca de tiempo —un timestamp de Unix o una cadena RFC 3339— es la forma humana, y D1 la convierte de manera determinista al bookmark correspondiente: el mismo instante da siempre el mismo marcador.

# el bookmark del instante actual
npx wrangler d1 time-travel info mi-base

# el bookmark de un momento concreto del pasado
npx wrangler d1 time-travel info mi-base --timestamp="2026-07-15T09:30:00+00:00"

time-travel info es tu telescopio: te dice a qué marcador corresponde un instante, sin tocar nada. Es el paso que das antes de restaurar, para saber exactamente adónde vas a viajar.

Merece la pena detenerse en por qué los bookmarks son ordenables lexicográficamente, porque no es un capricho de formato. Significa que comparar dos marcadores como cadenas de texto es compararlos en el tiempo, sin parsear fechas ni consultar la base: el menor alfabéticamente es el más antiguo. Esa propiedad los hace triviales de almacenar, indexar y comparar en cualquier sistema, desde una cookie hasta una columna.

Y como la conversión entre un instante y su marcador es determinista, no hay ambigüedad: el mismo timestamp produce siempre el mismo bookmark, hoy y dentro de un mes.

timestamp 1752570600   ->  bookmark 00000080-...
mismo instante         ->  siempre el mismo marcador
comparar como texto    ->  ordenar en el tiempo

Esto disuelve una distinción que en otros sistemas es costosa: la que hay entre un momento y una versión de la base. Aquí son lo mismo, y un solo identificador sirve para nombrar ambos, lo que explica que el bookmark reaparezca en la Sessions API y en Time Travel sin cambiar de significado. Piensa en el marcador como en el número de línea de un libro que solo se escribe hacia adelante: identifica una posición exacta en una historia que nunca se reescribe, y por eso sirve tanto para releer como para sincronizar.

Restaurar y deshacer

Restaurar reescribe la base al estado de un instante:

# por marca de tiempo
npx wrangler d1 time-travel restore mi-base --timestamp="2026-07-15T09:30:00+00:00"

# o directamente por bookmark
npx wrangler d1 time-travel restore mi-base --bookmark=00000080-ffffffff-00004c60-390376cb

La operación es destructiva y sobrescribe la base en su sitio; las consultas y transacciones en vuelo se cancelan. Pero Time Travel tiene una red de seguridad elegante: la restauración te devuelve el bookmark del estado inmediatamente anterior a ella. Guardarlo es guardar la puerta de vuelta. Si te arrepientes, restauras a ese marcador y deshaces el viaje, porque restaurar nunca borra los marcadores antiguos: puedes ir y volver por la línea del tiempo cuantas veces necesites.

Deshacer, en la práctica, es restaurar de nuevo a ese marcador de vuelta:

# el restore anterior devolvio este bookmark del estado previo
npx wrangler d1 time-travel restore mi-base --bookmark=00000085-ffffffff-00004c6d-2510c8b0

Como cada restauración es a su vez un punto del historial, la línea del tiempo no se ramifica ni se pierde: avanzas y retrocedes sobre la misma secuencia, y siempre puedes preguntar por el marcador actual con time-travel info. Este diseño revela una asimetría con los backups clásicos: un backup te da puntos discretos —las tres de la mañana de cada día— y entre ellos no hay nada; Time Travel te da un continuo, cualquier minuto, porque no guarda fotos sino el flujo de cambios del que cualquier foto puede derivarse. Puesto de otro modo, el backup es una copia y Time Travel es una memoria: una copia hay que hacerla, guardarla y confiar en ella; una memoria simplemente está.

flowchart LR
T0[estado sano] --> T1[delete sin where]
T1 --> T2[desastre visible]
T2 -->|restore al bookmark previo| T0
T2 -.->|guarda el bookmark de aqui| U[puerta de vuelta]
style T0 fill:#a6e3a1,color:#11111b
style T1 fill:#f38ba8,color:#11111b
style T2 fill:#f38ba8,color:#11111b
style U fill:#89b4fa,color:#11111b

Los límites de viajar en el tiempo

La ventana es de treinta días en el plan de pago —siete en el gratuito—: un bookmark más antiguo que eso es inválido como punto de restauración. El ritmo también tiene tope, y hay algo que Time Travel todavía no hace: bifurcar o clonar la base a una copia nueva; hoy solo sobrescribe la existente. Son límites que revelan su propósito —recuperación ante desastres recientes—, no almacenamiento histórico indefinido.

Cuando necesitas conservar un estado más allá de la ventana de treinta días —por retención legal, por auditoría—, la respuesta no es Time Travel sino exportar: puedes volcar la base a R2 de forma programada con Workflows, y ahí el estado vive tanto como quieras. Time Travel cubre el pasado cercano con precisión de minutos; R2 cubre el archivo de largo plazo. Usar cada herramienta para lo que fue diseñada evita forzar ninguna de las dos.

Como restaurar es destructivo, la operación de más valor no es la restauración sino la anotación previa: time-travel info sobre el estado actual, guardado en algún sitio, es la red bajo la red. El equipo maduro anota el bookmark del presente antes de cualquier cambio arriesgado, igual que etiqueta un release antes de desplegarlo.

Así, la operación de recuperación más valiosa ocurre antes del incidente, no después: en el hábito de dejar migas de pan por la línea del tiempo, para que volver sea cuestión de leerlas.