The night my Synology DS920+ decided its Docker package needed a fresh reinstall, I lost about forty minutes of my life and roughly two years of Pi-hole query logs. The containers came back. The data did not. That was the day I finally understood the thing every Docker guide should say in the first sentence but never does.
You do not back up a container. You back up what it writes to disk.
A running container is a throwaway shell built from an image. Delete it, and you can pull the exact same image again in seconds. What actually matters, and what disappears silently when things go wrong, are three separate things: your volumes, your compose or config files, and your appdata folder. Get those three off the box safely and a total rebuild stops being a disaster and becomes a chore.
Understand what you are actually protecting
Before you copy a single file, it helps to know where each container stashes its state. On a NAS this is almost always one of two patterns.
The first is a bind mount, where a folder on your NAS is mapped straight into the container. On Synology this usually lives under something like /volume1/docker/appname. On Unraid it is the famous /mnt/user/appdata/appname. You can open these folders in File Station or Krusader and see the real files sitting there. That is the good case, because a plain folder is trivial to copy.
The second is a named volume, managed by Docker itself and buried under /var/lib/docker/volumes. These are harder to reach and easy to forget. If a container uses one and you only back up your appdata folder, you have missed data entirely.
Step 1: Save your compose files and run commands first
This is the part people skip, and it is the cheapest insurance you will ever buy. Your docker-compose.yml files, or the exact docker run commands you used, are the recipe for rebuilding everything.
On Unraid, your container definitions are template XML files under /boot/config/plugins/dockerMan/templates-user. Copy that whole folder. On Synology using Container Manager, export each project, or better, keep your compose files in a dedicated folder like /volume1/docker/compose and edit them there.
I keep every compose file in a single Git repository that syncs to my laptop. It is maybe 30 kilobytes of text, and it means I can rebuild my entire stack from a fresh install without remembering a single port mapping or environment variable.
Step 2: Stop the container before you copy its data
Here is the mistake I see constantly. Someone copies a live SQLite or database folder while the app is running, the file gets copied mid-write, and the backup restores into a corrupted mess. Databases hate being read halfway through a transaction.
The safe pattern is stop, copy, start.
- Stop the container:
docker stop nextcloud - Copy or snapshot the data folder
- Start it again:
docker start nextcloud
For most home apps the downtime is seconds. If you script this to run at 3am, nobody will ever notice. The exception is a proper database container like PostgreSQL or MariaDB, where you should use the app's own dump tool instead, for example docker exec mariadb mysqldump, which gives you a clean consistent export while the container keeps running.
Step 3: Back up named volumes the right way
Named volumes need a trick, because you cannot just browse to them easily. The standard approach is a throwaway helper container that mounts the volume and tars it out.
The command looks intimidating but it is copy-paste safe:
docker run --rm -v myvolume:/data -v /volume1/backups:/backup alpine tar czf /backup/myvolume.tar.gz -C /data .
That spins up a tiny Alpine container, mounts your named volume at /data, mounts a backup folder on your NAS, and compresses everything into a single tarball. When it finishes, the helper container deletes itself. Restoring is the same command in reverse with tar xzf.
If your stack is full of named volumes, do not run this by hand for each one. List them with docker volume ls, then loop the tar command over the names in a short shell script. I have eleven volumes across my main stack, and the loop tars every one of them into timestamped files in about ninety seconds flat. Timestamps matter more than you would think, because they let a cleanup line keep the last seven nights and delete anything older automatically, so your backup folder never quietly fills the disk.
Step 4: Get the backup off the NAS entirely
A backup that only lives on the same NAS as the original is not really a backup. If the drive dies or the whole unit gets stolen, both copies vanish together. This is where the well-worn 3-2-1 backup strategy earns its keep: three copies, two different media, one off-site.
On Synology, Hyper Backup does this natively and can push your /volume1/docker folder plus your volume tarballs to an external USB drive, another NAS, or a cloud bucket. On Unraid, the community Appdata Backup plugin stops your containers, tars the whole appdata folder, and can drop it wherever you point it.
| Method | Best for | Rough effort |
|---|---|---|
| File Station copy | Bind mounts and appdata | Manual, low |
| tar helper container | Named volumes | Script once, then automatic |
| Hyper Backup (Synology) | Whole-folder off-site | Set once, runs nightly |
| Appdata Backup (Unraid) | Full appdata stop-copy-start | Set once, runs weekly |
Step 5: Automate it and set a schedule
A backup you have to remember to run is a backup that will not happen. Put the whole thing on a timer.
On Synology, Task Scheduler runs a user-defined script. On Unraid, User Scripts plus a cron line does the same. My own stack stops the containers, dumps the databases, tars the named volumes, then lets Hyper Backup ship the lot to Backblaze B2 at 3:15am every night. It costs me under two dollars a month for around 60 gigabytes.
One detail worth getting right is retention. A single nightly backup that overwrites itself is dangerous, because if a database corrupts on Tuesday and you do not notice until Thursday, your only backup is now two nights of corruption. Keep at least a week of dated copies so you can roll back to a known-good night. Disk is cheap and regret is not.
The rebuild test that proves it worked
The real measure of a Docker backup is not whether the files copied. It is whether you can go from bare metal to running app using only what you saved.
Try it once on purpose. Spin up a container from your compose file, stop it, delete it and its data, then restore your volume tarball and appdata folder and start it fresh. If the app comes back with its settings, users, and history intact, you are done. If it comes back empty, you found a gap while it was cheap to fix rather than at 2am during a real outage. That single dry run is worth more than any guide, including this one.
Frequently asked questions
Do I need to back up the Docker images themselves?
No. Images are pulled fresh from a registry like Docker Hub whenever you run a container, so saving them is wasted space. Just make sure you record the exact image tag in your compose file so you rebuild with the same version, then let Docker download it again.
Can I back up a running database container safely?
Not with a plain file copy. A live PostgreSQL or MariaDB data folder can be copied mid-write and restore corrupted. Instead run the database's own dump command, such as docker exec mariadb mysqldump, which produces a consistent export while the container keeps running.
Where does Synology Container Manager store appdata?
It depends on how you set up each container, but bind mounts typically live under /volume1/docker/appname. Run docker inspect on the container and check the Mounts section to see the exact source path on your NAS for every folder it uses.
What is the difference between a bind mount and a named volume for backups?
A bind mount is a normal folder on your NAS you can browse and copy directly in File Station. A named volume is managed by Docker under /var/lib/docker/volumes and needs a helper container to extract. Many stacks use both, so check with docker inspect.
How often should I back up my containers?
Nightly for anything with data that changes daily, like Nextcloud or a media server database. Static setups can go weekly. The more important number is how often you test a restore, which should be at least once a month.
