After looking around, seems like there are two main modern alternatives: borg and restic. Borg seems better for our use case. Stuff like a streaming JSON output option, compression, support for non-encrypted backups. It also has a longer history and a wider development community.
That said... Borg does not support backing up to remote locations (technically it does allow ssh if you install borg on other side). Restic has wide remote support.
So it would require some upstream work to augment borg remote support or some upstream work on restic to close the feature gap.
My current thinking is to recheck the status of the python3 porting effort and see if that can be pushed across the line before py2 goes EOL. That would let us either do nothing or at least take pressure off and let us wait for restic and borg to grow some more.
Our code base has always paid lip service to the idea that duplicity isn't the only possible tool backend we might support. And that concept was one of the reasons I deprecated the non-gvfs-based cloud backends a while back, to make it easier to support a wider set of tools.
Duplicity has been a good tool backend for the past ten years. But realistically, it still creates problems for us. (A) it is complicated enough that a lot of the bugs we receive are actually due to it (or our interactions with it anyway). And (B) it's not clear whether it will be ported to python3 by 2020 when python2 goes EOL. Which will make packaging and supporting it harder for distributions.
I think it would be wise to at least examine the field and consider supporting another tool backend. Even if we don't do anything about it, it would be a useful exercise to understand our options.
Requirements
Here are my initial thoughts on must-haves and nice-to-haves. Any thoughts on these lists?
Must-haves:
- Encryption
- Incremental backups
- Supports POSIX file permissions, even when backing up to locations that don't
Nice-to-haves:
- Baked in support for gvfs (we could always use gvfsd-fuse to expose a location as local directories, but that was a little brittle the last time I tried it years ago)
- Backup files are as non-custom/opaque/unique as possible. Platonic ideal would be a user being able to browse files using normal tools (think an rsync backup). But with all our desired features, that's not likely. Still, something to think about.
- Compression
- Well maintained / well reviewed / considered stable / well translated
Default Tool Migration
If we did add support for a new tool backend, and we eventually liked it as a better default backend, migration to it would need careful consideration.
We do a full backup every few months. So once it was time for a new fresh backup, we could make it using the new tool. And then support restoring with the correct tool depending on the date chosen. Obviously it's not as easy as that. But it *would* be possible to quietly migrate folks.
But anyway, that's a whiles away. I'm not even sure there is an obvious good candidate that we'd like more than duplicity, yet.
Next Steps
I'll start looking at the field. And update a wiki page with the results:
I welcome thoughts! And pointers to potentially suitable tools. I know there's an open bug about supporting the Restic tool (LP: #1800996). I guess I could look into Restic.
_______________________________________________
deja-dup-list mailing list
