Reeve Backups
Tres formas de respaldar una base Supabase, y qué falta en cada una
El panel, pg_dump y un servicio gestionado. Qué guarda de verdad cada uno, qué deja fuera sin avisar y cuál sobrevive a perder la cuenta.
En resumen
- Los backups del propio Supabase son los más fáciles de activar y los peores para confiar: la copia vive dentro de la cuenta que podrías perder.
- pg_dump es gratis y completo, y solo ocurre cuando te acuerdas. Acordarse es la parte que falla.
- Ninguna de las tres respalda tus archivos de Storage. Eso es un trabajo aparte tomes la ruta que tomes.
Todo el que construye sobre Supabase acaba haciéndose la misma pregunta, más o menos una semana después de lanzar y casi siempre a las dos de la mañana: si rompo algo, ¿puedo recuperar mis datos?
La respuesta depende por completo de cuál de las tres rutas tomaste, y a cada una se le escapa algo que las otras dos sí cubren.
¿Cuál debería usar?
Activa lo que te dé tu plan de Supabase y luego guarda una copia en otro sitio. Son dos trabajos distintos, y hacer solo el primero es justo el error que este artículo existe para evitar.
El backup del panel te protege de tus propios errores. Una copia que tienes tú te protege de perder la cuenta: un cobro fallido, un proyecto suspendido, una contraseña que no puedes recuperar. Son desastres distintos y piden respuestas distintas.
| Panel de Supabase | pg_dump a mano | Backups gestionados | |
|---|---|---|---|
| Funciona sin ti | Sí | No | Sí |
| La copia es tuya | No | Sí | Sí |
| Sobrevive a perder la cuenta | No | Sí | Sí |
| Comprobado antes de contar | No | No | Sí |
| Coste | Solo en planes de pago | Gratis | Una suscripción |
Qué contiene de verdad un backup
Tus tablas, tus filas, tus índices y funciones y tus reglas de Row Level Security, las políticas que deciden quién puede leer qué, no solo las tablas a las que se aplican. Eso es todo.
Lo que no contiene es todo lo que nunca estuvo en la base de datos:
| En el archivo | Fuera del archivo |
|---|---|
| La estructura de las tablas, con cada columna y restricción | Archivos en Storage: subidas, avatares, adjuntos |
| Cada fila que crearon tus usuarios | Ajustes de autenticación, como tu app de Google o GitHub |
| Índices y funciones | Edge functions, que viven en tu repositorio |
| Políticas de Row Level Security |
Con lo que tropieza la gente es con Storage. Cada avatar, cada PDF subido, cada imagen que añadieron tus usuarios vive en almacenamiento de objetos, no en la base de datos. La base solo guarda la ruta de cada archivo. Restaura un backup en un proyecto vacío y tendrás una tabla llena de enlaces a archivos que no están.
Ruta 1: el panel de Supabase
La más fácil, y la que casi todo el mundo debería activar primero. Supabase hace backups diarios en los planes de pago, y la recuperación a un punto en el tiempo está disponible como extra si necesitas rebobinar a un minuto concreto en lugar de a la medianoche pasada.
En qué es buena: funciona sin ti, es completa, y restaurar son unos clics en una interfaz en vez de un comando que tienes que acertar bajo presión.
Qué se le escapa: la copia vive dentro de la cuenta. Si el proyecto queda suspendido, la tarjeta falla o pierdes el acceso al login, los backups están detrás de la misma puerta que aquello que protegían. Es una salida de incendios dentro del edificio.
Además no existe en el plan gratuito, que es donde están la mayoría de las apps recién lanzadas.
En qué plan estés decide si tienes esto siquiera, y comprobarlo lleva dos minutos.
Ruta 2: pg_dump en tu propia máquina
Supabase es Postgres, así que la herramienta estándar de Postgres funciona.
pg_dump escribe la base entera en un archivo que tienes tú.
pg_dump "postgresql://…tu cadena de conexión…" \
--clean --if-exists --no-owner \
--file backup-2026-08-09.sql
En qué es buena: es gratis, es completa, el archivo es tuyo, y puedes restaurarlo en un proyecto nuevo de otra cuenta. De las tres rutas, esta es la única que sobrevive a perder todo lo demás.
Qué se le escapa: solo ocurre cuando te acuerdas. No es un tecnicismo, es el fallo entero. El dump de tu portátil lleva la fecha del último día que pensaste en ello, y el día que lo necesitas nunca es un día en el que estuvieras pensando en ello.
Hay un segundo problema, más callado: un dump sin probar es una suposición. Un archivo escrito mientras una migración estaba a medias, o que se cortó en silencio porque cayó la conexión, se ve exactamente igual que uno bueno hasta el día que intentas usarlo.
Ruta 3: backups gestionados
Otra cosa se encarga de sacar la copia con un horario, la guarda fuera de tu cuenta y comprueba que la copia es real antes de darla por hecha. Esa última parte es la que de verdad importa.
Eso es lo que hace Reeve Care: varias copias al día según el plan, cifradas y guardadas fuera de tu cuenta de Supabase, cada una verificada contando lo que salió contra lo que entró. Un backup no cuenta como hecho hasta que se ha verificado, y por eso la fecha que aparece en el panel es la de la última copia verificada y no la del último intento.
El intercambio honesto: cuesta dinero y es un servicio más en tu stack. Si eres lo bastante disciplinado para llevar la ruta 2 con un horario real y probar las restauraciones, no lo necesitas.
El ciclo completo está en la página de copias de Supabase: la copia que sale de Supabase, la verificación que viene después y el botón que la devuelve.
¿Alguna vez has restaurado uno?
Esa pregunta decide si tienes un backup o un archivo que nadie ha abierto nunca. Un dump que nadie ha leído de vuelta es una suposición sobre el futuro, y el momento en que descubres que era falsa es el momento en que necesitabas que fuese cierta.
Una prueba de restauración no tiene que ser dramática. Crea un proyecto nuevo de Supabase, carga en él tu backup más reciente, abre la app contra ese proyecto y comprueba que hay una fila que reconoces. Media hora, una vez por trimestre. Si la restauración falla, te has enterado un martes por la tarde en vez de durante una caída.
Si quieres la lista más amplia de cosas que conviene revisar en una app recién lanzada, la checklist de seguridad de 10 minutos cubre los backups junto al resto, y la guía de seguridad de Supabase repasa qué más se suele dejar abierto.
Qué hacer esta semana
Qué hacer
- Activa el backup que incluya tu plan de Supabase. Es lo más barato de esta lista y lleva alrededor de un minuto.
- Haz hoy un
pg_dumpy deja el archivo en algún sitio que no sea tu portátil. Incluso una copia vieja gana a ninguna copia. - Respalda tus archivos de Storage por separado. Ningún backup de base de datos de estas rutas los incluye.
- Haz una restauración en un proyecto desechable, para que la próxima vez que leas ese archivo no sea la primera.
- Decide cuántos datos podrías soportar perder, y elige la frecuencia a partir de esa cifra y no de lo que parece responsable.
Para leer después: si dabas por hecho que el deshacer de tu builder cubría tus datos, el historial de versiones no es un backup es el primero que conviene leer. Después de eso, tu base de datos es tan privada como las claves que tiene delante, y qué claves de API son seguras en tu frontend trata la que se salta cada regla que pongas.
Preguntas frecuentes
¿El plan gratuito de Supabase incluye backups?
No. Los backups diarios empiezan en el plan Pro, y la recuperación a un punto en el tiempo es un extra por encima. En el plan gratuito no hay ninguna copia automática de tus datos en ninguna parte, lo que sorprende a casi todo el mundo la primera vez que la necesita.
¿Un backup es lo mismo que el historial de versiones de mi builder?
No, y este es el malentendido más caro de este artículo. Lovable, Bolt y los demás versionan tu CÓDIGO. Tu base de datos es un servicio aparte con tus usuarios, sus contenidos y sus pedidos. Volver el código a ayer no vuelve atrás tus datos, y borrar una tabla en el editor de Supabase deja tu código perfectamente intacto.
¿Cada cuánto debería respaldar?
Pregúntate mejor cuánto estás dispuesto a volver a teclear. Si perder un día de registros fuese molesto, cada noche basta. Si perder una hora de pedidos supusiera devolver dinero, necesitas algo más cercano a cada hora. La prueba honesta no es la frecuencia, es si alguna vez has restaurado uno.
¿Necesito respaldar si mi app casi no tiene usuarios?
Ese es el momento más barato para empezar, porque los datos son pocos y lo que importa es la costumbre. Las pérdidas dolorosas rara vez son dramáticas. Son un borrado 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.