Respaldos de Supabase por plan y cómo tener los tuyos

En Supabase, el plan Free no incluye respaldos automáticos; Pro guarda respaldos diarios de los últimos 7 días, Team de 14 y Enterprise de hasta 30. La recuperación a un punto en el tiempo (PITR) es un complemento pago que permite volver a un momento exacto de los últimos días en lugar del último respaldo diario. Ninguno incluye los archivos de Storage, y si eliminas el proyecto se eliminan también sus respaldos, así que toda app con usuarios reales debería guardar además su propia copia fuera de Supabase.

En esta guía verás qué te da cada plan, qué implica restaurar, qué dejan afuera los respaldos y una rutina sencilla para tener copias propias.

¿Qué respalda cada plan de Supabase?

Según la documentación de respaldos de Supabase y su página de precios:

La documentación recomienda expresamente que los proyectos Free exporten sus datos con regularidad usando la CLI de Supabase y guarden copias en otro lugar. Si tu app nació como prototipo en el plan Free y ahora tiene clientes que pagan, esto es lo primero que debes resolver.

Respaldos diarios significa que puedes perder hasta un día de datos. Si la base se restaura al respaldo de esta mañana, todo lo escrito después (registros, pedidos, mensajes) se pierde.

¿Qué agrega la recuperación a un punto en el tiempo?

PITR guarda un registro continuo de los cambios, así que puedes restaurar a un segundo concreto y no solo al último respaldo. Según la documentación:

• Está disponible como complemento en Pro, Team y Enterprise, y requiere como mínimo el complemento de cómputo Small.
• Los cambios se archivan cada dos minutos o antes, así que en el peor caso pierdes unos dos minutos de datos.
• El precio depende de cuánto hacia atrás puedes volver: alrededor de 100 dólares al mes por 7 días, 200 por 14 y 400 por 28, aparte del cómputo.
• Al activar PITR, reemplaza a los respaldos diarios.

¿Vale la pena? Una prueba simple: si perder un día de pedidos, reservas o contenido de usuarios te costaría más que el complemento, sí. Para una herramienta interna o una app cuyos datos podrías reconstruir, suelen bastar los respaldos diarios más tus propias exportaciones.

¿Qué no incluyen los respaldos de Supabase?

Aquí aparecen las sorpresas.

• Los archivos de Storage. El respaldo incluye la base de datos, con los metadatos de tus archivos, pero no los archivos. Restaurar un respaldo viejo no recupera imágenes ni documentos borrados. Necesitas tu propia copia de los buckets importantes.
• Las contraseñas de roles propios. Si creaste roles de Postgres propios, sus contraseñas no quedan en los respaldos diarios y hay que restablecerlas después de restaurar.
• Nada después de eliminar el proyecto. Eliminar un proyecto borra para siempre sus datos y sus respaldos.
• Tu código y la configuración fuera de la base. El código de las Edge Functions, la configuración de Auth y las variables de entorno viven en otro lado. Guarda el código en Git y anota la configuración.

¿Qué pasa cuando restauro?

La restauración se inicia desde Database > Backups en el panel. Eliges el respaldo (o el momento, con PITR) y confirmas. Mientras corre, el proyecto no está disponible, y el tiempo de caída crece con el tamaño de la base. Antes de restaurar, la documentación indica eliminar las suscripciones o slots de replicación que hayas creado y volver a crearlos después.

Una restauración reemplaza la base entera. Si solo necesitas recuperar unas cuantas filas borradas, es más seguro restaurar en un proyecto nuevo (Supabase lo llama duplicar o clonar un proyecto) y copiar de vuelta solo lo que hace falta.

¿Cómo tengo mis propios respaldos?

La CLI de Supabase usa pg_dump por dentro y genera archivos SQL que puedes guardar donde quieras. Necesitas la CLI, Docker funcionando y la cadena de conexión de tu base (la del session pooler, que aparece en el diálogo Connect, sirve en la mayoría de las redes). Siguiendo la guía de respaldo y restauración:

supabase db dump --db-url "$DB_URL" -f roles.sql --role-only
supabase db dump --db-url "$DB_URL" -f schema.sql
supabase db dump --db-url "$DB_URL" -f data.sql --use-copy --data-only \
  -x "storage.buckets_vectors" -x "storage.vector_indexes"

Obtienes tres archivos: roles, estructura y datos. Las dos opciones -x excluyen tablas internas, igual que en el ejemplo de la guía. Guarda la cadena de conexión en una variable de entorno y nunca en scripts que subas al repositorio.

Conviértelo en rutina

1. Prográmalo. Ejecuta los comandos a diario desde una tarea programada de CI o un servidor pequeño. Un workflow programado de GitHub Actions funciona bien, con la cadena de conexión guardada como secreto cifrado.
2. Guarda las copias fuera de Supabase, en un almacenamiento que controles en otra cuenta, y conserva varios días o semanas de historial.
3. Cifra los archivos. Contienen los datos de tus usuarios; trátalos con el mismo cuidado que la base.
4. Copia los buckets de Storage por separado. Supabase Storage ofrece un endpoint compatible con S3, así que las herramientas habituales de S3 pueden sincronizar los buckets a otro lugar. Busca los datos de conexión en la configuración de Storage de tu proyecto.
5. Prueba una restauración. Un respaldo que nunca restauraste es una suposición. Cada pocos meses, crea un proyecto vacío, carga los archivos con psql como indica la guía y abre la app contra esa base.

Si usas Supabase Vault o columnas cifradas, la guía advierte que la clave de cifrado debe pasar al proyecto nuevo; si no, los secretos restaurados no se pueden descifrar.

¿Qué más me protege de perder datos?

Los respaldos son la última barrera. Las causas más comunes de pérdida de datos en apps hechas con IA son una migración que borra una columna, un agente de IA que ejecuta una consulta destructiva o una clave de administrador en el lugar equivocado. Hacer los cambios de esquema con migraciones con la CLI de Supabase, tener un entorno de pruebas (staging) y mantener las claves secret fuera del frontend evita la mayoría. Si un agente ya borró algo, empieza por qué hacer si el agente de IA borró archivos.

Respuestas rápidas

¿Puedo descargar los respaldos automáticos? Aparecen en el panel, pero no todos los tipos se pueden descargar. Tus propios archivos de supabase db dump son la copia externa confiable.

¿Pausar un proyecto Free borra mis datos? No: un proyecto pausado se puede restaurar, aunque solo por un tiempo limitado. Lo vemos en proyecto de Supabase pausado en el plan gratis.

¿Cada cuánto hago mi propio respaldo? Al menos una vez al día si la app tiene usuarios activos, y siempre justo antes de una migración riesgosa.

¿PITR reemplaza a mis propios respaldos? No. Vive dentro del mismo proyecto y la misma cuenta. Las copias externas te protegen de problemas con la cuenta o de que alguien elimine el proyecto.

¿No tienes claro si tus datos están a salvo?

La revisión gratuita de tu app te da una primera mirada desde afuera. Si quieres revisar bien respaldos, restauración y claves, eso es parte de nuestra revisión de seguridad de Supabase, y los planes de mantenimiento pueden vigilarlo mes a mes. Puedes escribirnos desde contacto.