Cómo restaurar un backup de Supabase, y qué se rompe después

Algo va mal en tu base de datos y, por una vez, tienes una copia. Ahora estás mirando un botón que no has pulsado nunca, en un proyecto con usuarios reales dentro, tratando de averiguar qué está a punto de hacerles.

Esta es la parte que guía tras guía se salta. Casi todos los artículos sobre cómo restaurar un backup de Supabase terminan en el momento en que acaba la restauración, y ahí es donde empiezan casi todos los problemas. El desenlace habitual no es una restauración que falla. Es una que funciona y deja la app rota igualmente, porque una copia de la base nunca contuvo más que la base.

Ayuda dejar de imaginar esto como recuperar tus datos. Una restauración cambia tu base de datos por una más antigua, más parecido a sustituir un archivador entero que a devolver una carpeta a su sitio. Todo lo que sigue se deduce de ahí.

¿Cómo restauro un backup de Supabase?

Tres caminos, y cuál de ellos tienes abierto hoy se decidió antes de hoy.

Los dos primeros dejan tus datos donde ya estaban. El tercero es el único que puede ponerlos en otro sitio, que es lo que necesitas el día en que el problema es tu cuenta y no tus datos.

Si no tienes claro cuál de estos tienes, el plan de Supabase que tengas decide los dos primeros y comprobarlo lleva unos dos minutos.

Copia lo que tienes ahora, antes de restaurar nada

Toma primero una copia de la base en su estado roto actual. Es un solo comando, y es lo que hace reversible cada decisión posterior.

pg_dump "postgresql://…tu cadena de conexión…" \
  --clean --if-exists --no-owner \
  --file before-restore-2026-08-24.sql

Hay dos razones, y la segunda la suele aprender la gente después.

La primera es que una restauración es un reemplazo. Las tablas de la copia vuelven exactamente como estaban, así que se va con ellas cada fila escrita desde entonces. Un cliente que se registró esta mañana es una fila que estás a punto de borrar a propósito.

La segunda es que tu base rota sigue siendo el único sitio donde existen algunos de tus datos. Si la copia es del martes y el daño ocurrió el jueves, todo lo creado el miércoles está delante de ti ahora mismo y en ningún otro sitio. Restaura encima y desaparece por segunda vez, esta vez de tu mano y no por el accidente.

Mientras trabajas, apaga todo lo que escriba filas nuevas. El razonamiento es el mismo que tras cualquier borrado accidental: el hueco entre la copia y ahora se encarece cuanto más tiempo lo siga llenando la app.

Restaurar desde el panel de Supabase

Esto reemplaza la base de tu proyecto por la copia que elijas, y el proyecto no está disponible mientras dura.

Abre el proyecto con el que habla tu app, ve a Database y luego Backups, y elige la copia con fecha que quieras. Los pasos exactos léelos en la documentación de backups de Supabase, porque el panel se reorganiza y esta página no se enterará cuando pase.

Cuánto tarda depende del tamaño de tu base, que es la respuesta de Supabase. Pon un aviso de mantenimiento antes de empezar.

Point-in-time recovery es la misma operación con un dial más fino. En lugar de elegir anoche, indicas un minuto y el proyecto retrocede hasta ahí. Supabase lo describe como destructivo, que es la palabra correcta. Sus notas de soporte añaden que una restauración point-in-time no puede arrancar hasta que se eliminen las suscripciones y las ranuras de replicación existentes, así que si algo en tu app recibe cambios de la base a medida que ocurren, ese es un paso previo en vez de un error a mitad de camino.

Ninguno de los dos caminos puede llevar tus datos a otro proyecto. Los dos actúan sobre el proyecto en el que estás, lo que significa que ninguno está disponible el día en que lo que falla es tu acceso a la cuenta.

Restaurar un archivo de volcado con psql

Apuntas psql a un proyecto y reproduces el archivo dentro. Ese proyecto puede ser el que tenías, o uno recién creado en una cuenta que abriste esta mañana.

psql -d "postgresql://…cadena de conexión del proyecto destino…" \
  --variable ON_ERROR_STOP=1 \
  --single-transaction \
  --file backup-2026-08-09.sql

Dos de esas opciones conviene entenderlas, porque el comportamiento por defecto de psql es el sorprendente.

ON_ERROR_STOP=1 se detiene en el primer error. Sin ella, psql lee el error, lo imprime y sigue con la línea siguiente, así que un archivo que falló en la línea 400 de 30.000 acaba igualmente en un prompt con aspecto de éxito, sobre una base a la que le falta todo lo posterior a esa línea. --single-transaction envuelve el archivo entero en una sola operación, de modo que un fallo deja la base como estaba en lugar de a medias.

Luego las credenciales, que es donde se atasca mucha gente. Reproducir un backup es escribir, así que hace falta algo que pueda escribir. Una clave anon no sirve, y una de solo lectura tampoco. Lo que psql quiere es la contraseña de base de datos del proyecto de destino, que está en los ajustes de tu proyecto de Supabase, en Database.

