Hi Veeam,
after we have changed our backup from "forever forward incremental" to "incremental with SF" the restorepoint count is grow from 30 (SLA) to 46 and will be grow to 60 points (until new full) > this is dirty
Solution from support:
1. Wait until new full > not enough freespace!
2. Delete Files manuelly from primary Job (BC Jobs works fine) > very dirty with a SOBR
And we cannot delete selected Restore Points via PS without corrupt sql tables (is tested on our LAB).
These things should work better.
BR
Alex
-
- Influencer
- Posts: 19
- Liked: 1 time
- Joined: Apr 04, 2018 9:49 am
- Full Name: Alexander Weit
- Contact:
-
- Veeam Software
- Posts: 2010
- Liked: 670 times
- Joined: Sep 25, 2019 10:32 am
- Full Name: Oleg Feoktistov
- Contact:
Re: Restore point count has grown after changing backup algorithm
Hi Alexander,
I split your post from the original one as it wasn't related to Powershell much.
Thanks,
Oleg
I split your post from the original one as it wasn't related to Powershell much.
Thanks,
Oleg
-
- Product Manager
- Posts: 9846
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Restore point count has grown after changing backup algorithm
Do you have configured monthly Synthetic Fulls? Then this is expected behavior with forward synthetic Full.after we have changed our backup from "forever forward incremental" to "incremental with SF" the restorepoint count is grow from 30 (SLA) to 46 and will be grow to 60 points (until new full) > this is dirty
A old chain cannot be deleted until the new backup chain has again your 30 configured restore Points.
You will always have 30-60 restore points on your backup repo with monthly synthetic Fulls and a retention Policy of 30 restore points.
Product Management Analyst @ Veeam Software
-
- Veteran
- Posts: 643
- Liked: 312 times
- Joined: Aug 04, 2019 2:57 pm
- Full Name: Harvey
- Contact:
Re: Restore point count has grown after changing backup algorithm
Alexander,
Use this tool to predict your retention: http://rps.dewin.me
With a periodic full, you will consistently have more points than retention shows. Count back from your most recent point until you reach retention. If you reach it and it's an increment, keep going until you find a Full backup and you'll know the "max" number of points on disk you'll have.
Synthetic Fulls are fine, but maybe let's check why you're doing this first -- maybe there's a way to address this without the fulls.
Else, is your repository filesystem using XFS/ReFS? My guess is the extra full is what eats up all your space, and with XFS/ReFS you get "free" fulls that only use the same space as an increment. If you aren't using this now, you should be looking for a natural point when you can rearchitect towards it.
Use this tool to predict your retention: http://rps.dewin.me
With a periodic full, you will consistently have more points than retention shows. Count back from your most recent point until you reach retention. If you reach it and it's an increment, keep going until you find a Full backup and you'll know the "max" number of points on disk you'll have.
Synthetic Fulls are fine, but maybe let's check why you're doing this first -- maybe there's a way to address this without the fulls.
Else, is your repository filesystem using XFS/ReFS? My guess is the extra full is what eats up all your space, and with XFS/ReFS you get "free" fulls that only use the same space as an increment. If you aren't using this now, you should be looking for a natural point when you can rearchitect towards it.
Who is online
Users browsing this forum: EskBackupGuy23, Google [Bot] and 302 guests