Reeve Backups
El historial de versiones no es un backup. No recupera una tabla.
Lovable y Bolt guardan un historial de versiones de tu código. Tu base de datos es un servicio aparte, y volver atrás no te devuelve tus datos.
En resumen
- El historial de versiones restaura tu código. Nunca toca tu base de datos, que es donde viven tus usuarios, sus contenidos y sus pedidos.
- Una tabla borrada, una fila sobrescrita o una migración torcida sobreviven intactas a una vuelta atrás.
- Tu código trae un deshacer incorporado. Tus datos solo tienen uno si tú lo pones ahí.
Algo se rompió, así que hiciste lo sensato. Abriste el historial de versiones en Lovable o Bolt, buscaste la versión de esta mañana y pulsaste restaurar. La app volvió exactamente como estaba.
Los datos no.
Aquí está la parte donde la gente tropieza: tu código y tus datos son dos sistemas separados, y solo uno de ellos tiene botón de deshacer. Tu builder guarda los planos de tu app. Tu base de datos guarda lo que hay dentro. El historial de versiones reconstruye los planos a la perfección, hasta el último detalle, y te devuelve un edificio idéntico y vacío.
¿El historial de versiones de mi builder respalda mi base de datos?
No. Guarda tu código, y tus datos viven en otro sitio completamente distinto.
Lovable, Bolt, v0, Replit, Cursor y los demás llevan un historial de los archivos de tu proyecto: tus páginas, tus componentes, tu lógica, tus estilos. Eso son los planos. Restaurar una versión reescribe esos archivos tal y como estaban el día que elegiste.
Tu base de datos es un servicio diferente, casi siempre Supabase, en una cuenta propia. Nada del historial de tu proyecto entra ahí. La restauración no tiene opinión sobre tus datos porque no puede verlos.
Por qué tu código y tus datos viven en sitios distintos
Porque tus datos tienen que sobrevivir a lo que tu código hace constantemente, que es cambiar.
Tu código se reconstruye cada vez que publicas. Si los pedidos de tus usuarios vivieran dentro, se borrarían cada vez que arreglas un botón. Por eso se mantienen aparte, a propósito: el código es reemplazable y los datos no, y por eso los versionan herramientas distintas.
El precio de esa separación es de lo que va este artículo. Toda herramienta que versiona uno de los dos es ciega al otro. Tu builder no puede recuperar una tabla, y tu base de datos no puede recuperar una página rota.
Qué pasa de verdad cuando vuelves atrás
Tus pantallas vuelven a como estaban. Tus datos no se mueven en absoluto.
| Qué | Al volver atrás el código |
|---|---|
| Páginas, componentes, estilos | Restaurado |
| La lógica de tu app y sus arreglos | Restaurado |
| Una tabla que alguien borró | Sigue borrada |
| Filas que sobrescribió un script | Siguen sobrescritas |
| Una columna que quitó una migración | Sigue quitada |
| Archivos que subieron tus usuarios | Sin cambios en ningún sentido |
La fila de la migración es la que más sorprende. Una migración que lanzaste contra tu base de datos ya ocurrió; vive en la base de datos, no en tu repositorio, y deshacer el archivo que la describía no cambia nada.
Dónde muerde esto de verdad
En los diez minutos posteriores a un error, cuando vas a buscar el deshacer y descubres que no hay ninguno.
Las formas que toma son de lo más corriente:
- Un borrado en el editor de tablas de Supabase que alcanzó más filas de las previstas.
- Una migración asistida por IA que quitó una columna para que desapareciera un error de tipos.
- Un script de carga o de reinicio apuntado al proyecto en producción en vez de a uno de pruebas.
- Una limpieza de lo que parecían datos de prueba y resultó ser la cuenta real de alguien.
Nada de esto toca una sola línea de tu código. Todo ello sobrevive intacto a una vuelta atrás, y por eso la vuelta atrás parece no haber hecho nada. Hizo exactamente lo que hace.
Para qué sirve de verdad el historial de versiones
Para bastante, y conviene decirlo con claridad, porque la respuesta no es «para nada».
Es un deshacer real para problemas reales: un cambio de diseño del que te arrepientes, una publicación que rompió una página, una edición de la IA que reescribió a peor una pantalla que funcionaba, una función que acabó haciendo la app más difícil de usar. Todo eso vive en tu código, y para eso funciona exactamente como promete.
El problema es la suposición callada de que su trabajo lo cubre todo. Esa suposición no la hace nadie a propósito; es con la que te quedas cuando nadie te cuenta que hay dos sistemas.
Cómo conseguir un deshacer de verdad para tus datos
Tienes que ponerlo tú. Es decir, una copia de la base de datos, tomada con un horario, guardada en un sitio que perder la cuenta no se lleve por delante.
Hay tres maneras de hacerlo, cuestan cantidades distintas de dinero y de atención, y a cada una se le escapa algo que cubren las otras. Tres formas de respaldar una base Supabase recorre las tres, incluida la que casi todo el mundo debería activar primero y la razón por la que no basta por sí sola.
Para eso está también Reeve Care: copias programadas de tu base de datos de Supabase, guardadas fuera de tu cuenta de Supabase y comprobadas antes de contar como hechas. Conecta tus buckets de Storage y los archivos que subieron tus usuarios viajan con ellas, así que una restauración devuelve las filas y las imágenes a las que apuntan.
Qué contiene una de esas copias, y qué hace realmente el botón, está en la página de copias de Supabase.
Qué hacer esta semana
Qué hacer
- Averigua si algo está respaldando ahora mismo tu base de datos. No tu código: tu base de datos. Si la respuesta tarda más de un minuto en aparecer, la respuesta es no.
- Activa el backup que incluya tu plan de Supabase. Te protege de tus propios errores, que es justo el fallo del que trata este artículo.
- Guarda además una copia en otro sitio, porque un backup que vive dentro de la cuenta no te sirve si pierdes la cuenta.
- Respalda por separado los archivos subidos. No están ni en tu código ni en tu base de datos.
- Restaura una copia en un proyecto desechable, para que la primera vez que leas ese archivo no sea el día que lo necesitas.
Antes de cerrar esta pestaña, abre tu proyecto de Supabase y mira si los backups están activados. Esa única comprobación es todo el trabajo de hoy. La checklist de seguridad de 10 minutos la cubre junto al resto de lo que conviene confirmar en una app recién lanzada, y la guía de seguridad de Supabase repasa qué más se suele dejar abierto.
Preguntas frecuentes
He borrado una tabla sin querer. ¿Puedo recuperarla?
Solo desde un backup hecho antes del borrado, así que lo primero es averiguar si existe alguno. Volver atrás tu código no lo consigue, y tu builder tampoco. En un plan de pago de Supabase hay backups diarios, y recuperación a un punto en el tiempo si la añadiste. En el plan gratuito no hay nada automático. Comprueba qué tienes antes de cambiar cualquier otra cosa, porque algunas vías de vuelta se complican en cuanto empiezas a escribir datos nuevos sobre el hueco.
¿Lovable hace copias de mi base de datos de Supabase?
Tu builder versiona los archivos de tu proyecto. Tu base de datos es un servicio aparte en tu propia cuenta de Supabase, y nada del historial del proyecto entra ahí. Los builders añaden funciones, así que mira la documentación del tuyo en lugar de suponer en un sentido o en otro, pero da por hecho que la respuesta es no hasta que hayas leído que es sí.
¿Mi historial de Git es un backup?
No, exactamente por la misma razón por la que no lo es el historial de versiones. Git sigue los archivos con los que se construye tu app. Nunca ha visto una sola fila de tus datos y no puede devolver ninguna. Un repositorio y una base de datos son cosas distintas que se llaman las dos «tu proyecto».
Mis datos siguen todos ahí. ¿Tengo que hacer algo hoy?
Hoy es el día más barato en que vas a montar esto, porque los datos son pocos y lo que importa es que la costumbre exista antes de necesitarla. Las pérdidas que duelen rara vez son dramáticas: son un comando mal tecleado durante un arreglo de madrugada, en un proyecto con los usuarios reales justos para que empezar de cero no sea una opción.