Cómo hacer una copia de seguridad de la base de datos de tu app (y restaurarla de verdad)

Para hacer copia de seguridad de la base de datos de tu app, expórtala a un archivo según un calendario (en Postgres, la herramienta estándar es pg_dump), guarda las copias en un lugar separado de la base de datos y restaura periódicamente una de ellas en una base de datos vacía para comprobar que funciona. Haz una copia extra justo antes de cualquier cambio arriesgado. La copia de tu código, ya sea un repositorio de GitHub o una exportación, no incluye tus datos.

Esta guía es para quien tiene una app pequeña y quiere dejar de preocuparse por perderla. Usa Postgres en los ejemplos, porque la mayoría de las apps creadas con IA lo utilizan, pero los principios sirven para cualquier base de datos.

Qué debe cubrir una copia de seguridad

Una app es más que su base de datos. Conoce qué parte protege cada copia.

Los datos son la parte que no puedes recrear. El código se puede reescribir y los ajustes se pueden volver a introducir; los pedidos de tus clientes, no.

Paso 1: decide cuántos datos puedes perder

Dos preguntas determinan tu plan de copias:

• ¿Cuántos datos recientes puedes permitirte perder? Si haces una copia al día y la base de datos falla por la tarde, pierdes los cambios de ese día. Para una app de pruebas personales es aceptable. Para una app que recibe pedidos, puede que no lo sea.
• ¿Cuánto tiempo puede estar caída la app mientras restauras? Una base de datos pequeña se restaura en minutos. Una grande puede tardar mucho más, y conviene saberlo antes de necesitarla.

Para la mayoría de las apps pequeñas, una copia automática diaria más una manual antes de los cambios arriesgados es un buen punto de partida. Las apps que manejan dinero o datos de salud necesitan copias más frecuentes, o una base de datos gestionada con recuperación a un punto en el tiempo (la capacidad de restaurar a cualquier momento, no solo a la última copia).

Paso 2: revisa lo que ya hace tu proveedor

Muchos proveedores de bases de datos gestionadas hacen copias automáticas. Averigua:

• ¿Las copias están activadas en tu plan y con qué frecuencia se ejecutan?
• ¿Cuánto tiempo se conservan?
• ¿Puedes restaurar a un punto en el tiempo o solo a una instantánea diaria?
• ¿Puedes descargar una copia o solo restaurarla dentro de su sistema?

Las copias del proveedor son útiles, pero comparten un punto único de fallo con tu base de datos: la cuenta. Si la cuenta se cierra, se suspende o se elimina el proyecto, las copias pueden desaparecer con ella. Por eso también necesitas una copia propia.

Paso 3: haz un volcado con pg_dump

pg_dump exporta una base de datos de Postgres a un archivo. Lee una instantánea coherente, así que la app puede seguir funcionando mientras trabaja.

Un comando típico, usando la cadena de conexión que tu app ya tiene en una variable de entorno:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Qué hacen las opciones:

• --format=custom escribe un archivo comprimido que pg_restore puede leer, y permite restaurar tablas individuales más adelante. Usa --format=plain si prefieres un archivo .sql legible.
• --no-owner omite los comandos de propiedad, lo que simplifica restaurar en una base de datos distinta.
• La fecha en el nombre del archivo mantiene las copias separadas.

La versión de pg_dump debe ser igual o más reciente que la versión de Postgres de tu base de datos. Un pg_dump más antiguo puede negarse a ejecutarse.

Si creas con IA y no quieres tocar la línea de comandos, puedes pedir:

Crea una copia de seguridad de la base de datos de la app con pg_dump en formato custom, con la fecha de hoy en el nombre del archivo. No muestres la cadena de conexión ni ningún secreto. Dime el nombre del archivo y su tamaño cuando termine.

Paso 4: automatízalo

Las copias manuales se olvidan. Automatízalas con lo que permita tu configuración:

• Las copias programadas de tu proveedor de bases de datos, si lo ofrece.
• Una tarea programada en un servidor o en un servicio de CI que ejecute pg_dump y suba el archivo a un almacenamiento.
• Un servicio de copias alojado que se conecte a tu base de datos.

