No dedicated Command Line Option for "Copy"?

[GH-User]

It seems there's no dedicated Command Line Option for "Copy", just a combined one:

-b Perform duplicacy backup/copy operation

So I can not start a Copy process without a preceding Backup operation?

I want to run Copy without Backup to copy a local storage to a cloud storage. My workaround: I created a "fake" backup with an empty fake folder that runs prior to Copy.

[jeffaco]

I didn't think this was necessary when I originally coded this. My reasoning:

A storage isn't just random files, its files created by duplicacy. Now, when duplicacy originally ran, that's when you'd want to do the copy (so your repository copies are always up to date). It didn't make sense to me to do a backup to a storage and then not immediately follow by a copy operation.

I can add this (it's certainly easy enough), but I'd like to understand your use case a little better. If you're backing up to a local storage (fair enough), wouldn't you want to copy to the remote storage immediately after that? Why wait?

Thanks.

[GH-User]

My use case:

1. Backing up various folders from various computers to a combined storage on a different (backup) computer:
   – Backup computer PC1 folder ABC to storage XYZcombined on computer X.
   – Backup computer PC1 folder DEF to storage XYZcombined on computer X.
   – Backup computer PC2 folder XYZ to storage XYZcombined on computer X.
   – Backup computer PCXY folder Xxx to storage XYZcombined on computer X.
   etc.
2. COPY storage XYZcombined on computer X to cloud storage Backblaze B2.

a) Since this copy process runs on computer X it must run separately and not combined with one of the preceding Backup tasks that are running on the respective computers.

b) The COPY task will run for many weeks because of the limited upload speed. But I need to restart it again and again because unfortunately Duplicacy suddenly stops if Backblaze B2 gives some random error messages and Duplicacy unfortunately doesn't resume the copy process.

[jeffaco]

Yeah, that's a use case alright.

How do you drive this with duplicacy-util? Do you have different named configuration files so, for example, only one COPY operation will happen at once? You must update storage XYZcombined on computer X while a COPY operation is running, since COPY is so slow?

I'll look at this. There are other changes going into 1.4 that will require minor updates to how you run it (primarily in configuration). I think I'm going to deprecate -b (backup/copy), -p (prune), and -c (check). Then I'll create -backup, -copy, -prune, and -check. The only one that will stick around: -a (all).

The problem with -b is that it's not specific and confusing if I start allowing backup and copy to be separated. Most of the time I use -a except for a very large repository, where check can take a very long time against Google Cloud Drive (like 30 minutes). I don't see a need to run that nightly, so I run it a few times a week via scheduling.

Hopefully that's true with others too, in which case most people wouldn't be affected by this change.

[jeffaco]

b) The COPY task will run for many weeks because of the limited upload speed.
But I need to restart it again and again because unfortunately Duplicacy suddenly
stops if Backblaze B2 gives some > random error messages and Duplicacy
unfortunately doesn't resume the copy process.

I had problems like that with Azure; I reported them and they were fixed. You should open an issue for duplicacy and hopefully this would get fixed.

You could also do some fancy filtering of the log and restart duplicacy-util if there was an odd error. But this is a hack. Or better yet, if you get meaningful error exit codes from duplicacy, then duplicacy-util should return those. You could restart if the error code was one of these retry-able errors.

[jeffaco]

Resolved in commit 0bd554f. Closing this issue.