Out of curiosity, I stopped the docker container and re-ran the prune command from the CLI, with remarkably different results… results which were in line with my expectations.
duplicacy -log prune -storage b2_test -keep 30:360 --dry-run
Here’s a snippet of the log:
2024-07-05 16:11:05.511 INFO STORAGE_SET Storage set to b2://ch
2024-07-05 16:11:05.830 INFO BACKBLAZE_URL download URL is: https://f002.backblazeb2.com
2024-07-05 16:11:06.845 INFO RETENTION_POLICY Keep 1 snapshot every 30 day(s) if older than 360 day(s)
2024-07-05 16:12:00.886 INFO SNAPSHOT_DELETE Deleting snapshot xxx_b2 at revision 2
2024-07-05 16:12:00.905 INFO SNAPSHOT_DELETE Deleting snapshot xxx_b2 at revision 14
2024-07-05 16:12:00.905 INFO SNAPSHOT_DELETE Deleting snapshot xxx_b2 at revision 15
2024-07-05 16:12:00.905 INFO SNAPSHOT_DELETE Deleting snapshot xxx_b2 at revision 17
2024-07-05 16:12:00.924 INFO SNAPSHOT_DELETE Deleting snapshot xxx_b2 at revision 20
2024-07-05 16:12:00.945 INFO SNAPSHOT_DELETE Deleting snapshot xxx_b2 at revision 23
2024-07-05 16:12:00.957 INFO SNAPSHOT_DELETE Deleting snapshot xxx_b2 at revision 25
2024-07-05 16:12:00.980 INFO SNAPSHOT_DELETE Deleting snapshot xxx_b2 at revision 27
2024-07-05 16:12:00.980 INFO SNAPSHOT_DELETE Deleting snapshot xxx_b2 at revision 29
<snip>
In addition, over 500 unreferenced chunks were identified.
So … there seems to be some “bug” in the docker image that affects the prune operation.
As a result I re-ran prune on all the storage locations via CLI, and all consistently were affected.
Anyone?