Prune - How do i stop backup jobs running if prune is taking forever?

[danmed]

Is there a way to stop a backup job running if a PRUNE is already running?

I currently have 4 schedules…

• PRUNE - 8am every other day
• CHECK - 8am every other day (offset of above)
• LOCALBACKUP - 11pm Daily
• CLOUDBACKUP - 3am Daily.

I understand (i think) that the parralel tick box is only for other backups in the same schedule… is that correct? (i have them all unticked)

My prune command is : -keep 0:365 -keep 30:30 -keep 7:7 -keep 1:1 -a -exhaustive -exclusive

Am i missing something or does a prune automatically prevent anything else from running?

[saspus]

Why do you want to prevent backup from running concurrently with prune?

[towerbr]

Notice that

@TheBestPessimist

-exclusive

Assume exclusive access to the storage (disable two-step fossil collection).

(…)

WARNING: Only run -exclusive when you are sure that no other backup is running, on any other device or repository.

I recommend not using this option for regular prunes. Use it only if you want to do something very specific, like manually deleting a revision.

[danmed]

My Assumption was that it was bad to do so… but it appears as @towerbr has mentioned below, i shouldn’t be using the -exclusive flag.

[danmed]

Thanks for the advice… is the -exhaustive OK or is that not needed either?

[gchen]

-exhaustive is not needed either. If there is an ongoing backup, -exhaustive will unnecessarily attempt to fossilize new chunks uploaded by this backup (and later resurrect them during the next prune run). This option is only recommended if you know there are a lot of unreferenced chunks, for instance when a backup is aborted and never retried.

[saspus]

@gchen

as @towerbr has mentioned below, i shouldn’t be using the -exclusive flag.

Good point. I focused on schedule and missed the -exclusive -exhaustive in your prune command.

Generally, avoid specifying any extra flags unless you have a very good reason for each one with full understanding of the side effects. The defaults are meant to work and be most optimal in most cases.

@danmed

My Assumption was that it was bad to do so

“bad” is ambiguous. Concurrent access is either supported and works or is not. Duplicacy is concurrent, and accomplishes that without reliance on a locking database – this is one of its major selling points. If you manage to corrupt backup via concurrent use (without -exclusive flag) – it would be a bug and would need to be fixed.

I highly recommend reading the IEEE published article that outlines the duplicacy operation – understanding of internals will bring peace of mind and confidence in its design.

Duplicacy paper accepted by IEEE Transactions on Cloud Computing

A paper introducing Duplicacy and Lock-Free Deduplication has been accepted by IEEE Transactions on Cloud Computing: Duplicacy: A New Generation of Cloud Backup Tool Based on Lock-Free Deduplication - IEEE Journals & Magazine If you want to read the paper but don’t have to access to the pdf file, here is a link to the final draft which should be very close to the published version other than a few minor, mostly editorial changes.