First of all, great work. Duplicati is quite impressive and already beats the pants off a lot of commercial systems I’ve used in my 25+ years in IT.
One small thing I would love to see is the ability to tag backups and/or add comments to versions both at version creation and at arbitrary occasions in the future. I’m thinking along the lines of tags commit comments in revision control packages (Git, Perforce, etc).
To illustrate, I’ll use a recent real-world scenario: I made sweeping changes to my Photo library (which I smartly had backed up with Duplicati for several months before) and didn’t notice that some EXIF data had been broken for quite some time following. Subsequent changes were made and now I was several revisions deep. Through a lot of datestamp research and a long afternoon learning the finer points of exiftool, I was able to eventually figure out the version(s) I needed to restore from Duplicati but it was a painful process.
What I would love to do is be able to run a backup before I’m going to do such things in the future and either programatically or manually tag it as “The one before I screw everything up” or some more proper descriptive text. (For bonus points, I would love to then also be able to “pin” that version as a “NEVER DELETE” version - another potential feature ask.)
I have also had occasions where I’ve wanted to note specific events retroactively, i.e. “This was the last backup before I moved to a new workstation.” Being able to tag arbitrary versions would be the ask.
I know I can do this outside of Duplicati with judicious note-taking but it would make the package a more complete solution for archiving.
Again, thanks for your hard work. I am rapidly becoming a Duplicati evangelist.
I believe the Description field is not what was asked in this thread. The description is about a general description for the backup as a whole, not a specific run.
Correct, I’m hoping for a per-version naming scheme. Ideally, one that could be specified at backup time, i.e.:
duplicati-cli backup [source] [target] <various options> --backup-comment="Preparing for migration to new storage array."
But also offering the ability to retroactively name a backup run/version, i.e. “2018 Q4 Keep - Final version before someone inserted cat GIFs during the NYE party.”
FYI, I was poking around restic and discovered it’s pretty much doing what I’m hoping for with it’s “tag” commands. I’m not swayed enough by the rest of restic enough to want to switch though. Tags are pretty much the only thing I like better there.
Let’s see… New table to store comment… Update dlist format to include comment on… Add parameter to accept comment… Update UI to get / show comment…
Sounds good to me!
Question - should an empty comment being passed to a previous version that already has a comment be treated as “please delete comment” or “ignore this unfilled parameter” (meaning a specific delete comment feature is needed)?
The concept I had was that it would be a single tag. An update would replace an existing tag. It would be on the user to make the tag meaningful by retaining existing information in the update/replacement or not. Likewise, a “delete” would be updating using an empty string, perhaps?
I like this idea. For example, if I am working on something I can trigger a backup manually and tag something like “before docker” or something so I know which backup to restore to if something goes wrong. Mapping back with times may not be as feasible.
That should be fine as long as the description comes in the version list drop down along with the time of backup. The point is to identify specific backup versions from the list while restoring.
The UI for this was always a question, and UI developers are even scarcer than C# ones. Any helpers? Duplicati is a community effort, and relies on volunteers, otherwise progress doesn’t happen (or worse).
There’s actually another short part of the dropdown line possible, but would a short tag be helpful at all?
Implementing it might be done with a similar change to the dlist files, but how would one do the UI for it?
At the destination, each dlist file is a backup version, so tag editing would be tough (no database there).
If really necessary, it might be possible to leverage the code where Repair can upload deleted dlist files.
Next time it goes up, put the new tag on it. Regardless, still needs some UI and importantly, developers.
