← Back to Blog Home

Running a Duplicacy Docker Image

Extracurricular Activities
by: Matt Fletcher

Article summary

My preferred remote backup solution is Duplicacy. Every night, I have Duplicacy backup data from my local NAS to Backblaze B2. In this post, I’ll explain how I have Duplicacy run nightly via Docker.

This is my fourth post documenting containers I use at home. You can also read about how I run the Unifi controller, how I run Plex, and how I update DuckDNS.

About Duplicacy

Duplicacy describes itself as “a new generation cross-platform cloud backup tool.” I like it because it performs incremental backups on a regular basis. Configuration is not difficult, and the Duplicacy Web interface works well enough to get the job done.

Duplicacy Web Configuration

I tend to use docker-compose to build and run my images and containers. Here are the contents of the docker-compose.yml for this project:

---
version: '3.7'

networks:
  default:
    name: duplicacy

services:
  duplicacy-web:
    container_name: duplicacy-web
    image: saspus/duplicacy-web:v1.4.1

    hostname: fletcherm-duplicacy

    environment:
      - USR_ID=XYZ # user account id on the system
      - GRP_ID=ABC # group id on the system
      - TZ=America/Detroit
    ports:
      - "3875:3875/tcp"
    volumes:
      - /volume1/docker/duplicacy-web/config:/config
      - /volume1/docker/duplicacy-web/logs:/logs
      - /volume1/docker/duplicacy-web/cache:/cache
      - /volume1/dir1:/data/dir1:ro
      - /volume1/dir2:/data/dir2:ro

Let’s step through some of the interesting bits here, much of which is derived from the instructions in the saspus/duplicacy-web image’s README file.

Image

image: saspus/duplicacy-web:v1.4.1

My personal preference is to lock images down to a specific version, if at all feasible. This way I won’t be surprised when, say, a new version of an image requires or breaks the current configuration. The author of this image (saspus) has done a great job providing versioned images over time. The next time I need to update this image, it’ll be easy to see what I’m coming from, where I’m going, and what the changes are.

Hostname

hostname: fletcherm-duplicacy

Hostname is the key used by Duplicacy’s Personal license. This is how we configure it while running the image.

Permissions

environment:
  - USR_ID=XYZ # user account id on the system
  - GRP_ID=ABC # group id group on the system
  - TZ=America/Detroit

Here I set the user and group IDs for the local user I want backing up the data. (I have the comment there so that, when I look at this file again three months later, I can remember why I have some hardcoded numbers typed into the file.) I also set the timezone so that timestamps are obvious to me.

Note that, although the above variables are named slightly differently, they follow the tried-and-true approach from LinuxServer.io that I appreciate so much.

Volume Mapping

volumes:
  - /volume1/docker/duplicacy-web/config:/config
  - /volume1/docker/duplicacy-web/logs:/logs
  - /volume1/docker/duplicacy-web/cache:/cache
  - /volume1/dir1:/data/dir1:ro
  - /volume1/dir2:/data/dir2:ro

There are two sets of volumes here. The first set of volumes are data directories for Duplicacy. The second are the data directories I want backed up. The data directories are set with read-only access, which further boosts my confidence that the data itself can’t get mangled by an error of some sorts.

That’s about it. saspus has done a wonderful job of making the image itself pretty straightforward to run. I hope this post helps spread knowledge of their good work!

Related Posts