Lo que vuelve depende de lo que haya en el archivo, y eso quedó decidido cuando se tomó el volcado. Tus cuentas de acceso son la parte que conviene revisar antes de fiarte. Viven en un esquema llamado auth junto a las contraseñas cifradas, y Supabase documenta moverlas entre proyectos como un trabajo con sus propios pasos. Si vas a restaurar en un proyecto nuevo y quieres que la gente entre con la contraseña que ya tiene, lee esa página antes de empezar.

Y un proyecto nuevo tiene una URL nueva y claves nuevas. Tu app sigue apuntando al antiguo hasta que lo cambies, que es la primera línea de la sección siguiente.

Restauró, y la app sigue rota

Este es el desenlace normal. Casi siempre es una de cinco cosas, y la primera cuesta un minuto.

La cuarta merece la atención. El permiso de lectura y el de escritura se conceden por separado, y una restauración puede acertar uno y fallar el otro. Así que las páginas se llenan con tus datos, todo parece recuperado, y entonces la primera persona que envía un formulario recibe un error. Mirar la app no te lo enseñará nunca, porque mirar es leer.

Cómo saber si la restauración funcionó de verdad

Inicia sesión, encuentra una fila que puedas nombrar y luego escribe una. En ese orden, y la última es la comprobación que cuenta.

• Inicia sesión desde la app como lo haría un usuario, en vez de abrir el editor de tablas de Supabase. Eso prueba la app, la conexión y las cuentas de acceso de una vez.
• Encuentra una fila que recuerdes. Un pedido concreto, un cliente con nombre, lo último que añadiste antes de que se rompiera. "Los datos parecen estar ahí" es una sensación; una fila que puedes nombrar es una comprobación.
• Compara un recuento con lo que esperabas. Abre tu tabla más grande en el editor de Supabase y lee el número de filas. Una restauración que se paró a medias suele aparecer aquí como un número más pequeño de la cuenta.
• Y entonces escribe algo. Crea una fila como lo hace un usuario: haz un pedido de prueba, guarda un perfil, publica un comentario. Esta es la comprobación que falla cuando las otras tres pasan, y lo único que demuestra que la restauración terminó.
• Abre algo que haya subido un usuario. Si tu app tiene imágenes o adjuntos, haz clic en uno. Que hayan vuelto tus archivos es una pregunta aparte de si han vuelto tus filas.

Qué hacer ahora mismo

Antes de cerrar esta pestaña, averigua si tienes siquiera algo desde lo que restaurar, y dónde está. Esa única respuesta decide qué mitad de este artículo vas a necesitar alguna vez. La lista de seguridad de 10 minutos lo cubre junto con lo demás que conviene confirmar en una app recién lanzada, y la guía de seguridad de Supabase repasa qué se suele dejar abierto.

Qué hace Reeve Care el día que restauras

La copia ya existe, ya se ha vuelto a leer y comprobar, y está fuera de tu cuenta de Supabase. Eso convierte la hora de arriba en una decisión sobre qué copia, y un botón.

Cuatro cosas que cambia sobre este artículo en concreto.

La copia está verificada antes de que la necesites. Cada backup se lee de vuelta y se cuenta contra lo que entró, y la fecha que ves en tu panel es la de la última copia que pasó la comprobación, no la del último intento. La restauración a medias contra la que avisa este artículo es un problema que encontramos una tarde cualquiera, antes de que sea tuyo.

La copia de seguridad previa no es un paso que tengas que recordar. Pulsar restaurar toma antes una copia fresca del estado actual, de modo que la propia restauración se puede deshacer.

Tus archivos subidos también vuelven, en cuanto conectas tus buckets de Storage. Esa es la fila de la tabla de arriba que si no no tiene buena respuesta.

La clave de base de datos que guardamos solo puede leer. Una restauración tiene que escribir, así que pide tu contraseña de base de datos cada vez y no guarda ninguna. La clave opcional para tus archivos sí puede escribir, porque Supabase no emite una de solo lectura para Storage, y la página donde la entregas lo dice antes de que lo hagas.

Los límites van en la misma frase, porque conviene conocerlos antes de pagar y no durante una caída:

• Funciona con Supabase y hoy con nada más.
• Restauras a una copia que existe, no a cualquier minuto que digas. En el peor caso pierdes un intervalo, que es hasta una noche en el plan de entrada y menos en los dos de arriba.
• Las cuentas de acceso no se tocan nunca. Nadie sale de su sesión, ni se borra, ni vuelve.

Deja tus backups de Supabase encendidos igualmente. Dos copias en dos sitios es la idea entera, y la más barata de las dos ya está en tu plan. Qué cubre cada plan de Care está en la página de inicio.

Si prefieres no pagar por nada de esto, todo lo de este artículo sigue funcionando. Un pg_dump con una periodicidad que cumplas de verdad, guardado en un sitio que perder tu cuenta de Supabase no se lleve por delante, más una restauración de práctica al trimestre, te lleva casi todo el camino. Los tres caminos y qué se deja cada uno lo cuenta sin argumento de venta.

El ciclo completo está dibujado paso a paso en la página de backups de Supabase: la copia saliendo de Supabase, la comprobación que la sigue y el botón que la devuelve.