Duplicati vs restic

For most of the last decade the answer to this was a one-liner: do not trust your backups to software that has been in beta since 2017. That answer expired on 31 January 2025, when 2.1.0.4 became the first stable release of the Duplicati 2.x codebase. The comparison is now a real one, and it turns on two things: which storage you can reach, and how you feel about a backup tool that keeps a database.

What the specification table decides#

Services to run is 1 against 0, and that gap is the whole design difference: Duplicati is a service listening on port 8200 with a web UI to secure, restic is a process that exits. Datastore is the row that predicts your worst evening, because Duplicati's SQLite databases are the component that goes wrong. Operational load is 3 against 2, and the extra point is exactly that database plus the web interface plus manual patching.

Yes, it shipped, and the reputation is still partly earned#

Credit where it is due. The stable line is real and moving: 2.1.0.4 (31 January 2025), 2.2.0.0 (October 2025), 2.4.0.0 (3 September 2026), the last of which added PAR2 parity data for remote volumes and a native VSS provider on Windows so open-file snapshots no longer need a VCRedist dependency. That is an actively developed project, not a zombie.

The reputation persists for three reasons, and only one of them is unfair.

Unfair: people repeating a 2019 warning without checking. If you read "Duplicati is beta" in an article, check the date.

Fair, first: eight years of a project telling users to run a beta build as their backup software is a long time, and the community memory includes people who lost restores in that period. Trust in backup software is asymmetric. It takes one bad restore to lose and years to rebuild.

Fair, second: the 2.1 rewrite broke running installs in two ways at once. It moved to .NET 8 with OS-specific builds and made the web interface password compulsory, so containers that used to come up with an open UI now need DUPLICATI__WEBSERVICE_PASSWORD, plus DUPLICATI__WEBSERVICE_ALLOWED_HOSTNAMES if you reach it by hostname. And automatic updating was removed in that same release, so an install that was quietly self-updating since 2019 now sits on an old build forever unless you patch it yourself. That is a bad property for the software that owns your backups, and it is the single change most worth acting on today.

A working container looks like this:

services:
  duplicati:
    image: duplicati/duplicati:latest
    environment:
      DUPLICATI__WEBSERVICE_PASSWORD: ${DUP_PASSWORD}
      DUPLICATI__WEBSERVICE_ALLOWED_HOSTNAMES: backup.example.org
      SETTINGS_ENCRYPTION_KEY: ${DUP_SETTINGS_KEY}
    volumes:
      - ./data:/data
      - /srv:/source/srv:ro
    ports: ["8200:8200"]

Set SETTINGS_ENCRYPTION_KEY at first run. It encrypts the credentials stored in the server database, and adding it later is more work than setting it now.

The database recreate is the single most reported Duplicati pain#

Every Duplicati job keeps a local SQLite database that mirrors what is on the remote: block hashes, file lists, volume contents. It exists so incremental backups do not have to interrogate the destination. When it is lost, moved, or disagrees with the remote, Duplicati rebuilds it.

The rebuild reads remote index files first. When those are insufficient, which happens more often than the design implies, it starts downloading 50 MB dblock volumes and reading them one at a time. On a small job that is minutes. On a job with millions of blocks it is hours, and people running large or old jobs report it continuing overnight and into the next day, with the progress bar sitting at the same percentage for hours because the phase it is in has no useful granularity.

Nothing is lost. Restores are possible with no local database at all. But the tool looks broken for a very long time, and it usually happens on the day you moved the container, changed the volume mount, or actually needed a restore.

Two things reduce your exposure:

• Back up /data. It holds Duplicati-server.sqlite and every job database. Restoring it is minutes; rebuilding it is hours. This is the cheapest insurance available and most people skip it because the data is "regenerable".
• Do not inherit the legacy block size. 2.1.0 raised the default deduplication block size to 1 MiB, which massively reduces block counts and therefore database size and recreate time. The change applies only to jobs created afterwards. Existing jobs keep the small legacy size forever, which is the main reason old installs carry multi-gigabyte job databases. The only fix is a new job and a new backup set, meaning a full re-upload. If your Duplicati install predates 2025 and you have the bandwidth, that re-upload is worth doing once.

restic has no equivalent component. There is no local state that can disagree with the repository; the repository is authoritative and the index is rebuilt from it in memory each run. restic's mirror-image problem is that this index lives in RAM during prune, so multi-terabyte repositories with tens of millions of blobs want several GB and get OOM-killed on a small VPS. Both tools have a "the metadata is the hard part" problem. Duplicati's costs you an evening; restic's costs you a bigger backup host.

Where Duplicati genuinely wins#

Two places, and they are not small.

Storage backends. More than twenty, including OneDrive, Google Drive, Dropbox, Jottacloud and pCloud. restic speaks local, SFTP, REST, S3, Azure, GCS and B2 natively, and reaches the rest only through rclone:

rclone config                       # set up an 'onedrive' remote
restic -r rclone:onedrive:backups init

That works well and it is two tools to install, configure and update instead of one. If your only storage is a family Microsoft 365 subscription, Duplicati is the honest answer.

The person who is not you. A browser interface with a schedule picker, a restore browser and email notifications is what makes backups happen on a desktop belonging to someone who does not use a shell. restic ships no GUI, no dashboard and no scheduler, and the third party wrappers are yours to maintain.

Where restic wins and it is not close#

Immutability. Duplicati's client holds delete rights on the destination by design, because it prunes remote volumes itself. There is no append-only mode. restic can push to rest-server with --append-only, or write to a bucket with S3 Object Lock, so a compromised client cannot erase its own history. If ransomware resistance is on your list, this ends the discussion.

Scale. The per-job SQLite database and recreate times are where Duplicati stops being pleasant, and the boundary is roughly millions of files or many terabytes. restic's ceiling is higher and its failure mode there is memory, which you can buy.

Auditability. A restic backup is one command with an exit code:

restic backup /srv /etc --exclude-caches --tag nightly
restic forget --host web1 --keep-daily 7 --keep-weekly 4 --keep-monthly 12
restic prune --max-repack-size 20G --retry-lock 10m
restic check --read-data-subset=1/10

You can read that in a cron log, alert on it, and reproduce it on any machine. Duplicati's equivalent is a service, a database and a UI.

Attack surface. Duplicati listens on 8200 with a web application in front of your entire filesystem. Put it behind Caddy and an auth layer (Reverse proxy and TLS, Single sign-on for self-hosters) and never expose it directly, since it supports local passwords only and has no OIDC.

Which one for your situation#

What to do next#

If you are on Duplicati and it works, do three things this week: confirm you are on the stable channel by date rather than version number, wire it into whatever patches the rest of your machines because it no longer self-updates, and add /data to your other backup so a database recreate is never on the critical path.

If you are choosing now for a server, use restic and size it first with Backup planner. Then read Backups that actually restore and rehearse an actual restore, because the difference between these two tools matters far less than whether you have ever restored from either. If you want a middle path with a GUI and a repository server, restic vs Kopia covers Kopia, and restic vs BorgBackup covers the SSH-only option. For a destination to write to, MinIO vs Garage and Garage are the current answers, and rclone handles the cases where you want a mirror rather than snapshots. The full Backup category has the rest.