Copias de una aplicación con PostgreSQL

Tu aplicación (Node, Python, Ruby, PHP, Go…) se ejecuta en un servidor Linux, con PostgreSQL en la misma máquina, instalado desde los paquetes de tu distribución o en un contenedor Docker. Esta página explica qué guarda NeverWiped, qué revisar, y cómo recuperar una base de datos, la aplicación o el servidor entero.

Lo que encuentra el agente

• La carpeta de tu aplicación. Una carpeta de /opt se guarda como aplicación cuando contiene un archivo de proyecto: package.json, composer.json, Gemfile, go.mod, manage.py, un .env, una carpeta .git o un archivo Compose. Las aplicaciones en /srv, /var/www, /home o /root se guardan con esas carpetas (qué se guarda).
• PostgreSQL en el servidor. Cuando pg_dumpall, el socket local y el usuario postgres están presentes, todas las bases se exportan con pg_dumpall, ejecutado como postgres: cada base coherente por sí misma, más los roles (una base de datos).
• PostgreSQL en un contenedor. Un contenedor en marcha de una imagen PostgreSQL, PostGIS o TimescaleDB se exporta con docker exec, con el usuario de POSTGRES_USER (bases de datos en Docker).
• La configuración: /etc y las tareas programadas. Debian y Ubuntu guardan los ajustes de PostgreSQL en /etc/postgresql; otras distribuciones pueden tenerlos en la carpeta de datos, que no se copia: añade esos archivos con --include.

Los archivos de la base en sí no se copian: lo que restauras es la exportación. Excluidos por defecto: **/node_modules, **/.cache, /var/cache (qué se guarda).

Revisa el plan antes de aceptarlo

• PostgreSQL aparece entre las bases de datos. Si no aparece, no se guarda. Debe ejecutarse en este servidor, con su socket en el lugar habitual.
• Una base de datos en otra máquina (una base gestionada, un servidor de bases aparte) no se exporta. Instala también el agente en ese servidor, si es tuyo.
• Espacio para la exportación. Durante una copia, la exportación se escribe en el disco del servidor, en /var/lib/neverwiped/dumps, y luego se borra. La estimación muestra el tamaño de los archivos de la base, no el de la exportación (tamaño y exclusiones).
• Resultados de build y cachés. --preset build deja fuera lo que un build vuelve a crear; los archivos subidos y todo lo que solo tiene tu aplicación siguen dentro.

El plan se fija en la instalación. Cuando añadas un servidor de bases de datos o una carpeta de aplicación, vuelve a ejecutar neverwiped install --yes con las mismas opciones: conserva el mismo servidor y el mismo repositorio.

Recuperar

• Una base dañada, las demás bien (un DELETE equivocado, una migración fallida): saca esa base de la exportación, renombra la base dañada e impórtala sola. Los comandos están en una base de datos.
• Todas las bases, o un servidor nuevo: vuelve a importar el archivo entero, roles incluidos, con psql (una base de datos).
• Un archivo de la aplicación (un archivo subido, un archivo de configuración): un archivo o una carpeta.
• El servidor entero: instala primero PostgreSQL y el entorno de tu aplicación, y sigue un servidor entero.

Antes de una migración, ejecuta neverwiped backup now: la exportación es así lo más reciente posible.

Lo que no hace aquí

• No hay recuperación a un instante exacto. Vuelves al momento de una copia, cada noche o una vez por semana según tu plan, no al segundo antes del accidente. Si lo necesitas, añade el archivado continuo del registro de escritura (WAL) del propio PostgreSQL; NeverWiped no lo hace.
• Cada base es coherente por sí misma, no todas en el mismo instante. Una aplicación que guarda datos relacionados en dos bases debe saberlo.
• Una réplica no es una copia de seguridad, y esto no es una réplica. Una restauración lleva el tiempo de una reimportación; no mantiene la aplicación en marcha si el servidor cae.
• Root en el servidor, y una sola copia: ver los límites conocidos.

Empezar

En el servidor, como root:

curl -fsSL https://neverwiped.com/install.sh | sh

Después sigue los primeros pasos. Otros servidores: todos los casos de uso.

Última revisión: 6 de noviembre de 2026.