Allow either a backup or a restore process to run, not both at once

Feature
#1

I have a setup where I run a script at the beginning of the backup to start the computer and at the end to shut it down.

I was restoring some files that were taking several hours to restore and unfortunately for me I had a backup scheduled that kicked in during that process. I thought that duplicacy would first complete the restore and then complete the backup, but that was not the case. Instead the backup ran along side the restore and then shut down the machine.

I propose to implement a toggle (for those where this is not an issue to maintain the current setup) to invoke exclusivity of one process over the other. A restore can not be started while a backup is running and vice versa.

#2

Running restore should have no bearing on backup. Those are separate operations. Introducing even optional dependency would be counterproductive.

Why not check in your shutdown script it duplicacy is running andā€¦ not shutdown? Asking duplicacy to add a feature to workaround a bug in your external scripts is hardly a good approach. Or implement shutdown on idle in the server side ā€” that way it will be safer and more robust.

Or pause backup schedule for the duration of your restore.

#3

Iā€™m curious, where this script runs, since it starts before the computer itself? Is this ā€œcomputerā€ a VM?

#4

I am not sure that it would be counterproductive, but I take your point.

When ā€˜restoreā€™ runs, does it set a flag that I could query?

#5

I have my backup schedule sandwiched between a prune command at the beginning and a check command at the end. I run a script ā€˜pre-pruneā€™ and a second one ā€˜post-checkā€™, which respectively turn the backup computer on, and run a mover/cleanup command + shutdown.

The computer is a physical box that I can start via a magic package. Works really well. The scripts themselves are started from duplicacy itself. I quite like this solution as I get the log output from within duplicacy, making this a handy solution for my specific problem.

Perhaps it is also useful to note that I run duplicacy as a docker on an UNRAID machine.

#6

I donā€™t think so. But you can check if any duplicacy CLI engines (beside this current one) are running in your post script, and if so ā€“ donā€™t shutdown the host, or keep stalling in the polling loop. Even brute force so:

while [ $(ps aux | grep duplicacy_linux_x64 | grep -v grep | wc -l)  -le 1 ]; do
    echo "Waiting for other duplicacy tasks to complete"
    sleep 1
done

ssh myserver.local "shutdown -s now"

Alternatively, donā€™t shut down the server, period. When all activity ceases it will sleep on its own. No need to micromanage that.

1 Like
#7

thank you! I will experiment with this on the weekend