For 08b4ef33: Because for the group of snapshots that are for that set of paths (seen in the snapshot 08b4ef33) and the host BackupComputer02, the most recent snapshot is 1fb7d097 from 2023-12-08 09:28:48. When you ask restic to keep one daily snapshot for seven days back, it looks up the most recent snapshot (for that group of snapshots) and keeps one snapshot per day for seven days back relative to that date, 2023-12-08.
For 85e91a83: Same as above, the seven days is related to the snapshot with ID 1b9753af.
For 8aba2d2f: The reason that 8aba2d2f was kept when there was already 85e91a83 for that date is that there weren’t enough snapshots to keep for seven days back relative to the most recent snapshot 1b9753af in that group, so restic as a precaution saves the oldest one as well.
All in all, restic tries to err on the side of caution. Restic looks at the list of snapshots and relates its time calculations based on the most recent one (per group). It’s not about when you run the forget command, it’s about the timeline of snapshots.
Now I understand why paths were so important to you.
Okay, this sheds a whole new light on the whole backup policy. This is very smart and focused on data safety. But there should be option for retention related on time. Grouping by time.
Unfortunately I have one repo with hundreds of computers and hundreds of different paths connected to it. A lot of data is duplicated, this is the most reasonable solution (have all machines in one repo).
Making retention in this repository seems very hard or even impossible ;/ I don’t care what will be lost because this is only for current data something like trashbin - the timeframe is 30 days. Period. User need to have in mind this 30 days window. Older data needs to be deleted.
