I have a Mac on which there are two backups - one to a remote SFTP destination and one to a not-always-plugged-in USB drive. Both are scheduled to run daily.
The SFTP job runs just fine but I’ve been fighting with the USB destination for weeks now, however I think I finally figured out what was going on so I thought I’d share in case others have insight or similar experiences.
On initial backup creation while the USB drive was connected I set the destination to /Volumes/Backups/Duplicati. The “Test Connection” worked as expected and created the “Duplicati” folder on the “Backups” USB drive. The job also ran just fine.
However, once I removed the drive if the job auto-ran or I did a “Test Connection” again Duplicati would create a FOLDER tree of “/Backups/Duplicati” in /Volumes. This means that when the job runs it reports missing files because it’s looking at the Backups “folder” not the Backups USB drive.
To make things worse, even after attaching the USB drive it still seems to try to back up to the folder not the USB drive.
Once a deleted the /Volumes/Backups FOLDER (with the USB drive disconnected, just to be safe) then plugged in the USB drive and ran a backup everything worked just fine.
So I guess my questions are:
Is this a normal thing (create folders in /Volumes) for a Mac to do or should it be considered a bug that Duplicati is doing so?
Would the --alternate-destination-marker parameter work on a Mac?
How does the wildcard thing work, is it (in unix terms) globbing (I guess) or regex (probably not)? And how do I work with drive names (mount points) that have whitespace in them (the 0.5 manual explains neither of these).
If the partition is called “Backup Disk”, the mount point is “/Volumes/Backup Disk” and I would suspect that I need “/Volumes/Backup Disk*/” for alternate-target-paths and a target-marker to make sure Duplicati does not create the directories when the disk is not mounted. Correct?
Without globbing it could work too but it would not be robust in case a second partition named “Backup Disk” is mounted.
I have limited access to the Mac that I have this working on - luckily that access includes today, so I’ll review what I’ve got working there and let you know in a bit.
If I recall correctly I didn’t use the --alternate-target-paths parameter at all. But if you want to read up on where I learned figured this stuff out, I got it at:
We might need to give that page a title update to be “Changing Windows Drive Letter and MacOS Mount Point Problems”.
At the moment I’m not sure if the “/Volumes/xxx folder is created if USB drive not mounted” issue is a Duplicati bug (maybe it’s trying to create the destination if it doesn’t exist) or a MacOS issue (maybe it’s taking Duplicati’s “does this exist” query as a “please make this exist” command).
As for wildcards, other than the * mentioned in the link above to check all drive letters (on Windows) I haven’t tried anything else.
Note that the following “fatal error” is generated when the job runs and the drive is NOT attached, so it looks like the --alternate-destination-marker file can live in the drive root OR the actual backup destination folder. But because of the fatal error I also set the --send-mail-level to Success,Warning,Error.
Fatal error
Duplicati.Library.Interface.UserInformationException: The marker file “DuplicatiDrive.txt” was not found in any of the examined destinations: /Volumes/My Backups/Duplicati/My Mac, /Volumes/My Backups/
Wildcards in the alternate-paths value on MacOS do not work. Neither the globbing style nor the regex style. I tried /Volumes/Backup Disk* and /Volumes/Backup Disk.* but neither would match the actual mount point /Volumes/Backup Disk 1
The marker and paths option does work to prevent Duplicati creating an alternative backup directory if the backup disk is not mounted. However, if the backup disk is not mounted, it produces an error on the unavailable marker. The disk not being available is more a soft error than a hard error. Ideally, one would ignore the soft error but only start reporting trouble when the situation remains so for a longer time (e.g. when Duplicati has been unable to successfully run a backup because of a missing marker for more than 3 days or so). Now, you will get a failure (and if set up a mail message) for each time Duplicati tries but fails to locate the backup directory because of the missing disk.
The drive versus folder issue shows the Windows-heritage of Duplicati where drive (letter) and folder are quite independent, while on unix-like systems a drive is just a folder in the root file system somewhere and the difference is not visible at the file system level.
