Reeve Backups
Un agente de IA borró mis datos de Supabase. ¿Qué puedo recuperar?
Un agente de IA borró datos de tu base. Lo que puedes recuperar ya estaba decidido antes de que se ejecutara, y los próximos minutos deciden el resto.
En resumen
- Si un agente de IA borró datos de tu base, lo que puedes recuperar es lo que hubiera en la última copia tomada antes. Lo creado después no quedó escrito en ningún otro sitio.
- Corta todo lo que escriba filas nuevas antes que cualquier otra cosa. Una restauración quita todo lo añadido después de la copia, así que un registro que entre ahora es una fila que borrarás tú mismo.
- El agente no puede devolver las filas. Nunca las tuvo, y volver a ejecutarlo contra una base en producción es otra ocasión de perder más.
Le pediste al agente que limpiara unas filas de prueba, o que arreglara una migración que no acababa de aplicarse. Escribió el SQL él mismo, lo ejecutó contra el proyecto que usa tu app en producción y te dijo que estaba hecho. La app sigue cargando. La tabla está vacía.
Cuando un agente de IA ha borrado datos de tu base, lo que puedes recuperar ya estaba decidido antes de que se ejecutara. Los próximos minutos deciden cuánto de eso sobrevive.
Aquí está lo que fallan casi todas las respuestas a esto. Te dicen que vuelvas atrás en el código, o que le pidas al agente que lo deshaga. Ninguna de las dos toca tus datos, y mientras lo intentas, lo único que todavía está en tu mano se va poniendo peor en silencio: lo que tu app está escribiendo en la base ahora mismo.
¿Qué puedo recuperar después de que una IA borrara mis datos?
Lo que hubiera en la última copia de tu base tomada antes del borrado, y nada de lo que se creara después.
Esa es toda la respuesta, y la mayor parte se decidió hace semanas. Aquí no hay
un paso forense, nada que desborrar, ningún registro esperando en Supabase para
volver a reproducirse. Una fila que se llevó un DELETE o un DROP TABLE
desapareció de la base en el momento en que la instrucción se confirmó. Lo que
vuelve es una copia, y una copia existe o no existe.
Así que tienes dos tareas delante. Averiguar qué copias existen. Y evitar que el hueco entre la más reciente y ahora salga más caro de lo que ya sale.
Lo primero: para todo lo que escriba en la base
Antes de ponerte a buscar una copia de seguridad, apaga todo lo que escriba filas nuevas. Leer no es problema.
Hay dos razones, y la segunda pilla a la gente.
La primera es que una restauración no es una fusión. Volver a poner una copia sustituye las tablas que contiene por lo que aquellas tablas tenían entonces, y todo lo escrito después se va con ellas. Un cliente que se registre durante la hora que pases leyendo esto es una fila que borrarás tú mismo, más tarde, en un paso que ya has decidido dar.
La segunda es que algunas vías empeoran mientras esperas. La recuperación a un momento concreto de Supabase devuelve el proyecto entero a un minuto que tú eliges, así que cuanto más se aleje la app del error, más trabajo auténtico tira esa vuelta atrás junto con el daño.
Una hora detrás de un aviso de mantenimiento sale barata. Explicarle a alguien que su pedido se creó y luego se quitó a propósito sale mucho más caro.
¿Puedo pedirle al agente que lo deshaga?
No. Nunca tuvo tus filas.
El agente escribió una instrucción y tu base la ejecutó. Lo que tiene ahora es la transcripción de esa conversación, que es algo distinto de una copia de la tabla. Pídele que deshaga el borrado y obtendrás una respuesta segura de sí misma, SQL plausible y ningún dato.
Vale la pena ser concreto con el riesgo, porque la petición parece inofensiva. Volver a ejecutar el agente significa una segunda sesión sin supervisión contra una base en producción que ya ha perdido algo. Si decide que la forma de arreglar una tabla que falta es crear una, ahora tienes una tabla nueva y vacía donde estaba la antigua, y has hecho la pérdida más difícil de describirle a quien te ayude después.
Sácalo del proyecto hasta que sepas dónde estás. Lo mismo vale para el historial de versiones de tu builder: volver con el código a esta mañana restaura tus páginas y deja tus datos exactamente donde están, por razones que conviene entender una vez.
Dónde mirar, y en qué orden
Baja por esta lista y párate en la primera que exista. Está ordenada por cuántos de tus datos vuelven, que no es lo mismo que por lo fácil que sea.
| Dónde mirar | Qué puede devolver | Qué tenía que ser cierto ya |
|---|---|---|
| Recuperación de Supabase a un momento concreto | La base tal como estaba en un minuto que tú eliges, incluido el anterior al borrado | Un plan de pago con la opción PITR, contratada antes de hoy |
| Copia diaria de Supabase | La base tal como estaba en la última copia automática | Un plan de pago |
| Un servicio de copias gestionado | La base tal como estaba en la última copia comprobada de ese servicio | Conectaste uno antes de hoy |
Un pg_dump que hiciste tú | Todo lo que haya en el archivo, tan viejo como la última vez que te acordaste | El archivo existe y terminó de escribirse |
| Una tabla de borrado suave o auditoría en tu app | Solo las filas de las que tu app ya llevaba registro | La construiste así a propósito |
| El historial de versiones de tu builder | Nada | Versiona tu código, y tus datos viven en otro servicio. |
| Volver a preguntarle al agente | Nada | Nunca ha tenido una copia de tus filas. |
Todas las vías que devuelven algo comparten el mismo requisito, y es el que zanja esto: tenía que existir antes del borrado. Ninguna se enciende ahora y alcanza hacia atrás. El plan de Supabase que tengas decide las dos primeras, y comprobarlo lleva unos dos minutos.
Qué vuelve y qué cae en el hueco
La copia, tal como estaba, y nada de lo que pasó después.
Las filas creadas entre esa copia y el borrado no están dañadas ni escondidas en algún rincón incómodo. Nunca quedaron escritas en ningún sitio salvo en la base de la que se han quitado. Esa es la parte difícil de aceptar delante de una tabla vacía, porque perder algo suele querer decir que ese algo sigue estando en alguna parte.
Lo ancha que sea esa banda depende por completo de qué estuviera tomando las copias. Una copia nocturna puede meter dentro un día de trabajo entero. La recuperación a un momento concreto la estrecha a un minuto, y ese es casi todo el motivo de que cueste aparte. Un dump que hiciste el día que te acordaste mete dentro todo el tiempo transcurrido desde entonces.
Hay una versión de esto en la que el hueco casi no importa, en una app cuyos datos son sobre todo contenido tuyo y cambian despacio. Y hay una versión en la que importa mucho: cualquier cosa con pedidos, mensajes o registros, donde un día de filas es un día de personas que se van a dar cuenta.
El agente borró una parte, no todo
Entonces tienes una decisión de verdad, y ninguna de las dos respuestas es limpia.
Una restauración no devuelve las filas que faltan dejando el resto en paz. Sustituye las tablas de la copia por lo que aquellas tablas tenían entonces, por completo. Restaurar recupera lo que el agente quitó y revierte cada fila buena escrita desde entonces. No restaurar conserva las filas buenas y deja el agujero.
Cuál es la correcta depende de cuánto trabajo auténtico haya después de la copia. Si la respuesta es casi ninguno, restaura y sigue con tu día. Si la respuesta es tres días de fichas de clientes, suele ganar la vía lenta: exportar primero las filas supervivientes, restaurar, y luego volver a poner encima las filas exportadas. Es engorroso, y es el único camino que no pierde nada.
Es también el argumento para copiar la base en su estado roto actual antes de tocar nada. Decidas lo que decidas, quieres poder volver al estado del que partiste.
Cómo va esa misma hora cuando ya existe una copia
Más corta, y más una decisión que una búsqueda. Eliges una copia, miras qué guardaba y pulsas el botón.
Eso es lo que hace Reeve Care: copias comprobadas de tu base de Supabase según un calendario, cifradas y guardadas fuera de tu cuenta de Supabase, con una restauración en un clic detrás. Antes de que una restauración arranque, toma una copia fresca del estado actual, para que la propia restauración se pueda deshacer.
Los límites van en la misma frase, porque conocerlos es la forma de decidir si te encaja:
- Copia tu base de datos, y los archivos que subieron tus usuarios en cuanto conectas tus buckets de Storage. Es opcional y requiere una segunda clave.
- Hoy funciona con Supabase y con nada más.
- Restauras a una copia que existe, no a cualquier minuto que nombres. En el peor caso pierdes un intervalo, o sea hasta una noche en el plan de entrada y menos en los dos de encima.
- Las cuentas de acceso no se tocan nunca. A nadie se le cierra la sesión, se le borra ni se le devuelve.
- La clave de base de datos que guarda solo sabe leer, y esa fue la promesa cuando la conectaste. Volver a escribir datos necesita una que sepa escribir, así que una restauración te pide la contraseña de la base cada vez y no se queda con ninguna. La clave opcional para tus archivos sí sabe escribir, porque Supabase no emite ninguna de solo lectura para Storage, y la página donde la entregas lo dice antes.
Qué cubre cada plan está en la página de inicio. Si prefieres no
pagar por nada de esto, la versión sencilla de la misma protección es un
pg_dump con un calendario que cumplas de verdad, guardado en algún sitio que
perder tu cuenta de Supabase no se llevaría por delante.
Las tres vías y lo que se le escapa a cada una
lo repasa sin discurso de venta.
Esa hora está explicada, copia por copia, en la página de copias de Supabase.
Qué hacer ahora mismo
Qué hacer
- Para todo lo que escriba en la base. Es el único paso de aquí que sale más caro cuanto más lo dejes.
- Averigua qué copias existen antes de decidir nada: primero tu plan de Supabase, luego cualquier dump que hicieras tú, y luego si tu app lleva registro de las filas borradas.
- Copia la base tal como está ahora, rota y todo. Hagas lo que hagas después, quieres un camino de vuelta hasta aquí.
- Después de una restauración, comprueba que la app todavía puede escribir. Una base que lee bien y rechaza un insert es una restauración a medias, y solo un insert lo demuestra.
- Cuando pase lo urgente, monta la copia que habría convertido todo esto en un problema de diez minutos en lugar de una mañana.
Antes de cerrar esta pestaña, abre tu proyecto de Supabase y averigua si algo está copiando tu base, y apunta dónde vive esa copia. La checklist de seguridad en 10 minutos lo cubre junto con lo demás que conviene confirmar en una app recién lanzada.
Preguntas frecuentes
Un agente de IA borró filas de mi base de Supabase. ¿Puedo recuperarlas?
Solo desde una copia tomada antes de que se ejecutara, así que lo primero es averiguar si existe alguna. Mira qué incluye tu plan de Supabase, luego busca cualquier dump que hayas hecho tú, y luego comprueba si tu app guarda por casualidad un registro de las filas borradas. Si no existe nada de eso, las filas se han perdido, y ningún trabajo sobre la app va a cambiarlo. Averigua esto antes de escribir nada nuevo en la base.
¿Puedo pedirle al agente que devuelva los datos?
No. El agente nunca tuvo tus filas. Envió una instrucción a tu base y la base la ejecutó, así que lo que tiene ahora es la transcripción de la conversación, no una copia de la tabla. Pedirle que deshaga el borrado te da una respuesta segura de sí misma y ningún dato. Además supone una segunda sesión sin supervisión contra una base que ya ha perdido algo.
Estoy en el plan gratuito de Supabase. ¿Hay algo que recuperar?
De Supabase no. Las copias automáticas empiezan en los planes de pago, y la recuperación a un momento concreto es un añadido por encima, así que un proyecto gratuito no tiene una copia de ayer en ninguna parte. Queda un dump que hayas hecho tú, o una tabla de borrado suave o de auditoría que tu app ya estuviera escribiendo. Comprueba las dos antes de dar nada por perdido, y compruébalas antes de seguir usando la app.
¿Debo dejar la app funcionando mientras decido qué hacer?
Apaga todo lo que escriba. Leer no es problema. Las filas nuevas son un problema doble: restaurar una copia quita todo lo añadido después, así que un pedido que entre ahora es un dato que borrarás tú mismo más tarde, y una vuelta atrás a un momento concreto tiene más trabajo real que tirar cuanto más esperes. Un aviso de mantenimiento durante una hora cuesta menos que la segunda pérdida.
El agente borró algunas filas pero no todas. ¿Restauro igualmente todo?
Ese es el caso incómodo, y no hay una respuesta limpia. Una restauración sustituye por completo las tablas de la copia, así que devuelve lo que perdiste y a la vez revierte cada fila buena escrita desde entonces. Cuál elegir depende de cuánto trabajo real haya después de la copia. Si es mucho, exportar primero las filas supervivientes y volver a ponerlas encima de la restauración es más lento y no pierde nada.