Ask a NAS owner what their containers do and they will list ten apps. Ask how long rebuilding them all from nothing would take, and the room goes quiet. The difference between a disaster and an annoying afternoon is this routine — small, boring, and done before it is needed.
🎥 Watch the complete installation in the video — Docker on a Synology NAS, step by step
A container setup has three layers, and a real backup covers all three. The images need no backup at all — they download again from the registry for free. The settings — ports, volume mappings, environment variables, the compose files — are small text and absolutely worth saving, because they are the recipe. The data is your apps' databases and files, sitting in the shared folders you mapped. Lose the data and the recipe is a menu for a restaurant that burned down; lose the recipe and the data is a warehouse with no index. Back up both, keep one copy off the NAS, and test the restore once.
The three layers of a container setup
ImagesRE-DOWNLOAD — NO BACKUP NEEDED
Settings and compose filesEXPORT AND KEEP
App data in shared foldersHYPER BACKUP
The only copy on the NAS itselfNOT A BACKUP
Images are replaceable, recipes are small, data is priceless. A backup routine that treats all three the same is wasting effort in one place and risking everything in another.
1
Layer One — Export Every Container's Settings
Container Manager lets you export a container's configuration to a file. Do it for every container you would miss, and again after any change you make to ports, folders or variables.
Open the container in Container Manager and use its export settings option, saving the file into a dedicated folder — docker-backups/settings is a fine home.
For Projects, the treasure is the compose file itself. Keep a copy of every project's compose file in the same folder. That one small text file can rebuild the entire stack on any Docker machine on earth.
Keep a plain note, in words, of anything the files cannot say — why a port was chosen, where a password lives in your password manager, which folder belongs to which app.
2
Layer Two — The Data Folders Go Into Hyper Backup
Because you mapped your apps' data into the docker shared folder (the volumes guide in this series explains why), ordinary NAS backup tools can see it — no container knowledge required.
Open Hyper Backup and include the docker shared folder — or the specific app subfolders — in a task alongside your other important shares.
Send it somewhere that is not this NAS: a USB drive you rotate, another NAS, or a cloud target. A backup on the same disks as the original is a second copy of the same accident.
Databases inside containers prefer a quiet moment. Scheduling the backup for the small hours, when apps are idle, keeps files consistent; apps with their own built-in backup or export feature deserve to have it used as well.
Also back up DSM's own configuration from Control Panel, so the NAS itself — users, shares, permissions — is part of the same recovery story.
3
Layer Three — The Off-NAS Copy of the Recipes
The settings exports and compose files are tiny — kilobytes. There is no excuse for their only copy to live on the machine they describe.
They ride along automatically if your Hyper Backup task includes the folder that holds them — one more reason to keep them inside the docker share rather than scattered in download folders.
A second copy in your normal cloud documents or password-manager vault costs nothing and survives even a total NAS loss, fire-and-flood included.
Review the folder monthly. Delete exports of containers you no longer run, so a future restore is not an archaeology dig.
4
The Restore Test — The Step That Makes It a Backup
An untested backup is a hope wearing a backup's clothes. Once — once is enough to learn everything — walk the full road back:
Pick your least important real app. Stop and delete its container entirely.
Restore its data folder from Hyper Backup to a test location, or confirm the live folder is intact if you are testing only the recipe.
Recreate the container from your exported settings or compose file, pointing at the data folder.
Open the app and check its contents like an auditor. Everything present means your backup is real. Anything missing means you just learned, cheaply, what to fix in the routine.
Time the exercise. The number you measure — not the number you imagine — is your real recovery time, and knowing it turns a future failure from a panic into an appointment.
5
The Routine, Compressed to a Habit
After every change to a container: re-export its settings. Every week, automatically: Hyper Backup carries the docker folder off the NAS. Once, and once a year after: the restore test. That is the entire discipline. Containers were designed to be rebuilt in minutes — this routine is simply making sure the minutes are spent rebuilding, not remembering.
🐳 The sentence to tape above the NAS: images are free, settings are small, data is priceless — a backup you have never restored is a rumour. Export the recipes, back up the folders, and prove the road back once while nothing is on fire.
🎥 Watch the Complete Video
The full Docker on Synology NAS installation, shown live on a real NAS from package install to a running container.
Do I need to back up the container images themselves?
No. Images are downloaded from the registry and can be fetched again at any time for free. What deserves backup is the small stuff that cannot be re-downloaded — your container settings or compose files — and the app data in your shared folders, which exists nowhere else.
Can Hyper Backup back up my Docker containers?
Hyper Backup backs up folders and supported DSM packages and settings, and your container data — because it lives in the docker shared folder — is included like any other folder. The container definitions themselves are covered by exporting each container's settings from Container Manager and keeping those small files inside a folder your backup already carries.
How often should I test restoring a container?
Once when you set the routine up, so you learn the road while nothing is at stake, and then about once a year or after any big change to how you run containers. Delete one unimportant container, rebuild it from your exported settings and data folder, and confirm the app returns complete.
This guide is based on the Technical Anshu video on installing Docker on a Synology NAS • Stuck on a step? Ask in the video comments 🙏