Duplicati

Last reviewed Aug 26, 2026 · 800 words

Duplicati's weak point is not the backup, it is the restore. Every backup job depends on a local SQLite database that maps files to encrypted blocks on the destination, and if that database is lost or corrupted, Duplicati has to rebuild it by reading the remote, which for a multi-hundred-gigabyte set can take hours to days. Know that before you rely on it. With that understood, it is still the friendliest free backup tool for someone who wants a web UI, a schedule, AES-256 encryption and 30-odd storage backends without touching a terminal, and at about 14,900 GitHub stars with a history back to 2008 it is not going anywhere.

How the data is stored, and why you cannot browse it

Duplicati splits files into blocks, deduplicates them, encrypts them, and packs them into remote volumes with dblock, dindex and dlist names. The destination is a pile of opaque archives; you cannot open your Backblaze bucket and find a photo. The local database is the index. Two operational rules fall out of that. First, export every job's configuration as JSON from the UI and keep it, with the passphrase, in your password manager, because without both the remote data is unrecoverable noise. Second, run a test restore of a few files every month, since that exercises the database and the remote together and is the only proof the backup works.

Fix the block sizes before the first run

The defaults are tuned for small backups, and the block size cannot be changed after a job has run. For anything over a few hundred gigabytes, open the advanced options on the job before its first execution and raise both the block size and the remote volume size; the community's rule of thumb is that the local database stays manageable when the block count stays in the low millions. I skipped this once on a 1.2 TB set, and the database grew to a size where every verification took most of a night. The remote volume size is adjustable later; the block size is not, and the only fix is a new job and a full re-upload.

The Docker setup is four lines plus mounts

services:
  duplicati:
    image: duplicati/duplicati:latest
    ports:
      - "8200:8200"
    volumes:
      - ./config:/data
      - /home:/source/home:ro
      - /srv/media:/source/media:ro
    restart: unless-stopped

The web UI is on port 8200. Mount source directories read-only under a single prefix, so a misconfigured restore cannot write over live data, and keep /data on the same backup rotation as the jobs it describes, because that is where the SQLite databases live. Set a UI password on first launch; the official image accepts it through environment variables and the interface prompts for it otherwise. Native installers exist for Windows, macOS and Linux, and on a family member's laptop the installer is the right choice, since it runs as a service with a tray icon and needs no explanation.

A decade of beta is over, mostly

The 2.0 line spent roughly ten years labelled beta, which is the reason the catalogue lists "long beta history" as a con, and the reason many operators refused to trust it. The 2.1 line now ships builds marked stable and the project has a company behind it. I would still describe the maturity as good rather than bulletproof, and I would still treat the "database recreate" operation as the thing most likely to ruin a day. Restores of a handful of files are quick; full-set restores are the slow path and you should have timed one before you need it.

When restic or Kopia is the better tool

Restic and Kopia use similar chunk-and-encrypt designs but keep their indexes in the repository, so there is no local database to lose and a restore from a fresh machine starts immediately. Both restore faster in my experience, both are command-line first, and Kopia ships a desktop GUI that covers the schedule-and-forget use case. For servers, scripts and anyone comfortable with a terminal, they are simply better, and my 3-2-1 backups guide plus the Borg versus restic comparison go through the practical differences.

What I'd do

Duplicati for the machines run by people who will never open a terminal: a parent's Windows laptop backing up to Backblaze B2, block sizes raised before the first run, job export and passphrase saved, a five-file restore tested quarterly. For my own servers, restic to the same bucket. Two tools, each doing the job it is honest about, which in the backup category beats one tool doing both jobs badly.