• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 27 subscribers
  • Views 9976 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Calculating Retention Policy

laytonj
over 7 years ago

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

  • 0 over 7 years ago
    There is no rule of thumb for retention, everyone is different.

    What I would recommend

    1) Don't think of it as retention, think of them as restores. What would you be comfortable saying you can/ cant restore. If a user comes to you and says I want a restore from X date, X months ago, are you fine saying you don't have it (since retention removed it) but you can restore from 30 days prior to the date they want.

    2) Get your executive's to approve a retention plan, don't set one up on a guess. If they demand you keep more recovery points than you can hold, they need to buy more storage. If things go wrong and a user complains you cant restore what they need, the responsibility of what is retained falls back to executives, not you.
  • 0 over 7 years ago
    It's entirely up to me and we have other backups in place so that's not really the issue. I guess my question is how to I maximize my repository to keep as much as possible intelligently as opposed to just changing things. The whole days/hours/days/weeks graph thing is just confusing.

    For example I know I'm at about half right of my repository now. The first selection in the retention is hours. I don't do hours. So go straight to keep all for X days or down to keep one per day for X days? I'd hate to lose what I built up to now.

    Feature request: A retention policy that figures out on it's own how to keep the most points using the backup schedule I choose.
  • +1 over 7 years ago
    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
  • 0 over 7 years ago

    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.

  • 0 over 7 years ago
    Good advice. Thanks for taking the time both of you.