I am performing testing on this app, I’ve configured hourly, weekly, monthly and yearly retention periods.
Based on my picture above, I would logically assume that the OLDEST backup, (the bottom one) should be the one with the badge / label of yearly / monthly / weekly etc, until such time as a newer backup which fits in to ‘steal’ the label.
Why would the oldest, not get the yearly flag? I’m probably doing something wrong, to be clear.
I don’t think you are doing anything wrong. Based on an earlier comment by Jarek, the logic is that the tags carry forward UNTIL it is stolen. So for latest-N, a new backup always steals the ‘first spot’, and then all the others get pushed back 1 place. Similarly, the latest backup of the day gets to claim the daily-N, until the next day when it gets pushed back. So on and so forth for the weekly, monthly, and annual tags.
As for the intuition, it sort of depends on how you think about it. For instance, I think of it as being ‘earned’ and not ‘inherited’. So if you accumulated a week’s worth of backup, at the END of the week, you get to keep the tag as a mark of the work. Similarly, at the end of the month, I consider a backup for that month to be complete, so therefore the last backup of the month should keep the tag.
Perhaps it would help if you replaced the numbers with something more familiar: for instance if the tag was ‘Monthly: January’ instead of ‘Monthly-1’, do you expect the backup to be at the start of the month or the end of the month? Me personally, I would see it as being the end of the month, it must contain the backup of the ENTIRE month. Therefore, if I made multiple backups in the same month, the very last backup will point to the backup of the entire month, and thus, that backup earns the ‘monthly’ tag. Likewise, if you were to think of the ‘Annual-1’ tag as being ‘Annual 2020 Backup’, it follows that it should contain the backup for the ENTIRE year 2020, therefore the last such backup of the year keeps the tag. If you are following this logic, then it makes sense that the tags carry forward UNTIL a new one can be earned.
Old thread I know - but I do had this confusion when I started looking at kopia. Actually, confusion isn’t exactly the word - but more, conflicting assumptions.
This is more a comment for any new readers/users coming in…
My developer mind understands that we’re carrying the tag forward, but since I’m storing 24 month snapshots, even tho that original oldest snapshot gets the anual and monthly tag pulled forward, I still have a monthly-4 of that earlier snapshot, if anything drastic happened and I needed to restore - within that first year, I’m still covered by those other tags.
Still, it irked me that depending on when I started using kopia (for me, early november so the years almost over, but if I’d started in January - then that’s 11 months potentially I won’t have overage for ( and since I’m just currently backing up my git repos, which are already mirrored elsewhere, and have full history anyway ) I wasn’t toooo terrible concerned - altho I’ve been bitten in the past.
I raised the topic and recently, snapshot “pining” was introduced, so I’ve added a pin on my earliest snapshot called “keepme” ( you can use any name you like ) and whilst any snapshot is pinned, it’s not pruned.
I imagine never having to have a need to use this - but it’s also nice to pin a backup, before doing something that could potentially break/delete a bunch of files and revert - altho ideally you’d do that with say ZFS/AppleFS snapshots etc. - it’s always a comfort to know you have that pinned snapshot offline.
