Feature request: "-repo" option for backup command

For automating unattended backups with Duplicacy CLI I feel it would be convenient to pass the “repo to be backed up” as a parameter to the backup command, rather than requiring the working directory to be the repo itself. Obviously I would not ask that the current working directory functionality be removed, only that something like duplicacy backup -repo /path/to/repo be an option that is supported in addition.

Giving it a second thought, I’m not sure how exactly this would be superior to the working directory functionality (or if in fact it would indeed be superior at all), but something about the need to ensure that a backup task is run from the correct directory strikes me as a potential source for error.


It would simplify the task scheduler setup as I don’t need to fuzz around for setting the working directory of the duplicacy task…


The -repository option of the init command allows you to set up a ‘pseudo’ repository and the actual directory to be backed up can be different. Is this what you want? You’ll still need to change the current working directory to this pseudo repository before running the backup.

This is how I have my repos set up (I have a number of ‘pseudo’ repositories all set up at /backup/repos/repo1, /backup/repos/repo2, et cetera). Thank you very much for adding the -repository option for the init command, that’s actually what inspired this request!

For crontab purposes, rather than prepending cd /backup/repos/repo1 && (or similar) to the head of each duplicacy backup cron job, and rather than writing a short wrapper script that takes a repository path as an argument (and then cds to that path before initiating the duplicacy backup job), I’m requesting that users be able to pass the repository path directly to the backup command, e.g. duplicacy backup -repository /backup/repos/repo1.

I guess when you really break down this request to its core, what I’m actually asking for is a backup command option -repository </path/to/repository> that would shift the burden of responsibility for changing the current working directory onto Duplicacy itself rather than onto the user (or the user’s automation).

This is not a very high priority issue for me, but I think it could possibly help clean up various cron jobs a little.

Yes this is precisely what I was thinking with this request, that it would be a small quality-of-life improvement for scheduling duplicacy backup jobs in crontab.

If this is considered to be added, I think repository should be added to all? commands (list, prune, what else?)

1 Like

-repository is already in use. (Indicating to init the “real” folder to back up)
What you want to point to is the preferences folder for this backup. Not sure what a good name would be, but since it replaces a CD command, maybe it could be called -cd ?
(-prefdir is also a bit different.)

-cwd, perhaps? Change working directory.

1 Like

I think that would make sense, and is a great idea.

That’s a good point. The idea of a -repository option for the backup command came up to me because “repository” was the concept that made the most sense when considering what the backup command is actually doing, but you’re right that the init implementation has a completely different context than the one I’m thinking of. It’s kind of a shame, because I feel like the directory containing a .duplicacy prefs dir is actually more of a “repository” than the init-specific usage, but I would not want to create the possibility of ambiguity or confusion.

I’m curious if others feel the same way, that having duplicacy init -repository have a different/unique meaning compared to a hypothetical duplicacy backup|restore|list|check|prune|add -repository would be a strong enough reason to choose another name for the option?