Prune not working?

I’ve got a backup going to a B2 bucket that i’d like to keep only 30 days of backups for. So I’ve created a prune schedule on it with the flag -keep 0:30

The 30 days have passed however and the email alerts I’m getting from Duplicacy are saying:

INFO RETENTION_POLICY Keep no snapshots older than 30 days
INFO SNAPSHOT_NONE No snapshot to delete

So the policy is being applied but nothing is being done? Am I misunderstanding how Prune is meant to work?

It’s running on a separate schedule atm, is it meant to be added to the backup schedule itself somehow?

How often do you run that prune schedule? How often do you run backup? Does your prune apply on the same storage that you run backup on?

The Prune runs daily at 1 PM, the backup runs at midnight and usually completes in 1-2 hours. I have a separate bucket for each repository.

Have a look at prune log. If prune was incorrectly not running you would have more than 31 revisions in the backup. Is this the case?

You can also confirm how many revision files are under snapshots folder on the storage.

Btw, if data on the machines somewhat overlaps you can save storage space baking up all machine to the same bucket/prefix (with separate snapshot id of course)

There are more than 31 revisions yeah, where would the prune log be? Can’t see it under /var/log/

Indeed. Few oldest ones seem to should have been pruned.

You can reach logs from the dashboard history plot. Click on the last prune bar in the history, it will open log in the new browser tab.

Hmm just says:

Running prune command from /root/.duplicacy-web/repositories/localhost/all
Options: [-log prune -storage Test -keep 0:30]
2023-10-18 14:00:01.253 INFO STORAGE_SET Storage set to b2://
2023-10-18 14:00:01.870 INFO BACKBLAZE_URL download URL is:
2023-10-18 14:00:02.467 INFO RETENTION_POLICY Keep no snapshots older than 30 days
2023-10-18 14:00:03.110 INFO SNAPSHOT_NONE No snapshot to delete

I’m running this on my TrueNAS in a jail, and it’s backing up different datasets to different buckets. This is just the Test dataset, the logs for all say the same thing.

1 Like

Add the -d flag to the prune schedule’s global arguments (click on arguments in the schedule). This will enable verbose logs. Run the schedule manually, and see if there is anything useful in the verbose log about why were early revisions skipped from being pruned.

I added it so it reads -keep 0:30 -d

Doesn’t seem to log anything extra though

It shall be in front, before the command. It’s a global flag, not prune commands’ flag. It shall result in much more stuff logged. If you add it after — it’s a “dry run” prune’s flag.

Is it possible to do this in the GUI? I’ve added it before the -keep 0:30 so it’s -d -keep 0:30 but no luck producing more logs.

Yes. There are two sections for configuring arguments. I don’t remember whether when you click the options you are presented with both fields or whether you need to click on - in the global option section.

This is still after the command. There must be a separate field.

Post a screenshot of the prune entry in the schedule, I’ll try to point out where to click. I don’t remember how it looks…

Actually, shouldn’t I be using the -a flag based on this Prune command details

1 Like

Dangit! I thought you were specifying the -id but that was -storage. Yes, you want either -a or -id <id>. Unless it’s the default one

Good catch. Prune without either of those flags is still meaningful, it will complete prune started in concurrent scenario. But now it’s of course quite misleading.

I found the global flag bit, just going to run it now with -d in global, and -a in the job’s params

1 Like

That’s done it, thanks for the help!

I wouldn’t have thought of looking at the prune commands flags if you didn’t mention the -d global flag :slight_smile:

So my prune reads -d | -keep 0:30 -a , which seems to work as intended

1 Like

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