Controlling backup behaviour when errors occur in pre/post scripts

[niels]

Hi,

We’re looking into using Duplicacy for backing up our Linux servers’ entire filesystem. I’ve created a backup policy that has a pre/post-backup script that does the following:

1. Run “flush tables with read lock” on MySQL,
2. Create LVM snapshot & readonly mount it on /mnt
3. Unlock MySQL tables
4. Start backup of /mnt
   …
   After backup in post-backup script:
5. umount /mnt
6. remove LVM snapshot

This works well, however I have noticed that when there is a non-zero exit code the backup still continues. So if something goes wrong while settings up the LVM snapshot duplicacy still continues even though there will be nothing in /mnt as no valid snapshot can be mounted.

Is there a way to control this behaviour from within duplicacy? If something goes wrong in the pre-backup script I would like to prevent duplicacy from running at all and be notified of this. I can built logic into the pre/post-backup scripts that notify me when something goes wrong, so no need to do that from within Duplicacy itself, but it would be great if I could also abort duplicacy if something goes wrong in the pre-backup script.

Cheers!
Niels

[TheBestPessimist]

Instead of using pre-post scripts controlled by duplicacy, why not make a mega script which calls pre, checks status, then calls duplicacy, checks status, then calls post, checks status.

By doing it like this, it should be very easy to control anything you want in all steps, and also send yourself notifications/mails as needed.

[saspus]

Instead of using pre-post scripts controlled by duplicacy, why not make a mega script which calls pre, checks status, then calls duplicacy, checks status, then calls post, checks status.

Megasxript is actually a very good and straightforward idea that does not even require use of pre- and post- script support in the first place and that did not occur to me either, when I asked for this: Duplicacy should not proceed if pre-* scripts fail.

But this is only doable in a very small set of circumstances (Linux/Darwin hosts that run duplicacy via CLI automation)

There is still value in having pre and post scripts being able to modify behavior of the the backup engine when launched from the GUI, where the trick of replacing call to duplicacy CLI with the megascript will not persist through software update (and is very difficult to accomplish on windows to begin with).

Therefore I’m onboard with @niels’s request and I think this should still be implemented.

[niels]

Cheers,

I’ll create a wrapper script to handle this. It’s no problem to do it that way, though of course I’d rather not if pre/post-scripts have that feature built-in, which is why I asked if this was possible.

[gchen]

I agree this is a desirable feature. I’ll implement it right after the holidays.

[dtownsend]

Please note my similar request to get some kind of status of the backup passed through to the post-backup script. One example is wanting to have the script send me a notification if the backup failed in certain ways.

This is the request:

Does duplicacy pass any information about the backup to the post-script

When duplicacy runs the post-backup script does it pass it any arguments? It would be super useful to say pass some information about whether the backup failed and counts of failed files and such. Worst case the path to a log file would at least make scraping that data possible.