Elijas lo que elijas, haz que te avise cuando una copia falle. Una tarea de copias que ha fallado en silencio durante tres meses es la típica historia de terror.

Paso 5: guarda copias en otro lugar

La regla general se conoce como 3-2-1: tres copias de tus datos, en dos tipos distintos de almacenamiento, con una copia fuera de tu sitio. Para una app pequeña, una versión práctica es:

• La base de datos activa
• Las copias automáticas del proveedor
• Tus propios volcados en un almacenamiento separado, como un bucket de almacenamiento de objetos en otra cuenta

Además:

• Restringe el acceso. Una copia contiene los datos de todos los usuarios. Trátala como la base de datos activa.
• Define una política de retención. Por ejemplo, copias diarias durante dos semanas y mensuales durante un año. Borra las antiguas a propósito, y recuerda que las leyes de privacidad pueden obligarte a eliminar los datos personales cuando se solicite.
• Nunca subas copias a Git. Un volcado en un repositorio es una fuga de datos esperando a ocurrir.

Paso 6: prueba una restauración

Una copia solo es tan buena como tu última restauración correcta. Al menos cada pocos meses, y después de cualquier cambio en el proceso de copias:

1. Crea una base de datos nueva y vacía. Nunca restaures encima de la activa para hacer la prueba.
2. Restaura la copia más reciente en ella:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Para un archivo .sql plano, usa psql "$TEST_DATABASE_URL" -f backup.sql.

1. Comprueba que existe cada tabla, compara el número de filas con la base de datos activa y revisa algunos registros recientes.
2. Conecta una copia de la app a ella e inicia sesión, si puedes.
3. Anota cuánto tardó la restauración. Ese es tu tiempo real de recuperación.

Paso 7: haz copias antes de los cambios arriesgados

Haz una copia nueva justo antes de:

• Ejecutar una migración de base de datos que elimine o renombre columnas
• Importar datos en bloque
• Dejar que un agente de IA haga cambios grandes en el modelo de datos
• Borrar registros antiguos

En una app creada con IA, el agente puede cambiar la estructura de las tablas como parte de una función. Los puntos de control y el control de versiones revierten tu código, pero no recuperan las filas borradas. Una copia de treinta segundos antes de un cambio grande es un seguro barato.

Errores comunes

• Pensar que Git o una exportación de código son una copia de seguridad. Tienen el código, no los datos.
• No probar nunca una restauración. Muchas copias resultan estar vacías, incompletas o ilegibles justo cuando se necesitan.
• Guardar las copias en la misma cuenta que la base de datos. Una cuenta comprometida o cerrada pierde las dos cosas.
• Olvidar los archivos subidos. La base de datos guarda la ruta del archivo; la imagen en sí está en el almacenamiento.
• Dejar secretos en los scripts de copia. Lee la cadena de conexión desde una variable de entorno, nunca desde el texto del script. Consulta cómo mantener seguras tus claves de API.

Copias de seguridad y Mythex

Los proyectos de Mythex pueden tener una base de datos Postgres dedicada, y sus datos de conexión se inyectan en el espacio de trabajo y en la app publicada. La documentación de Mythex no describe una función de copia o restauración de la base de datos, así que planifica la tuya: pídele al agente que haga un volcado, descárgalo y guárdalo en un lugar seguro, sobre todo antes de los cambios grandes. Una exportación del proyecto (Pro) contiene tu código, sin los secretos ni node_modules; no contiene las filas de la base de datos. Consulta Base de datos y Propiedad de los datos en la documentación. Para saber más sobre la base de datos en sí, lee qué es Postgres.

Lista de verificación de copias de seguridad

• Decidido cuántos datos puedes permitirte perder y cuánto tiempo puedes estar caído
• Revisado qué copias automáticas ofrece tu proveedor de base de datos
• Tu volcado propio se ejecuta según un calendario, y los fallos te avisan
• Copias guardadas separadas de la base de datos, con acceso restringido
• Política de retención escrita
• Archivos subidos incluidos en la copia, además de la base de datos
• Restauración probada en una base de datos vacía, con el número de filas comprobado
• Copia hecha antes de cada cambio arriesgado

Preguntas