Copy command hanging at the start

I initialized a local repository as well as a remote one on a Backblaze B2 server, then did my first initial backup successfully to the local repo (external HDD), and am now trying to copy that backup to Backblaze using duplicacy copy. However, after running that command, Duplicacy doesn’t seem to be doing anything.

Here’s the full command I ran:
duplicacy copy -threads 10 -from local_storage -to remote_storage *>> C:\Users\[redacted]\duplicacy_copy.log

Here’s the full output I see in the log file so far:

Source storage set to D:\Files\DuplicacyBackup
Destination storage set to b2://[redacted]
download URL is: https://f000.backblazeb2.com

There has been no additional output for 15 minutes, and duplicacy.exe has stayed at 0% CPU usage in Task Manager throughout. Has something gone wrong? Is it safe to Ctrl + C in powershell at this stage and attempt again?

I’m using CLI version 2.5.2. Apologies if this has been asked already; I couldn’t find a thread.

The first thing copy does is to list all the chunk directories on the destination storage, which can take some time.

To get an indication of progress, add -v just after duplicacy and before copy and you’ll see that it lists each of the 256 subdirectories from FF to 00. (You can refresh the log file in notepad or whatever by just reloading the file.)

Thanks for the quick response! Is that wait time still expected even though the destination storage is empty? This is my first time copying the initial backup to it. I’m also confused by the lack of any CPU/network activity from duplicacy.exe in task manager.

Ideally I would cancel the task with Ctrl + C and try again with -v, but is that safe?

In that case, that stage of the check should be almost instantaneous, but what does your log file currently show?

But yea, Ctrl-C and run again should be safe.

There was no log output except what I pasted in my OP until I hit Ctrl + C. Then it suddenly populated with the prompt for my Backblaze password. Oops. I guess redirecting output in PowerShell with *>> blocks stdin?

Either way, I was able to work around that by storing my Backblaze password in the preferences file, and duplicacy seems to be happily uploading now.

Thanks for your help!

No worries.

In future - because you’re working on Windows - Duplicacy can store the storage password in the credentials/keyring area, which would be better than storing the password in plain text in the preferences file.

So all you have to do is run a duplicacy list -storage B2 command (without redirect) just once to get Duplicacy to prompt you for the password. When you enter the password, it should get saved in the credentials and subsequent commands on that storage won’t prompt for a password.

(Obviously, remove the password from the preferences file before doing that, otherwise it won’t prompt for the password.)

1 Like

I was wondering how to do that, thanks! Is it safe to edit the preferences file directly to remove the stored password, or can I somehow unset it via CLI?

I’d make a backup of it just in case, but you should be able to remove the password line - the “password”: “blah” bit, making sure the last line in that section doesn’t have a comma at the end of it.

Actually, y’know… it might depend on what type of password you entered there, as I’m not sure if all types of passwords (like B2 keys) can be stored in the credentials/keyring. I guess one way would be to test it by doing the list, entering the passwords and doing another list to see what it remembered.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.