Déjà Dup has used Duplicity since its beginning, over 15 years ago. Though it’s never been intended as a Duplicity frontend, but rather a backup app that used Duplicity behind the scenes.
And for the past four years, folks have been able to use an experimental Restic backend instead of the usual Duplicity one.
Over those years, the feedback has been positive, bugs have been fixed, and feature parity has been achieved.
I think it’s time to promote the Restic backend out of experimental mode and into real world usage.
Benefits of Restic
i.e. Why even consider Restic when we have Duplicity?
First, a couple words about how each works. (extremely simplifiedd)
- Duplicity takes a “rolling incremental” approach. Each snapshot builds upon the previous ones, in a continuous chain. Déjà Dup occasionally creates a new full snapshot so that older chains can be deleted.
- Restic takes a “repository” approach where chunks of files are stored in a folder tree with associated metadata connecting the chunks to files and snapshots.
Now back to the benefits of Restic:
- Faster
- About twice as fast in my testing
- More robust
- If anything goes wrong in Duplicity’s chain of incrementals, it can have a difficult time recovering, since all the future snapshots depend on the previous one. Whereas restic has some tooling around fixing problematic repositories
- Restic also seems to handle interruptions more gracefully
- More flexible, enabling possible future Déjà Dup features:
- Changing your backup password
- Searching the repository directly, using less memory
- Snapshot management (e.g. deleting snapshots at will)
- Limiting upload speed
Current situation
- Déjà Dup defaults to using Duplicity and puts the files directly in the storage folder.
- If Déjà Dup was built with
--Denable_restic=true
, you can opt into using Restic instead in the Preferences dialog. Déjà Dup will put Restic files in arestic/
subfolder of the storage folder.
Coming plans
- Add code to detect whether the storage folder holds Duplicity or
Restic files (including looking for arestic/
subfolder). - If the storage folder holds Restic files, use Restic. If Duplicity files, use Duplicity.
- Add a new build flag
-Ddefault_tool=duplicity/restic
that will determine if Déjà Dup will use Duplicity or Restic for fresh backups into empty storage folders. This will default toduplicity
for continuity. - But the official Déjà Dup flatpak builds on Flathub will instead use
restic
as the default tool for new backups, to begin getting broader testing.
Down the Road
Eventually if feedback continues to be positive, we may remove the build flag and unconditionally default to Restic, even for non-Flathub builds.
But existing Duplicity backups would continue to be supported. And any change there would be well advertised in advance and/or we’d offer some clever migration path. I’m not in a rush here and want to handle this cautiously.
Thoughts?
Please chime in with your experiences with Restic or concerns or happiness with this approach. Thanks!