Published: Last updated:

Duplicati

Duplicati is an open-source backup client that writes encrypted, incremental backups to many different storage destinations. The data is encrypted locally before it leaves the device, and the real test is not the backup but the tested restore.

Anyone who wants to put backups out of their own hands without having to trust the storage location faces a double task. The data should go to a remote place, and that place should not be able to read it. Duplicati solves both: it encrypts on the client side and then stores the backup wherever the space is, from a local NAS to a foreign cloud. That makes it a building block of sovereign infrastructure, and it closes the gap that continuous synchronisation leaves open: sync like Syncthing keeps devices current, but sync is not a backup. This page describes how Duplicati works, how mature the project is, and why the restore test decides everything.

The principle

Duplicati treats the files to be backed up as a stream of fixed-size blocks. Each block is stored only once; if the same content appears again, the backup references the block already stored. This deduplication is the reason why only the first backup is complete and all later ones transfer only the blocks that actually changed.

  • Block-based and deduplicated. The documentation puts it plainly: blocks are only stored once to save storage space. Changed files produce only new blocks, not a new full copy.
  • Encrypted before upload. Duplicati encrypts the backup data with AES-256, optionally also via GNU Privacy Guard, before it leaves the device. The storage location sees only encrypted containers, not the content.
  • Compressed and bundled. The blocks are compressed and packed into container files, which are then uploaded to the destination. A local database records which block sits in which container.

Duplicati is open source under the MIT license. The project was formerly released under the LGPL and moved to the MIT license in 2024, alongside the founding of Duplicati Inc. The code is open, the method is verifiable, and there is no vendor lock-in to a backup service.

Many storage destinations, one client

Duplicati's strength is the separation of backup logic from storage location. The same client writes to very different destinations, local and remote alike:

  • In-house infrastructure. Local drives, network drives (SMB), and the organisation's own servers over SFTP, FTP or WebDAV.
  • Object storage and cloud. S3-compatible storage (such as Amazon S3 or Backblaze B2) and services like Google Drive, OneDrive or Dropbox.

Because the data is encrypted on the client side, the storage location does not have to be trustworthy. That is exactly what makes Duplicati the practical implementation of the off-site copy from the backup and restore strategy: the third copy in a physically separate place, without that place gaining any insight into the data.

How a backup is created

A backup runs through the same sequence whether it goes to a NAS or into a foreign cloud:

flowchart TD
    A["Source data<br/>selected folders"] --> B["Split into blocks<br/>fixed block size"]
    B --> C["Deduplicate<br/>detect new blocks"]
    C --> D["Compress and<br/>encrypt with AES-256"]
    D --> E["Upload to destination<br/>NAS, SFTP, S3, cloud"]
    E --> F["Verify a sample<br/>backup-test-samples"]
    F -.->|restore test| G["Restore<br/>actually verified"]

The step after the upload is the one that often gets overlooked. After every completed backup, Duplicati can automatically download a sample of the uploaded containers, decrypt it and check it against the stored hashes. This automatic check is controlled by the backup-test-samples option and defaults to one sample per file type. It can be set to zero or switched off entirely, which disables the check. The dashed path to the restore test is the more important one and is not automatic: it has to be done deliberately.

Why the restore test decides

A backup that has never been restored is an assumption, not a safety net. The backup and restore strategy puts it bluntly: a backup that has not been successfully restored does not, in effect, exist. Duplicati offers two stages here that build on each other.

  • Automatic verification. The sample mentioned above, taken after every backup, checks whether the uploaded containers are readable and unaltered. The test command does the same on demand and, on repeated runs, checks different samples in a rolling fashion. This answers the question whether the backup files are intact.
  • Real restore test. But it does not answer the actual question: can the right data be brought back to the right place, completely and within the expected time? Only an actual restore shows that, for example into an empty target directory. Only this test connects the tool to the RTO and RPO targets that the backup and restore strategy defines.

Automatic verification does not replace the restore test; it is its precursor. Intact containers are necessary but not sufficient.

Placing the maturity realistically

Duplicati has a long maturity history, and that belongs to an honest assessment. Today's 2.x generation spent many years exclusively as a beta. Only in early 2025 did the first version labelled as stable appear; the project itself framed it roughly as Duplicati now being stable after years in beta. The current stable line is version 2.3.0.3 from June 2026, complemented by a canary channel for pre-release versions.

In practice this means: Duplicati is a stably maintained tool today, but the long beta phase is one more reason to rest any backup not on assurances but on a regular restore test. Whoever uses a tool sovereignly tests it against its real emergency, not against its version number. The same applies to alternatives such as rsync, which mirrors rather than versions a backup, and which solves the other half of the task.

Where Duplicati fits and where it does not

  • Fits. Encrypted, deduplicated backups to freely chosen destinations, including storage that need not be fully trusted. A clean off-site copy of the 3-2-1 rule without the storage location gaining insight.
  • Fits with discipline. As a reliable safety net only with verification switched on and a regular restore test. Without this discipline the tool backs up a feeling, not the data.
  • Does not fit as sync. Duplicati is not a tool for keeping devices continuously current. That task is solved by Syncthing, which is explicitly not a backup. Backup and synchronisation are two separate tools for two separate problems.

References

  • Duplicati v2.3.0.3 Stable Release. Current stable version of the backup client, open source under the MIT license. (10.06.2026). github.com/duplicati/duplicati
  • Duplicati After Years in Beta. Announcement of the move from the years-long beta to the first stable version. (28.02.2025). duplicati.com/articles
  • Duplicati How the Backup Process Works. Documentation on blocks, deduplication and client-side encryption. (2026). docs.duplicati.com/
  • Duplicati The Test Command and backup-test-samples. Documentation of the automatic sample check after every backup and of the manual test command. (2026). docs.duplicati.com/

Related topics

  • Disaster Recovery, the backup and restore strategy that Duplicati feeds into as the off-site copy.
  • Digital Sovereignty, control over data and storage location without outside insight.
  • Syncthing, continuous synchronisation that is explicitly not a backup.

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.