Cool backups for the people - Duplicacy

I spent a long time searching for a reliable backup solution for my home servers, and discovering Duplicacy honestly felt like a gift. It’s actively maintained, and if you look at the benchmark charts, Duplicacy stands out as a clear winner for many high-throughput tasks—all while saving precious disk space. Lock-Free Deduplication FTW!
The web version has some paid features (it's free for recoveries—huge thanks ❤️ to the developers!). I truly believe in supporting great projects like this, and I do so myself. However, I recognize not everyone has the means to contribute right now. That’s why I decided to put together a solution using Duplicacy CLI and Docker—perfect for those who enjoy tinkering and want a free, flexible option.
You can find the result here, but in this post, I want to walk you through how to set it up yourself and share some of its coolest features. Let's get started.
Docker Compose
First things first, you’ll need Docker and Compose installed on your machine. (If you haven’t already, there are plenty of great guides online. For searching, I highly recommend Kagi.)
Next, grab the provided docker-compose file and customize it to fit your setup. For Unraid users (as of 2025), it would look something like this:
services:
duplicacy-cli-cron:
image: drumsergio/duplicacy-cli-cron:3.2.4
container_name: duplicacy-cli-cron
restart: unless-stopped
volumes:
- /mnt/user/appdata/duplicacy/config:/config
- /mnt/user/appdata/duplicacy/cron:/etc/periodic
- /mnt/remotes:/smb_nfs_shares
- /mnt/disks:/unassigned_devices
- /mnt/user:/local_shares
- /boot:/boot_usb
environment:
- TZ=Etc/UTC
- SHOUTRRR_URL=telegram://TOKEN@telegram?chats=YOUR_CHAT_ID
You can set the Docker image as needed—for example, if you want to use your own container image, just point to it in the compose file. The Dockerfile is available in my repo, so feel free to build it yourself.
Next, configure your volumes. The first two volumes are for configuration files (we’ll cover these in a moment). The remaining volumes depend on what you’d like to back up, plus you’ll need to add a destination folder for your backup data. (Currently, my scripts only support file-based backups, but Duplicacy itself supports various backup targets.)
After that, set up your environment variables. Be sure to set the TZ
variable so timestamps in your logs are accurate (and the cron
times too), and add your Shoutrrr URL for notifications—I've personally tested this with Telegram, but it should work with any service Shoutrrr supports.
Once all that is set, you’re ready to run docker-compose up
and start configuring the scripts.
Config
Start by focusing on the first volume in the list: the Config volume. You’ll need to populate this folder (on your host or inside the container, as long as it’s within the volume) with the config.sh
and reinit-folders.sh
scripts found in my repo under the config/
folder.
The config.sh
script handles the setup for your Duplicacy folder. You just need to fill in the variable values as needed. For instance, if want to back up your Multimedia folder in Unraid, here’s how you’d do it:
#!/bin/sh
MY-LOCATION=Multimedia
MY-DESTINATION=Geiserback # My second server
MY-SECOND-DESTINATION=Geiserback2 # My third server
SMB_NFS_SHARE1=GEISERBACK_Backup
SMB_NFS_SHARE2=GEISERBACK2_Backup
cd /local_shares/Multimedia
duplicacy init -storage-name ${MY-LOCATION}-${MY-DESTINATION} ${MY-LOCATION}-${MY-DESTINATION} /smb_nfs_shares/${SMB_NFS_SHARE1}/${MY-LOCATION}
duplicacy add -bit-identical ${MY-LOCATION}-${MY-SECOND-DESTINATION} ${MY-LOCATION}-${MY-SECOND-DESTINATION} /smb_nfs_shares/${SMB_NFS_SHARE2}/${MY-LOCATION}
duplicacy list -storage ${MY-LOCATION}-${MY-DESTINATION}
duplicacy list -storage ${MY-LOCATION}-${MY-SECOND-DESTINATION}
Use as many config.sh
scripts as you have folders to back up.
You might notice that the initial duplicacy init
command here differs from what’s in the repo. That’s because this example assumes both servers are mounted via SMB or NFS, rather than having the disk physically attached to your Unraid system.
To get things working, make each config.sh
executable (chmod +x config.sh
), then run each one (./config.sh
) for every folder you want to set up.
As for reinit-folders.sh
, just add one line per config.sh
script you’re using. This script is handy for situations where NFS breaks or something goes wrong—sometimes it’s necessary to erase the .duplicacy/
directory for a clean reinit. If you do this, simply run your config.sh
files again (but double-check that your NFS mounts are accessible first 😁).
With the configuration ready, we now need the scripts to actually run and schedule the backups. Let’s dive into those next.
Scripts
The second volume maps to the container’s /etc/periodic
directory—yes, that’s the folder monitored by cron inside the container.
This directory needs a subfolder indicating how often you want your backups to run. If you log in to the container and run crontab -e
, you’ll see the monitored directories:
- 15min
- hourly
- daily
- weekly
- monthly
Simply choose the periodicity that fits your needs. In my setup, I usually create a daily/
subfolder, as I prefer backups to run once a day, overnight. The default schedule is 2 a.m., according to the timezone you set in Docker Compose. If you want a different time, you can adjust it in the crontab as needed.
Let’s say you opt for the daily/
subfolder. In that case, simply add the executor.sh
script inside it. For example, this script would back up the Multimedia folder we discussed earlier:
#!/bin/sh
MY_LOCATION=Multimedia
MY_DESTINATION=Geiserback
MY_SECOND_DESTINATION=Geiserback2
MachineName=NoName
... # Use the rest of the script from the executor under `scripts` folder in the repository
Don’t forget to make the script executable with chmod +x
, then you can test it by running ./executor.sh
to ensure everything’s working as expected.
The End
And that’s all for today, folks! If you’d like to contribute, feel free to submit a PR—I’d be more than happy to check it out and work on it together. Thanks for reading!