I’m trying to setup a backup to an external USB drive in a linux machine.
I’m very concerned about what could happen if duplicti runs a backup and the USB drive is not mounted at that time. If that happens, then duplicati will try to write the backup to the local “mounting point folder” in the system which will quickly fill that disk.
I read that a solution to this problem is to use the advanced option “–alternate-destination-marker” and indicate the name of a file in the drive. Duplicti will then verify the existence of this file (therefore confirming that the drive is mounted) before doing any backups. If it doesn’t find the indicated file then the backup fails. This sounds exactly like what I’m looking for.
However, the instructions indicates that this option must be used in conjunction with “–alternate-target-paths”. My understanding is that this option is to indicate a secondary target folder to serve as a backup if the principal target folder is ever disabled.
This is not my case and i don’t have a secondary target folder. So, if i wanted to use “–alternate-destination-marker” and only have 1 destination folder (the USB Drive), should i enable the option “–alternate-target-path” and leave its value empty as “”?
Any explanation on how to achieve this intent would be greatly appreciated.
Unless it’s initial backup, it will more likely error out because all the expected files are missing.
If you want to ensure this can nver happen, you can use chattr to make your folder immutable.
When I tried an empty option in the GUI, it took that as a request to check a folder called “true”
in addition to the primary destination. The right folder given twice would also seem reasonable.
On Windows, I tested a non-existent drive letter and that worked too, so maybe lots of options.
Improving Reliability with Large Backup Sets gave a script you can use with run-script-before,
which should let you get quiet non-runs when the drive is missing (still waiting for test though).
I agree, lots of option.
Based on my research, it appears that this is what most people are doing. I’ll give it a try. I guess that i just got confused with the official description of the function --alternate-target-paths.
I would argue that these functions should be called “–destination-marker” and “–destination-marker-path” to avoid confusion. Or maybe have only 1 function called “–destination-marker” and allow people to add the path and marker filename on the same field like “*\folder-path\markerfile.txt”, this would make it very clear and easy to understand.
It might be confusing in this use case because it was not intended for this case.
Windows Drive Letters and “alternate-*” might be the original intention for these.
If you would like to make a UX or Features category proposal, feel free to do so.
This will let other readers find it to give feedback. It also needs to be compatible.
Synonyms are sometimes possible, but breaking current use is not a good idea.
Current help text is pretty long. I fear for how long the all-in-one proposal will get:
C:\ProgramData\Duplicati\duplicati-188.8.131.52_canary_2021-03-10>Duplicati.CommandLine.exe help alternate-destination-marker
--alternate-destination-marker (String): Look for a file in the destination
This option only works when the --alternate-target-paths option is also
specified. If there are alternate paths specified, this option indicates
the name of a marker file that must be present in the folder. This can be
used to handle situations where an external drive changes drive letter or
mount point. By ensuring that a certain file exists, it is possible to
prevent writing data to an unwanted external drive. The contents of the
file are never examined, only file existence.
C:\ProgramData\Duplicati\duplicati-184.108.40.206_canary_2021-03-10>Duplicati.CommandLine.exe help alternate-target-paths
--alternate-target-paths (Path): A list of secondary target paths
This option allows multiple targets to be specified. The primary target
path is placed before the list of paths supplied with this option. Before
starting the backup, each folder in the list is checked for existence and
optionally the presence of the marker file supplied by
--alternate-destination-marker. The first existing path that optionally
contains the marker file is then used as the destination. Multiple
destinations are separated with a ";". On Windows, the path may be a UNC
path, and the drive letter may be substituted with an asterisk (*), e.g:
"*:\backup", which will examine all drive letters. If a username and
password is supplied, the same credentials are used for all destinations.
There’s also a conceptual issue where current use of “path” means singular (typical for the UI),
and not $PATH for those familiar with the concept of a search path as your terminology implies.
--destination-marker, how does primary path work? Is it invisibly implied first?
Possibly that’s another reason why the current terminology is so oriented around
I’m not sure how easy/hard it is to ignore the primary path, and how can one explain doing that?
There’s also the issue of undesired popup errors for the can’t-find-marker-anywhere scenario…
There are far more things that can be proposed than can be done, BTW, but one can discuss…