conserve icon indicating copy to clipboard operation
conserve copied to clipboard

incomplete backups should not block delete or gc

Open sourcefrog opened this issue 3 years ago • 0 comments

Conserve 0.6.15 currently declines to delete or gc any content if the last band in the archive is incomplete:

https://github.com/sourcefrog/conserve/blob/5320ad926882a20bae54e1d61b0f7b0d76d25062/src/gc_lock.rs#L50-L62

https://github.com/sourcefrog/conserve/blob/main/doc/deletion.md

This is annoying in a couple of scenarios:

  1. If you discover the backup is including things that should be excluded, and you interrupt it, then you can't immediately remove the incomplete backup.
  2. Suppose the last backup is complete and the second-last is incomplete. If you delete the last backup, then you cannot then delete the incomplete backup.

Note that the policy does not just prevent deleting the last band; it prevents deleting anything if the last band is incomplete.

Basically, this is being used as a conservative detection of whether a backup might currently be underway.

The reason for this policy is that we want to make sure we're not writing a new backup concurrently with deleting data, which might lead to the new backup referencing blocks that are later deleted.

However this could possibly be handled another way, perhaps one of:

  1. Better indication whether a backup really is currently running. Possibly, the running backup should take a lock on the archive, not just gc.
  2. Deleting content in a way that is safe with a concurrent backup. (I'm not sure what that would be though.)

sourcefrog avatar Mar 20 '22 16:03 sourcefrog