Calculating Retention Policy

Question

Hi All, 
 I am using the default retention policy but not the default hourly snapshot interval. I am wondering if I should make some adjustments to maximize my repository. It has currently filled to about half and holding steady. 
 I have been staring at the if/and/or boolean logic statements in regards to holding snapshots for hours, days, weeks, months and the pretty colored bar graph at the bottom but honestly still can't really make any intelligent decisions on what to change. Is there any easy rule of thumb or calculator to help with this? 
 Thanks

Emte · Accepted Answer

First, what is your backup frequency? If its not hours, I would think about changing that for critical/ busy servers (if not all of them) Having a backup product that only backs up a busy SQL server or File server once a day is a waste. 
 
Retention is actually pretty good, its just a bit hard to get your head around it. Below may help but it may also make you more confused. 
 
Another thing that really helps, simple look at your retention and then go look at the Restore Points for a server, notice what dates you have available and match it up. 
 
Lets assume: 
 
1) You perform backups every 2 hours. 
 
2) Lets say today is Feb 23rd and the client has been active for 2 years exactly 
 
2) The current retention is 
 
Keep all recovery points for 1 Days 
 
 ...and then keep one recovery point per hour for 1 Days 
 
 ...and then keep one recovery point per day for 2 Days 
 
 ...and then keep one recovery point per week for 3 Weeks

You will create 12 Recovery points each day. (backups every 2 hours) 
 
1) Feb 23rd (12 recovery points in the Repo) 
 
Keep all recovery points for 1 Days will keep ALL 12 Recovery Points created today 
 
2) Feb 22 and 21 (2 recovery points in the Repo) 
 
 ...and then keep one recovery point per day for 2 Days 
 
This will DELETE 11 recovery points for Feb 22 and only keep 1 
This DELETED 11 recovery points YESTERDAY for Feb 21 and will keep 1 
 
3) Feb 20 - 14 (3 recovery points in the Repo) 
 
 ...and then keep one recovery point per week for 3 Weeks 
 
This will have a single recovery point for each week, going back 3 weeks 
 
So in the example above, a single client would have 12+2+3 = 17 recovery points in the repository between Feb 23rd and Feb 14th 
 
There are probably some issues with the dates, info above, so if anyone has any feedback, feel free to give it. For example one thing that retention does is tries to keep the most recent backup for retention and depending on when retention is enforced, so it can screw up the numbers a bit 
 
There are several write-ups on retention that may help, for example (there are more if you are interested) 
 
 support.quest.com/.../118355 
 
 documents.software.dell.com/.../configuring-core-default-retention-policy-settings

Tudor.Popescu · Answer

Hi laytonj: scachman makes some valuable points (had to deal these real life issues quite a few times when working with various customers). I would like to add to the conversation a few points of my own: 1. The most available recovery points are located during the first few backup days (All recovery points + 1 recovery point per hour). The number of recovery points is decreasing dramatically when you get to 1 per day/week/month. As such, you may get to save space if you increase the interval between snapshots recovery points and reduce the time most recovery points are kept. The best approach is to discuss with stakeholders the relative importance of each backed up machine, divide the protected machines in groups that would be protected at the same intervals and apply similar schedules to each group. Although labor intensive this approach is the way to go as it raises awareness about what is available to users so they do not feel blindsided in their recovery expectations. 2. If repository size permits, taking base images of critical machines (i.e. on Accounting data after the month is closed) will give you an extra safety cushion. 3. If you have multiple cores, it makes sense to check if you can afford to buy a DR appliance and use it as secondary storage for all cores. It makes sense to keep only the recovery points that may be needed for immediate restores (in most cases about a week worth, i.e. to address files deleted by mistake or ransomware infection) and move the recovery points for longer storage on the DR Appliance. As mentioned all cores connect to the same DR appliance. BTW, DR appliances are able to replicate to other DRs without the help of RapidRecovery Cores so, if you get to have 2 DR appliances, you may have a replication alternative. Hope that this helps.

laytonj · Answer

Good advice. Thanks for taking the time both of you.