I just got done setting up Duplicati, and while it was truly a breeze to do, I have a few minor gripes that I think, if fixed, would greatly improve usability.
They are:
Call to action should lead into getting started article somehow. Either link the article directly and link the download page in article, or link getting started article on download page.
Rename articles button on website to documentation, guide, help, or getting started or something
Link to documentation/forums on the webui itself would be nice (see syncthing)
related: why do you have a link on your webui to your basically dead google group when you’ve got such a thriving forum?
Add backup’s destination screen should make it clear that new backups will not create folder for themselves, specify if each backup should live in its own destination folder (should it?)
related: new folder button in destination path picker would be really nice
On point 5: I know I should have checked first, but I assumed every backup set or whatever would create its own folder, so I just made a folder called ‘duplicati backups’ that I wanted to put backups of various nas shares in. Seeing as it doesn’t, I have to wait for my backup to finish and move its contents to a sub folder before I set up my other planned backups. Not a huge inconvenience, but I wish it had been explicit instead of leaving me to assume (even though assuming the files will go directly into the folder you choose may seem like the more common assumption). Seeing as each backup needs its own folder, I think a new folder button might be in order, at least on local drives.
Yes, but that was for the first backup job on each machine, right? I think what @chuckdries meant (and what I think is a good idea) is that if you create a second backup job on the same machine will not create a new folder. Or am I missing something?
Oh, you mean like if no destination folder is set at a target, and a second job is configured for the same target also with no folder, and the ensuing madness of conflicting file sets? That makes more sense. In that case I agree, the UI could offer a bit more explanation as to what the constraints / expectations / recommendations are re: folder separation etc.
Yep! So I simply made a folder titled “backup,” where I hoped to back up multiple different folders on different settings. I believe the UI should make clear that each backup set/folder/whatever you wanna call it, will need its own unique destination folder that I must create myself.
Just for clarification i think the UI will create it for you - i assume you just mean the user needs to know to enter unique folder names for each set?
Perhaps it will if you manually type a path, but if you use the folder picker on a local directory like I did, it doesn’t appear to.
So:
I added a backup called “Projects”
I set the destination to a local folder called “…/backups” by clicking it in the folder tree
As it started backing up, it just started dumping files into that backups folder, not, say /backups/projects like one might expect it to. It does not appear to create folders
Oh, i understand what you’re getting at now, sorry - a user might reasonably expect that a new subfolder would be created at the specified destination based on the backup set name. I’m trying it now and I do understand that it might be nice to have the “create folder” control there and some sort of explanation that you should create (or type) a new/unique folder before running the set.
I was probably thinking of the configuration for B2 backup where you specify a bucket and a remote folder and Duplicati creates it all for you, but the local folder config is a bit more confusing.
Yes, that’s the way it works. Autocreation of a subfolder surely could help to avoid mixing backup tasks at the backend, but thinking of it I suppose there is a pitfall: Duplicati must somehow rename the folder automatically if the backup name contains characters that are not supported by the file system at the backend. There are 2 ways of handling this:
Just remove or replace the characters that are not supported by the selected backend.
Backdraw is that Duplicati should have an internal renaming convention for every single backend. There is a (very small) chance ending up with a duplicate folder name (in rare situations a user could have these 2 backup jobs: “Movies ranked with a *” and “Movies ranked with a ?”). Duplicati should handle all possible problems for all posiible packends.
Convert all characters to upper case and remove all characters that are not alphanumeric. Almost all backends will support the result as name in the file system.
Backdraws: bad readability (PC-Office-02 Important files wil be renamed to PCOFFICE02IMPORTANTFILES), more chance to end up with duplicate folder names, which Duplicati should handle somehow.
Also, a too long backup description could cause autofolder creation to fail if the file system at the backend doesn’t support it.
Yes, unless the user wants/needs to access the backend, for example when backing up to a local disk and/or someone wants to synchronize the backup folder to another storage platform. This scenario is discussed some times, for example here:
Also, I rather like being able to tweak the names of my backup sets without worrying about the impact it’ll have on the backup folder(s). For example with B2, it’s impossible to rename buckets or folders after they’re created.
If a backup job name is modified, the folder name at the backend can stay unchanged. This will allow you to modify the backup name without unwanted side effects, but the relationship between folder name and backup task can become unclear.
For me, I’d also like to name the destination folder myself. Folder names are related, but not the same as backup names.
Same here.
That actually makes an idea occur to me - when a user first gets to the “folder name” entry point in a new backup job, would it be possible for Duplicati to auto-generate a suggestion, based on the backup name? The user could then provide something else if needed (i.e. a simplification). And perhaps display a warning if none is provided, in case users don’t realize that piping different backup sets into the same folder would cause issues.
Would the proposed (or user entered) name then have to be checked against the destination to see if it’s already in use?
I don’t recall seeing it but one (not necessarily good) way of dealing with the disallowed character issues would be to do something like a URL encoding on those characters.
Oh, and if Duplicati starts auto-creating folders, does that mean it will no longer be possible to have multiple differently-prefixed backups in a single folder?
Good points @JonMikelV. Thinking a bit more about it, I doubt in how many cases the provided suggestion will suffice.
I guess a tree structure at the backend is used to organize backups. Backup names should be descriptive by itself.
Example, if I want to create a backup job for my pictures located on PC01, I could give the name “Pictures on PC01” and would store it in backend://fqdn/Backups/Duplicati/PC01/Pictures. The suggested “Pictures%20on%20PC01” would not help if I want it to be “/Backups/Duplicati/PC01/Pictures”.
Agreed, the encoding of names to handle disallowed characters is solely to resolve potential collisions due to character replacements (such as * and ? with -) but it’s a terrible user experience for somebody who wants specific folder names in the destination.
Using pre-create / pre-rename destination checks to make sure the folder name (no matter what it is) is available is a much better user experience - but likely slightly more difficult to implement.
This sounds great, but we should at least put a note in the getting started documentation or the UI itself to clarify the behavior until we get around to implementing sub folder creation.
A note in the UI that informs the user that each backup set needs its own folder and a manual create folder button sounds like a relatively easy thing to implement right?