Strange behavior of expiration
estan opened this issue · 11 comments
Hi,
I'm in the process of setting up tarsnap + tarsnapper on my FreeBSD server.
I currently have the following small tarsnapper.conf:
deltas: 1d 7d 30d
target: $name-$date
jobs:
backup:
sources:
- /etc
- /usr/local/etc
I tried to create a couple of backups by invoking tarsnapper -c /usr/local/etc/tarsnapper.conf make. But then I encountered this behavior:
root@www:/etc/periodic/daily # tarsnap --list-archives
backup-20141026-181732
backup-20141026-174741
root@www:/etc/periodic/daily # tarsnap -c /usr/local/etc/tarsnapper.conf make
Creating backup backup: backup-20141026-182234
3 backups are matching
1 of those can be deleted
Deleting backup-20141026-181732
root@www:/etc/periodic/daily # tarsnap --list-archives
backup-20141026-182234
backup-20141026-174741
Why did it remove the backup-20141026-181732 archive?
(These commands were all run today while I was testing).
Perhaps I'm misunderstanding how the expiration works. My understanding was that the tool will strive towards satisfying the given deltas with as few archives as possible. And since it will always keep the most recently made archive, it would make sense that it would delete one of the two archives.
But why did it expire backup-20141026-181732 and not backup-20141026-174741 (which is slightly older)?
Okay. Now something happened that definitely should not happen. Before I went to bed last night:
[estan@www ~]$ sudo tarsnap --list-archives
backup-20141026-214357
backup-20141027-020110
and then today, after a cron:ed tarsnapper run early this morning (with the config above):
[estan@www ~]$ sudo tarsnap --list-archives
backup-20141026-214357
backup-20141028-020110
Why did it remove my backup from yesterday? These are supposed to be my daily backups!
Would be glad to know if there's something I'm misunderstanding here, but this seems a bug to me. With deltas 1d 7d 30d it should never delete backups that were made the day before, right?
But why did it expire backup-20141026-181732 and not backup-20141026-174741 (which is slightly older)?
A comment in the code says:
Find the backup that matches the current position best. We have different options here: Take the closest older backup, take the closest newer backup, or just take the closest backup in general. We do the latter.
The backup deleted is closest to the desired timestamp, which is most_recent - 1d.
I don't know if there is "best" answer. I believe in your case I prefer that it acts the way it does, because if snapshots are further apart, more data is likely to be captured.
As to the second case, I stepped to the code to figure it out. It may be a bug, it definitely doesn't seem "nice", but it should not be a serious problem in the sense that it will recover once more backups exist.
It behaves this way because the deltas are actually processed backwards. To choose the backups to keep for delta "1d", it will first try to find a backup for most_recent - 7d (and then found_backup + 1d and so on).
The backup that most closely matches -7d is 20141026-214357. It then looks for a backup matching 20141027-214357, and the backup from the night of the 28th is much closer to this point than the backup from the night of the 27th.
I just added a mode to the simulate script that you might find useful, for example, after some days this is what it would look like:
python simulate.py 20141026-214357 20141027-020110 20141028-020110 20141029-020110 20141030-020110
Deleted backups:
2014-10-27 02:01:10
Remaining backups:
2014-10-26 21:43:57
2014-10-28 02:01:10
2014-10-29 02:01:10
2014-10-30 02:01:10
Thanks a lot for taking the time to explain this, and for looking through the code. I think I understand the behavior now. I still find it slightly disconcerting that it removes anything at all in the "ramp up" phase so to speak.
My expectation was that if I tell it I want daily backups for the past 7 days (using 1d 7d), then the backups should start trickling in, without anything being considered for removal until 7 days have passed.
But now that I know the mechanics I feel a little more at ease. I'll monitor what happens in the coming 30 days :)
Thanks also for pointing out the simulate.py script. Neat!
Hi again.
The issue is closed, but I just have a last question: After a few days now, I have the following:
[estan@www ~]$ sudo tarsnap --list-archives | sort
backup-20141026-214357
backup-20141029-020109
backup-20141030-020109
backup-20141031-020110
backup-20141101-020110
backup-20141102-020109
backup-20141103-020109
backup-20141104-020110
backup-20141105-020109
[estan@www ~]$
Shouldn't tarsnapper have started removing backups by now? (my deltas are still 1d 7d 30d)
Sorry, kind of false alarm :) One more day, and I have
backup-20141026-214357
backup-20141030-020109
backup-20141031-020110
backup-20141101-020110
backup-20141102-020109
backup-20141103-020109
backup-20141104-020110
backup-20141105-020109
backup-20141106-020110
So all happy now. It began removing (backup-20141029-020109 was removed). Not sure why it keeps 8 backups (30/10 - 6/11), but it's okay (the 26/10 one is an odd one that I made manually, not through a cron job, will probably remove that manually).
Or actually, I think I understand now why it's keeping backup-20141026-214357 and backup-20141030-020109 above. It's because that in lack of any better matches, these two are decided to represent my current_date - 1 month and current_date - 2 months backups, respectively? If so it all makes sense now finally :)
I think your reasoning sounds right.
Great. Thanks. And also, thanks a lot for tarsnapper. If I hadn't found it, I would probably have tried to make my own bash backup script and made a complete mess out of it :)