Prune command details

How-to
#15

Got it. I have a folder that I store an entire photo session, and after 90 days the selected files are already in another location, this entire photo session folder just serves as a backup if the client want something I haven’t delivered. So 90 days is a good amount of time for me.

#16

If I understand right every time I delete these folders I need to set a prune for IE 7 days max, then after 7 days this folders will be gone after 2 prunes and a backup?

#17

I think the 7 day thing is if you don’t run any backups for that long. Otherwise, the first prune will delete the snapshots and ‘collect’ all the relevant chunks - ready for their deletion in the second run. But according to your prune command, those files - if you delete them - won’t be gone for at least 90 days.

#18

What is the behaviour of the prune command when there are more than one backup on a given day? (e.g. hourly backup)

#19

Pruning works at the resolution of a day, so it doesn’t make sense to run it more than once a day. Otherwise, it works fine with hourly backups.

Usually, you’d set up the retention period to keep hourly backups for at least a day - perhaps a week or two, or more - so recent backups don’t get touched until they’ve ages awhile.

2 Likes
#20

If I understand the question correctly… if you run the prune command to only keep 1 backup per day and you have hourly backups, then it’ll keep the oldest revision from the day (based on the thread linked below).

1 Like
#21

Yep, that’s what I was after. Thank you!

#22

A post was split to a new topic: Prune: exclude tags

#23

Does -exhaustive imply -all?

#24

No, -exhaustive only means to find ‘orphan’ chunks that are not referenced by any snapshots. It is a plausible use case that you can delete snapshots with a certain snapshot id and at the same time delete these ‘orphan’ chunks.

#25

I think I understand: -all deletes snapshots (revisions) from all snapshot ids according to the specified retention policies; in doing so it deletes (or fossilizes) any chunks referenced by those revisions but not referenced anywhere else. And -exhaustive deletes chunks that aren’t referenced by any snapshot. Correct?

1 Like
#26

This is correct…

1 Like
#27

Reading this:

The -exclusive option will assume that no other clients are accessing the storage, effectively disabling the two-step fossil collection algorithm.

Actually i am backing up some NAS dirs to a storage. No other client has access to that storage, it’s a bucket i created on B2 only for backup purpose.

So it’s fine to always use

-exclusive ?

#28

To only keep a 7-day history, would it be -keep 0:7 ?

#29

Yes.

However it’s questionable why would you want such a short history? It may not accomplish what you may hope to accomplish (I.e. purging data for various compliance reasons).

#30

Is the following correct?

If the keep option is not specified, no snapshots will be deleted and no new fossils created.

For example (assuming exclusive access to a storage) this command will only delete existing fossils, both referenced and unreferenced:

duplicacy prune -all -exhaustive -exclusive

#31

Feature Request: -persist flag that deletes snapshots no matter if there are missing chunks.
Feature Request: -v verbose flag that prints the chunks that are (currently) deleted

3 Likes
#32

I get the following error when trying to prune:

2024-10-04 16:56:28.216 ERROR DOWNLOAD_DECRYPT Failed to decrypt the file snapshots/install-ts639/34: No enough encrypted data (0 bytes) provided
Failed to decrypt the file snapshots/backup/34: No enough encrypted data (0 bytes) provided
#33

Okay I think that was a corrupt backup so I deleted it.

Now when I run prune I get this error:

2024-10-04 17:13:51.990 WARN CHUNK_FOSSILIZE Chunk bae0d76f68c4ca6262d68ea006cad8ec62972da3850e30128bb416a2a42d18c3 is already a fossil
2024-10-04 17:13:54.868 WARN CHUNK_FOSSILIZE Chunk 53e33af467e1b772ba40c3e8e0ff5663f98267974639f871390554e410062339 is already a fossil
2024-10-04 17:13:57.087 ERROR CHUNK_DELETE Failed to fossilize the chunk b0e62a477173fdb2dc7a697dfd3e3585cb02539cff76e273278fe9cd540f1b3b: sftp: "Failure" (SSH_FX_FAILURE)
Failed to fossilize the chunk b0e62a477173fdb2dc7a697dfd3e3585cb02539cff76e273278fe9cd540f1b3b: sftp: "Failure" (SSH_FX_FAILURE)

I think this is because it’s trying to write and there’s 0.0% space.

Is there any way to manually create space to prevent this error?

#34

So while other prune commands need to specify a backup or a snapshot, if I just want to get rid of unreferenced chunks taking up space, I can safely run prune -exhaustive without any keep flags?