-
-
Notifications
You must be signed in to change notification settings - Fork 2
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
Does backup pruning happens properly and automatically? #57
Comments
It seems it does not:
|
@kelson42 actually, today I got this :
|
@florentk Seems still wrong. Why the backup of the 2020-11-12 is there? |
@kelson42 our default configuration has 'keep whithin' at 48h, that's why it keeps two more. We can see that when I simulate a prune with and without
|
We need to have per default a backup for the:
|
Apparently fixed. |
@florentk I have to reopen this ticket as this is really not clear how this could work. See the documentation: https://docs.borgbase.com/faq/#why-can-i-still-prune-or-delete-archives-with-active-append-only-mode |
@kelson42 I understand that in "Append only" mode, when you make a prune, it doesn't really do it until you do it with a full mode. This is strange that there is no error and that it no longer appears in the list. But it will be necessary to do it manually from time to time with another key to save space. Then it would be to see how to properly integrate then into our tool |
@florentk concretly, what should be exactly run to effectively free the sapce of the pruned backups? |
@kelson42 |
@florentk This is to prune only one reposity I guess? |
@kelson42 yes |
@florentk We need a strategy to do that more or less automatically for all repos. |
@florentk @rgaudin It a bit sad to discover this problem so lately, in particular after me asking specifically to check the pruning. Anyway, now we need to fix it. It seems to me that there is no way for the backuper to effectively prune the old revisions with the append-only key. Changing the SSH keys to allow write operation, even temporarily, sounds cumbersome and dangerous. The best solution I can imagine is to have a third |
Yes the behavior is very deceiving and that's disappointing. I want to dig a bit further to understand how and why borgmatic could remove pruned-but-not-actually-removed archives from the list that it reports with that append-only key. Next, I agree with you about the prune-command strategy using another set of key which would not be shared with the backuper account. |
Does the pruning of older backups happens properly according the given configuration?
The text was updated successfully, but these errors were encountered: