Skip to content
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

Closed
ThomasWaldmann opened this issue Mar 28, 2016 · 14 comments
Closed

make compaction optional? #809

ThomasWaldmann opened this issue Mar 28, 2016 · 14 comments

Comments

@ThomasWaldmann
Copy link
Member

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 for check) and introduce a separate borg compact command.

borg would not modify existing files in the repo/data directory then, but just add new files.

@ThomasWaldmann
Copy link
Member Author

Interesting comment there about revoking permissions on old files:

oysols@2eeaac1

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:

master...oysols:delay_compact_segments

@enkore
Copy link
Contributor

enkore commented Mar 29, 2016

Maybe make it (append only repo) an option in the repository config file instead?

@ThomasWaldmann
Copy link
Member Author

yes, as this relates to repo behaviour, a setting in the repo config might be best.

@ThomasWaldmann ThomasWaldmann added this to the 1.1 - near future goals milestone Mar 30, 2016
enkore added a commit to enkore/borg that referenced this issue Mar 31, 2016
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
enkore added a commit to enkore/borg that referenced this issue Mar 31, 2016
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
@enkore
Copy link
Contributor

enkore commented Mar 31, 2016

This works, but where do we document it? Under the "Additional Notes" heading in docs/usage.rst?

enkore added a commit to enkore/borg that referenced this issue Mar 31, 2016
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
@Ape
Copy link
Contributor

Ape commented Mar 31, 2016

How does this affect the ´delete´ command? Is the data freed if I delete old archives?

@ThomasWaldmann
Copy link
Member Author

Discussion: can this change resolve #36?

@enkore
Copy link
Contributor

enkore commented Mar 31, 2016

Is the data freed if I delete old archives?

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.

Discussion: can this change resolve #36?

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 transactions folder and find the file N from 13:45. You go into the data folder and delete all segment files with a number >=N. Voila, everything is back to before 13:45. <--- this could be automated, but I don't think it should be.

Repository.destroy won't work either (it raises an exception, since it's an RPC method).

@ThomasWaldmann
Copy link
Member Author

Well, what you say means "it can". Why do you say it can't?

@enkore
Copy link
Contributor

enkore commented Mar 31, 2016

I edited my comment to clarify

@ThomasWaldmann
Copy link
Member Author

ah :) so you agree it solves #36?

@enkore
Copy link
Contributor

enkore commented Mar 31, 2016

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 borg serve setups.

It's pretty much meaningless without force_command in SSH, in that case the attacker can just use rm instead. There are probably ways to enhance this with ACLs or permissions, but that's outside of Borgs scope.

@ThomasWaldmann
Copy link
Member Author

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).

@enkore
Copy link
Contributor

enkore commented Mar 31, 2016

It's all if-wrapped with self.append_only, and the default is False, I'd say this is a pretty safe changeset. I can rebase on 1.0-maint and open a PR.

I'll add some docs about this, too.

@ThomasWaldmann ThomasWaldmann modified the milestones: 1.0.1 - fixes, 1.1 - near future goals Mar 31, 2016
enkore added a commit to enkore/borg that referenced this issue Mar 31, 2016
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
@ThomasWaldmann
Copy link
Member Author

fixed by merging #817 (currently in 1.0-maint, soon in master)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants