Repository navigation
Follow-up backups fail in "no-delete"-mode, if previous backup(s) aborted, under certain conditions, due to same pack-id being computed #10512
Description
I was trying to make myself familiar with the no-delete and append-only operation modes.
It seems that an aborted and later retried session might try to (re)write the same file on the backend, if the new computed pack-id is the same as the one from before (aborted session).
That apparently can indeed happen, if
- the source material ending up in respective pack didn't change
- the hashing algorithm used for generating pack-derived filenames does not involve any randomness
resulting in PermissionDenied and hence unsuccessful follow-up attempts in backing up that host.
Tested with mode + operation authenticated-blake3, but there might be others as well.
Maybe this is considered niche or unsupported, but I couldn't find it documented, so I guess at least that would be useful.
Activity
ThomasWaldmann commentedon Oct 11, 2026
Thanks for the report, will have a look into this.
Ideally, borg should not rewrite identical stuff that already is in the repo. But there can be circumstances making it happen, e.g. if the repository index does not have information about some chunks / some packs, making the client unaware of these chunks/packs.
Due to write order (first packs, then index) that can happen if a session is aborted.
The filenames of the packs are
store_hash(content), so the packs can be verified server-side.