Elaborate on append-only mode docs (1.1 backport) #4431
Conversation
|
thanks! |
| @@ -233,10 +236,19 @@ won't free disk space, they merely tag data as deleted in a new transaction. | |||
| Be aware that as soon as you write to the repo in non-append-only mode (e.g. prune, | |||
| delete or create archives from an admin machine), it will remove the deleted objects | |||
| permanently (including the ones that were already marked as deleted, but not removed, | |||
| in append-only mode). | |||
| in append-only mode). Automated edits to the repository (such as a cron job running | |||
| ``borg prune``) will render append-only mode moot if data is deleted. | |||
There was a problem hiding this comment.
Is this about running borg prune with or without append-only?
"if data is deleted" by that automated borg prune (without append-only) or "marked" as deleted (with append-only) before that automated borg prune (without append-only)?
I read this dozens of times, and I still struggle to understand this sentence and what it tries to suggest.
There was a problem hiding this comment.
No, this is about compact_segments, which borg < 1.2 implicitly calls at the end of repo-writing commands to get rid of most unused [or rather "not used any more"] parts of segment files IF the repo is not append-only.
In append-only mode, it just keeps everything it ever had, never frees any space, always appends changes to the end.
There was a problem hiding this comment.
And the sentence tries to suggest that you should make sure that your repo still shows all you want to keep and that all archives you want to keep actually have all content you want to keep.
If an attacker used borg delete while the repo is append-only, there is no immediate damage - you could still rollback the repo to any past state. But if you switch off a-o and write, compact_segments will actually get rid of the deleted data and no rollback is possible any more.
| operation on an append-only repository to catch accidental or malicious corruption:: | ||
|
|
||
| # run without append-only mode | ||
| borg check --verify-data repo && borg compact repo |
There was a problem hiding this comment.
"run before a writing/pruning operation on an append-only", once again, "writing/pruning" in which mode, append-only or not?
Also, why should borg check --verify-data be run without append-only? Isn't this read-only operation?
What compact has to do with this discussion?
There was a problem hiding this comment.
@ThomasWaldmann, just in case you missed this question about borg check --verify-data, it's still relevant. I also now found #4660 fixed by #4714, and I'm really under impression now that
# run without append-only modeshould have been removed as well, since borg check --verify-data should be read-only, isn't it? That is wasn't the above comment applicable only because of borg compact, which was now removed from documentation?
There was a problem hiding this comment.
Sorry to bother you so much jumping around different discussions about check, prune, compact. I'm just finally in the middle of organizing that subject area of a large backup infrastructure.
There was a problem hiding this comment.
if borg check --verify-data is successful (all looks authentic / uncorrupted), it will return rc == 0 and that will cause the righthand part to execute (borg compact).
if it looks like somebody has tampered with the repo contents (like corrupted chunks), it won't execute the borg compact.
guess the idea here was to only run compact if everything looks good.
otherwise you may want to rollback the repo to an older state and for that to work, you must not run borg compact.
There was a problem hiding this comment.
I guess my point was that, for Borg 1.2, it should be:
borg check --verify-data repo && {
# disable append-only mode and then run
borg compact repo
}While, for Borg 1.1, it should be:
borg check --verify-data reporegardless of whether append-only mode is on or off.
See #4384. This was really easy; unexpectedly, the patch applied cleanly.