It is possible we might want to reconsider the backup retention policy here a bit.
It’s smarter than it looks.
Let me guess, it is doing some sort of test to see how much free space there is and thus how long a rolling backup it can keep based on the level of change or something to that effect.
It’s how many days until the increments are as big as the last full backup, or something like that, which is when the next full backup occurs, plus the number of days the backups are kept around for at a minimum.
That actually makes a good amount of sense and is not what I would have guessed. That being said, I am still unsure I would want to roll incremental for 2500 days prior to a new full backup. Might be nice to have an option to limit it to a certain amount of time prior to forcing a new backup.
The retention policy works very well for me.
Judging by your screenshot you just set up your mailinabox server.
Give it some time as it takes a bit for the calculation to correct itself. As you use the box more, and maybe add more users to it, the time to the next full backup will decrease.
My box is currently backing up 8GB of data, had its last full backup 12 days ago and expects another full backup in 50 days. I think that is a reasonable timeframe.
Not a new one, but my backup set got wacky after the last upgrade, so I moved the backup folder and reran setup to let it make a clean one. In the end, it really does not concern me that much. I have a cron job in place that has Amazon run snapshots on the server. It keeps hourly ones for 48 hours, and dailys going back 2 weeks.
Basically it does a fsfreeze, runs the snapshot which takes seconds, and then unfreezes the filesystem. Seems to work really well and lets me roll back easily in an emergency.