raw target: add option to not use the closest parent but the one that is the last to be rotatet away #508
Comments
|
Can't do easily, and does not make much sense in my opinion:
|
|
Well, the only reason I thought this might possibly make sense is saving disk space (which is however anyway not that important, given that we're talking about incremental dumps). The idea was basically, that one likely wants to keep the "scheduled" backups, just as they're scheduled... i.e. to have a wayback machine for different time periods. Anyway as I've already said before,... I wasn't even sure myself how useful that would actually be. |
|
Just another similar thing for your attention/consideration, before we can close this issue: Again when trying out the incremental rotation, I played a bit around with What I noticed, I guess, is that under some bad circumstances one might run out of backups (well at least all but the latest one), which again, may destroy any wayback functionality that people might want: I had basically the following: So what I think might happen is... consider the backups fail for a longer while, e.g. the target host is down or so. When it comes up again, the most recent backups on it may already be well beyond their retention period (even if In a way this is of course the desired behaviour... but it may also "break" the wayback functionality. Not sure whether there's really anything one could do about it. Even something like an option that causes at least Anyway... feel free to close this issue! :-) |
|
I think what you describe here is pretty much a duplicate of #308 |
|
Thanks for the pointer. :-) Should you ever feel to implement #508 (comment), just re-open. But as I've said... no strong desire from my side, thus closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey.
I noticed this while trying out the branch from #474 ... I'm not sure whether what I describe below could already be done via
incremental_prefs, if so I didn’t understand it.One thing I’ve noticed (when trying https://github.com/digint/btrbk/commits/delete-incremental-raw) is what I have right now:
with the following files:
i.e. only the oldest one is a full backup and the following sidecars:
AFAIU, the one from
20221120T004649would in principle be deleted, because I have5hand there’s also the one from20221120T000012(which is closer to the full hour at20221120T0000and thus the one to be kept), but isn’t because its the parent of20221120T010012and the other following incremental dumps.Right so far?
In principle the rotating is of course correct, but wouldn't it perhaps make sense here to not use the closest parent (
20221120T004649) when creating the incremental20221120T010012, but the closest one that is (with the current retention policy) the last to be rotated away?The idea here is that one typically has some cron/systemd timer, which would then create cycles of full/incremental backups... while in addition there might be manually created ones (like above
20221120T004649).And then one wants the normal cycle to be used, rather than such intermediate backups, which should go away after
target_preserve_min.OTOH, any
runs without such option (i.e. manual runs) would indeed use the closest parent.Not sure whether this makes sense. ^^
In any case... it’s not really important to me.
Cheers,
Chris.
The text was updated successfully, but these errors were encountered: