Back up a VPS running Docker

Your apps run in Docker containers, usually started with Docker Compose, on one Linux server. Their data sits in named volumes, in folders mounted from the server, and in database containers. This page says what NeverWiped backs up on such a server, what to check before the first backup, and how to bring a volume, a database or the whole server back.

What the agent finds

• Your Compose projects. A folder in /opt with a compose.yml or docker-compose.yml is backed up as an application, with its .env file and the folders mounted from it (./data:/data). Projects in /srv, /home or /root are backed up with those folders (what is backed up).
• Databases in containers. A running PostgreSQL, MySQL or MariaDB container is exported with docker exec: pg_dumpall as the user of POSTGRES_USER, or mysqldump with the root password of the official images’ variables. Its volume is not copied as files: the export replaces it.
• The other named volumes. They are read while the containers keep running. For images that write a database-like state in place (Redis, Valkey, MongoDB, Elasticsearch, OpenSearch, InfluxDB, RabbitMQ, Vaultwarden and similar), the install proposes a copy with their containers paused for the time of a local copy (docker pause: frozen, not restarted). See a Docker volume.
• The rest of the server: /etc, the cron tables, /root and /home.

Not backed up: Docker’s images and container layers (/var/lib/docker/overlay2 is excluded). They come back with docker compose pull or a build from the Dockerfile in your project folder.

Check the plan before you accept it

• A folder mounted from elsewhere (/data, a second disk): add it with --include /data. Folders mounted from inside the project folder are already in.
• A database folder mounted from the project folder (./pgdata:/var/lib/postgresql/data): the export already covers that database, and a live copy of its files is not consistent. Leave it out with --exclude /opt/app/pgdata.
• A stopped database container is not exported: containers are found with docker ps, which lists the running ones. Start your stack before the install.
• A volume taken the wrong way: change it with --pause-volume <name> or --live-volume <name>.
• No Docker at all in the backup: --no-docker.

The plan is made at install. When you add a container, a volume or a project later, run neverwiped install --yes again, with the same options: it detects again and keeps the same server, repository and recovery key. neverwiped status shows what is backed up and how each volume is taken.

Bringing things back

• A volume. Restore it into a separate folder, stop the containers that use it, keep its current content aside, copy the backup in, start them again (a Docker volume).
• A database in a container. The dump comes back as postgresql-docker-<container>.sql or mysql-docker-<container>.sql, and is imported with docker exec -i (databases in Docker). One database alone: a database.
• The whole server. On the new server, install Docker first, then the agent, run neverwiped recover and restore into a folder. Copy your project folders back, run docker compose up --no-start to create the volumes, copy the volumes in, import the dumps, then start the stacks (a whole server).

Before a risky change (a major version of a database image, a migration), run neverwiped backup now.

What it does not do here

• No image of the server. The Docker engine, its images and the containers themselves are rebuilt, not restored.
• Live volumes are read while the app runs. Files written during the backup may come back as they were at different moments. Pause the volume if that matters to the app.
• A paused copy needs free disk space for a copy of the volume, and is what a power cut at that instant would leave on disk (a Docker volume).
• A database comes back as it was at a backup, not at any moment in between.
• 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.