Help with Prune on B2 using the Web GUI

Support
#1

I’m trying to get this running correctly for me but I’m struggling a bit. I have been using the Web GUI for over a year now. The backups were starting to build up and was growing to over 2TB on B2. I have roughly 350 revisions. I run a backup and check every night. Which has worked great. With my B2 costs going up I just wanted to limit the amount of backups I keep. So I set up prune to run once a week with the following parameters -keep 0:365 -keep 7:30 -keep 1:7 -a. Prune ran and completed just fine. The number of revisions has been pruned as expected. However it hasnt actually deleted any of the data from my B2 bucket. And also my checks now show missing chunks. From reading other threads I realise this is expected.

My question I guess is how do I get the prune to delete the fossil chunks and how do I go about fixing the check? Thanks in advance.

#2

It looks like prune was interrupted (check logs) and ghost snapshots remained in the storage still point to chunks some of which got already deleted.

You would neee to eliminate them (check -persist), delete failed snapshots manually, and then run prune -exhaustive to clean up orphans.

Duplicacy should have done it automatically, it has been long time requested but never implemented.

#3

Thanks for the quick response. you are right about a prune getting interrupted. my first prune got interrupted because of my appdata backup shutting down my duplicacy container.

How do I identify the failed snapshots in my B2?

#4

Run check with persist,

then review the log, and collect IDs of the snapshots that were reported corrupted. Then you can use any third party tool like CyberDuck or Transmit to access b2 backup and delete the corresponding revisions from under /snapshots/<snapshot id> prefix.

#5

Would you recommend having -exhaustive included for every run of prune? or just use it once to fix my current issue?

#6

Just once. There is no reason to run it every time – it’s incredibly slow, gets progressively slower as dataset grows, uses up a lot of API calls, and provides no benefits if there are no issues.

#7

Thanks for that. I am currently running the prune -exhaustive. It’s been running for the past 3 days and its been doing fine. I can see the b2 storage progressively getting smaller. Would it be faster to stop the prune and assign extra threads to this? Would this cause more problems?

#8

I would let it be. Not broken — don’t fix :slight_smile:

Starting over will result in a bit extra in api costs — enumerating all chunks again. And there is no hurry, it’s not blocking anything. You can continue doing backups as it’s pruning.

But generally yes, these storage classes are designed to be used multithreaded.

#9

Cheers. I’ve turned off all backups for the moment. I’ve local backups that will help it catch up anyway once its done.
I’ll add some threads to my regular prune once this is all done.

Thanks again.