-
-
Notifications
You must be signed in to change notification settings - Fork 753
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make compaction optional? #809
Comments
Interesting comment there about revoking permissions on old files: This approach might be nice also (so we do not need additional cmdline options / commands) - but it would not work for the "revoke permissions on old files" usecase: |
Maybe make it (append only repo) an option in the repository config file instead? |
yes, as this relates to repo behaviour, a setting in the repo config might be best. |
New repository config item, repository.append_only, causes Borg to never delete or append to existing data files. Hints and indices are handled as before, old ones are deleted, because they can get quite large, but are automatically reconstructed: no need to keep them. When append_only is activated a file /path/to/repo/transactions/<NUMBER> will be created for every commit. Deleting all segments <NUMBER+1> and higher will rollback to that commit. Note that this only influences Borg behaviour. Since repository config can't be altered remotely (except for repository.key) this can't be disabled when accessed remotely over SSH with "borg serve" as the forced command. This is only a feature to support the use case, and does not replace appropriate file system permissions or monitoring. Resolves borgbackup#809 TODO: - tests - docs
New repository config item, repository.append_only, causes Borg to never delete or append to existing data files. Hints and indices are handled as before, old ones are deleted, because they can get quite large, but are automatically reconstructed: no need to keep them. When append_only is activated a file /path/to/repo/transactions/<NUMBER> will be created for every commit. Deleting all segments <NUMBER+1> and higher will rollback to that commit. Note that this only influences Borg behaviour. Since repository config can't be altered remotely (except for repository.key) this can't be disabled when accessed remotely over SSH with "borg serve" as the forced command. This is only a feature to support the use case, and does not replace appropriate file system permissions or monitoring. Resolves borgbackup#809 TODO: - tests - docs
This works, but where do we document it? Under the "Additional Notes" heading in docs/usage.rst? |
New repository config item, repository.append_only, causes Borg to never delete or append to existing data files. Hints and indices are handled as before, old ones are deleted, because they can get quite large, but are automatically reconstructed: no need to keep them. When append_only is activated a file /path/to/repo/transactions/<NUMBER> will be created for every commit. Deleting all segments <NUMBER+1> and higher will rollback to that commit. Note that this only influences Borg behaviour. Since repository config can't be altered remotely (except for repository.key) this can't be disabled when accessed remotely over SSH with "borg serve" as the forced command. This is only a feature to support the use case, and does not replace appropriate file system permissions or monitoring. Resolves borgbackup#809
How does this affect the ´delete´ command? Is the data freed if I delete old archives? |
Discussion: can this change resolve #36? |
It can't do that. It will mark it as deleted in a new transaction, but it won't delete the data. In append-only mode the data/segments of old transactions are final.
It can do that, for some setups. Consider a typical "central backup server" setup. The machines backup up to there, and if one of the machines get hacked, the attacker can't delete the backups. E.g. an attacker deleted all backups at 13:45, you look into the Repository.destroy won't work either (it raises an exception, since it's an RPC method). |
Well, what you say means "it can". Why do you say it can't? |
I edited my comment to clarify |
ah :) so you agree it solves #36? |
Yep. For some setups it's just not possible on a Borg-level (for example a central repo accessed over NFS or something like that). But with this change it becomes possible for It's pretty much meaningless without force_command in SSH, in that case the attacker can just use |
as 1.0 is in ubuntu 16.04 (and debian), shall we tag this as "security" (because #36) and fast-track this to 1.0.1 (which might still get in, 1.1 won't get in I'ld guess). |
It's all I'll add some docs about this, too. |
New repository config item, repository.append_only, causes Borg to never delete or append to existing data files. Hints and indices are handled as before, old ones are deleted, because they can get quite large, but are automatically reconstructed: no need to keep them. When append_only is activated a file /path/to/repo/transactions/<NUMBER> will be created for every commit. Deleting all segments <NUMBER+1> and higher will rollback to that commit. Note that this only influences Borg behaviour. Since repository config can't be altered remotely (except for repository.key) this can't be disabled when accessed remotely over SSH with "borg serve" as the forced command. This is only a feature to support the use case, and does not replace appropriate file system permissions or monitoring. Resolves borgbackup#809
fixed by merging #817 (currently in 1.0-maint, soon in master) |
some people want a more strict "append only, do not change old repo files" behaviour than we have right now (as borg always tries to compact when it commits).
we could make the compaction optional (like
create --no-compact
, maybe also forcheck
) and introduce a separateborg compact
command.borg would not modify existing files in the
repo/data
directory then, but just add new files.The text was updated successfully, but these errors were encountered: