Back up an app with PostgreSQL

Your application (Node, Python, Ruby, PHP, Go…) runs on a Linux server, with PostgreSQL on the same machine, installed from your distribution’s packages or in a Docker container. This page says what NeverWiped backs up, what to check, and how to bring back one database, the app or the whole server.

What the agent finds

• Your app’s folder. A folder in /opt is backed up as an application when it holds a project file: package.json, composer.json, Gemfile, go.mod, manage.py, a .env, a .git folder or a Compose file. Apps in /srv, /var/www, /home or /root are backed up with those folders (what is backed up).
• PostgreSQL on the server. When pg_dumpall, the local socket and the postgres user are there, every database is exported with pg_dumpall, run as postgres: each database consistent on its own, plus the roles (a database).
• PostgreSQL in a container. A running container of a PostgreSQL, PostGIS or TimescaleDB image is exported with docker exec, as the user of POSTGRES_USER (databases in Docker).
• The configuration: /etc and the cron tables. Debian and Ubuntu keep PostgreSQL’s settings in /etc/postgresql; other distributions may keep them in the data folder, which is not copied: add those files with --include.

The database files themselves are not copied: the dump is what you restore. Excluded by default: **/node_modules, **/.cache, /var/cache (what is backed up).

Check the plan before you accept it

• PostgreSQL is listed under the databases. If it is not, it is not backed up. It must run on this server, with its socket in the usual place.
• A database on another machine (a managed database, a separate database server) is not exported. Run the agent on that server too, if it is yours.
• Room for the dump. During a backup the dump is written on the server’s disk, in /var/lib/neverwiped/dumps, then deleted. The estimate shows the size of the database files, not of the dump (size and exclusions).
• Build output and caches. --preset build leaves out what a build recreates; uploaded files and anything only your app has stay in.

The plan is made at install. When you add a database server or an app folder, run neverwiped install --yes again with the same options: it keeps the same server and repository.

Bringing things back

• One database damaged, the others fine (a wrong DELETE, a failed migration): take that database out of the dump, rename the damaged one aside, and import it alone. The commands are in a database.
• Every database, or a new server: re-import the whole file, roles included, with psql (a database).
• A file of the app (an upload, a config file): one file or a folder.
• The whole server: install PostgreSQL and your runtime first, then follow a whole server.

Before a migration, run neverwiped backup now: the dump is then as recent as it can be.

What it does not do here

• No point-in-time recovery. You go back to the time of a backup, every night or once a week depending on your plan, not to the second before the accident. If you need that, add PostgreSQL’s own continuous archiving of its write-ahead log; NeverWiped does not do it.
• Each database is consistent on its own, not all of them at the same instant. Apps that keep related data in two databases should know it.
• A replica is not a backup, and neither is this a replica. A restore takes the time of a re-import; it does not keep the app running if the server fails.
• Root on the server, and one copy: see the known limits.

Start

On the server, as root:

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

Then follow getting started. Other servers: all use cases.

Last reviewed: 6 November 2026.