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

Para hacer una copia de seguridad de la base de datos de tu app, exporta los datos a un archivo con una periodicidad fija (en Postgres, la herramienta estándar es pg_dump), guarda las copias en un lugar separado de la base de datos y restaura una de vez en cuando 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.

Qué	Dónde está	Cómo hacer la copia
Código	Archivos del proyecto, Git	Sincronización con GitHub o exportación del proyecto
Datos (usuarios, registros)	La base de datos	Volcado de la base de datos de forma programada
Archivos subidos	Almacenamiento de objetos	Copiar el bucket, o guardar los originales en otro lugar
Secretos y ajustes	Ajustes del proyecto, paneles de los proveedores	Un gestor de contraseñas, siempre actualizado

Los datos son la parte que no se puede 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 podrías perder

Dos preguntas definen tu plan de copias:

¿Cuántos datos recientes te puedes permitir perder? Si haces una copia al día y la base de datos falla por la tarde, pierdes los cambios de ese día. En una app de aficionado eso es aceptable. En una app que recibe pedidos, puede que no.
¿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 necesitarlo.

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 merecen copias más frecuentes, o una base de datos gestionada con recuperación a un punto en el tiempo (la posibilidad de restaurar a cualquier momento, no solo a la última copia).

Paso 2: comprueba 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 hacen?
¿Cuánto tiempo se conservan?
¿Puedes restaurar a un punto concreto 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 único punto de fallo con tu base de datos: la cuenta. Si la cuenta se cierra, se suspende o se borra 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 tanto.

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 te permite restaurar tablas sueltas más adelante. Usa --format=plain si prefieres un archivo .sql legible.
--no-owner omite los comandos de propiedad, lo que simplifica restaurar en otra base de datos.
La fecha del nombre del archivo mantiene las copias separadas.

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

Si creas tu app 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 al almacenamiento.
Un servicio de copias alojado que se conecte a tu base de datos.

Sea cual sea la opción, haz que te avise cuando una copia falle. Una tarea que lleva tres meses fallando en silencio es la historia de terror clásica.

Paso 5: guarda copias en otro sitio

La regla práctica suele llamarse 3-2-1: tres copias de tus datos, en dos tipos distintos de almacenamiento, y una de ellas fuera de tu entorno principal. Para una app pequeña, una versión práctica es:

La base de datos en producción
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 en directo.
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 si el usuario lo pide.
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. Como mínimo cada pocos meses, y después de cualquier cambio en el proceso de copias:

Crea una base de datos nueva y vacía. Nunca restaures sobre la base de datos real para hacer la prueba.
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 en su lugar.

Comprueba que existe cada tabla, compara el número de filas con la base de datos real y revisa algunos registros recientes.
Apunta una copia de la app a esa base de datos e inicia sesión, si puedes.
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 la 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 funcionalidad. 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 muy barato.

Errores comunes

Dar por hecho que Git o una exportación de código es una copia de seguridad. Tiene el código, no los datos.
No probar nunca una restauración. Muchas copias resultan estar vacías, incompletas o ilegibles justo cuando hacen falta.
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: pide al agente que haga un volcado, descárgalo y guárdalo en un lugar seguro, sobre todo antes de cambios grandes. Una exportación del proyecto (Pro) contiene tu código, sin secretos ni node_modules; no contiene los registros 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 comprobación de copias

Decidido cuántos datos te puedes permitir perder y cuánto tiempo puedes estar caído
Comprobado qué copias automáticas ofrece tu proveedor de base de datos
Tu volcado propio se ejecuta de forma programada, 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 las copias, 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

¿Con qué frecuencia debo hacer una copia de seguridad de la base de datos de mi app?

Ajústala a cuántos datos te puedas permitir perder. En la mayoría de apps pequeñas, una copia automática diaria es un mínimo razonable, más una copia manual antes de cualquier cambio arriesgado, como una migración, una importación o una funcionalidad nueva importante.

¿Exportar mi código es lo mismo que hacer una copia de mis datos?

No. Una exportación de código o un repositorio de GitHub contiene los archivos de tu app, no las filas de tu base de datos. Tus usuarios, pedidos y publicaciones viven en la base de datos y necesitan su propia copia.

¿Qué es pg_dump?

pg_dump es la herramienta de línea de comandos estándar que viene con Postgres para exportar una base de datos a un archivo. Puede escribir SQL plano o un formato comprimido personalizado, y las herramientas de restauración correspondientes son psql para los archivos SQL y pg_restore para el formato personalizado.

¿Cómo sé que mi copia funciona?

Restaurándola. Carga la copia en una base de datos separada y vacía, y comprueba que las tablas existen y que el número de filas y algunos registros recientes coinciden con los datos reales. Una copia que nunca has restaurado es una suposición.

¿Dónde debo guardar las copias de la base de datos?

En un lugar separado de la propia base de datos, idealmente con otro proveedor o cuenta, y con el acceso limitado a ti. Las copias contienen los datos de todos tus usuarios, así que trátalas con el mismo cuidado que la base de datos en directo.