Why I Set This Up
I run multiple Docker containers on my Proxmox host, and each one generates data I can't afford to lose. Configuration files, databases, user uploads—all stored in Docker volumes. For months, I relied on manual snapshots and occasional rsync jobs, which worked until I forgot to run them for three weeks straight.
I already had a Synology DS920+ running Active Backup for Business (ABB), which I used for backing up my laptops and a few VMs. The question was whether I could use it for my Docker volumes too, with proper deduplication and without treating it like a dumb file share.
The goal: automated, deduplicated backups of Docker volumes using Restic, stored on my Synology via SMB, with verification that deduplication actually worked.
My Setup
Here's what I was working with:
- Proxmox host running Docker containers (no Docker Compose, just plain docker run commands)
- Synology DS920+ with Active Backup for Business installed
- Docker volumes scattered across /var/lib/docker/volumes/
- Local network, no cloud involvement
I chose Restic because it handles deduplication natively and works well with SMB mounts. I'd used it before for backing up my Proxmox host itself, so I knew its quirks.
The SMB Mount Problem
My first attempt was mounting a Synology shared folder via SMB and pointing Restic directly at it. I created a shared folder called "docker-backups" in the Synology web interface and mounted it on my Proxmox host:
mount -t cifs //192.168.1.50/docker-backups /mnt/synology-backups \
-o username=backup-user,password=mypassword,uid=0,gid=0
This worked, but I immediately hit permission issues. Docker volumes are owned by various UIDs depending on the container, and Restic complained about not being able to read certain files. I fixed this by running Restic as root, which I wasn't thrilled about but accepted for a backup process.
The bigger issue was that Active Backup for Business doesn't directly interact with SMB shares the way it does with its own backup tasks. ABB is designed to receive backups from its agents or handle VM/PC snapshots, not monitor arbitrary file dumps. So while my backups landed on the Synology, ABB wasn't managing them—it was just storage.
Restic Repository Initialization
With the SMB mount in place, I initialized a Restic repository:
restic -r /mnt/synology-backups/restic-repo init
Restic prompted for a password, which I stored in a file at /root/.restic-password. Not ideal security-wise, but this is a local network setup, and I wasn't exposing anything externally.
I then created a simple script to back up all Docker volumes:
#!/bin/bash
RESTIC_PASSWORD_FILE=/root/.restic-password
RESTIC_REPO=/mnt/synology-backups/restic-repo
restic -r $RESTIC_REPO --password-file $RESTIC_PASSWORD_FILE \
backup /var/lib/docker/volumes/ \
--exclude="*.log" \
--exclude="**/cache/**"
The excludes were necessary because some containers generate massive log files that change constantly and don't need backup.
Scheduling with Cron
I added the script to root's crontab to run nightly at 2 AM:
0 2 * * * /root/backup-docker-volumes.sh >> /var/log/restic-backup.log 2>&1
This worked, but I had no alerting if it failed. I later added a check to send me an email if the exit code wasn't zero, using a simple mail command piped through my local Postfix relay.
Verifying Deduplication
The whole point of using Restic was deduplication. Docker volumes contain a lot of redundant data—config files that barely change, static assets, database dumps with overlapping content. I wanted to confirm that Restic was actually deduplicating and not just compressing.
After a few days of backups, I checked the repository stats:
restic -r /mnt/synology-backups/restic-repo --password-file /root/.restic-password stats
The output showed:
Total File Count: 12847
Total Size: 45.2 GiB
Total Blob Count: 8923
Total Blob Size: 12.1 GiB
So 45.2 GiB of data was being stored as 12.1 GiB of blobs. That's roughly 73% deduplication, which made sense given that many of my containers share base images and libraries.
I also ran a prune operation to clean up old snapshots:
restic -r /mnt/synology-backups/restic-repo --password-file /root/.restic-password \
forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
This kept the last 7 daily backups, 4 weekly, and 6 monthly. After pruning, the blob size dropped further, confirming that deduplication was working across time as well.
What Didn't Work
My initial plan was to have Active Backup for Business "see" these Restic backups as a managed backup set. That's not how ABB works. It only manages backups it creates or receives through its own protocols (like PC agents or hypervisor snapshots). The Restic repository on the Synology is just a folder full of blobs—ABB doesn't touch it.
I also tried using Synology's built-in rsync server instead of SMB, thinking it might integrate better with ABB. It didn't. ABB still ignored it, and rsync added no benefits over SMB for this use case.
Another failed experiment: running Restic inside a Docker container on the Proxmox host. I thought this would isolate the backup process, but mounting Docker volumes into another container created a mess of permissions and nested mounts. I abandoned it after two hours of troubleshooting.
Testing Restores
A backup system is useless if you can't restore. I tested this by intentionally corrupting a Docker volume (deleting a config file) and restoring it:
restic -r /mnt/synology-backups/restic-repo --password-file /root/.restic-password \
restore latest --target /tmp/restore-test \
--include /var/lib/docker/volumes/mycontainer_data
The file was restored correctly. I then copied it back to the original volume location and restarted the container. No issues.
I also tested a full volume restore, which took about 15 minutes for a 2 GB volume over my local network. Not fast, but acceptable for disaster recovery.
Monitoring and Alerts
I set up a simple monitoring check in Cronicle (my job scheduler) to verify that the Restic backup script ran successfully. If the log file didn't update within the last 25 hours, Cronicle sent me a notification.
I also added a weekly task to check repository integrity:
restic -r /mnt/synology-backups/restic-repo --password-file /root/.restic-password check
This scans the repository for corruption or missing blobs. It's slow (takes about 30 minutes on my setup), so I only run it weekly.
Storage Usage Over Time
After three months, my Restic repository is sitting at 38 GiB on disk for what would be 150+ GiB of raw backups if stored uncompressed and undeduplicated. The deduplication ratio has stayed consistent around 70-75%, which tells me my Docker volumes aren't changing as drastically as I thought they were.
The Synology reports the shared folder usage accurately in its Storage Manager, so I can track growth without SSHing into the NAS.
Key Takeaways
- Restic works well for Docker volume backups, but you need to run it as root to avoid permission issues
- Active Backup for Business won't manage Restic repositories—it's just storage in this setup
- SMB mounts are fine for local network backups; no need to overcomplicate with rsync or NFS
- Deduplication is real and measurable—verify it with `restic stats`
- Always test restores, not just backups
- Exclude logs and cache directories to keep repository size sane
- Run `restic check` periodically to catch corruption early
What I'd Change
If I were starting over, I'd use a dedicated backup user on the Synology with limited permissions instead of mounting as root. I'd also explore Restic's REST server mode, which might integrate better with future monitoring tools.
I'm also considering moving to Restic's SFTP backend instead of SMB, since it would eliminate the mount point and simplify the setup. But for now, what I have works reliably.
