DPM Online Retention Policy RRS feed

  • Question

  • We have an already setup DPM backup solution with long-term backup to Azure. It is all straight forward, but the retention policy brought up some confusion. Personally it looks likes a lot of redundancy as it is setup now. I tried googling what the best practices are or what the retention exactly does, but could not find the right answer. Hopefully someone here can clear this up.

    Currently it is setup like exactly like this:
    Looks like the default settings were used.

    Is it not more logical to have 7 days, 4 weeks, 11 months and 10 years retention? It looks extremely redundant to me as it is setup right now. But I could be wrong.
    Thanks in advance!

    Wednesday, October 18, 2017 2:31 PM

All replies

  • Hey there (I realise you posted this a while back, but here goes).

    Basically, both approaches are logical - it just depends how important it is to get backups from a specific but distant window.

    The original config may look like its just a lot of redundancy, but actually what it's providing are far more points in time to choose to potentially recover from.

    Yes you might both retain the 10 years required, and in normal usage you wouldn't notice any difference. But ultimately you've only got a single YEARLY point in time to recover from for each of years 2-5, whereas Their version, can additionally recover from any MONTH within years 2-5. And so on and so on, this concept trickles down with each 'overlapped' setting. This may or may not be critical one day. The data you need may have only existed for 6 particular months but 4 years ago, or for 2 particular weeks 4 months ago, or for 3 particular days 9 weeks ago, etc, and it's that specific window you'll need to nail to successfully recover that specific data.

    So that's what they're after with those settings. Are they better or more logical? Depends entirely what your need is for hitting those windows with restores, and also what your budget is to an extent (although retention costs are always hard to work out with Azure because they're differential backups).

    Personally, I decided to go for 4 weeks and 24 months, and that's it ... because it's all we need (we keep 2 years of backups, but they contain 10 years of data ... at least that's our policy). You just need to be aware of what you lose by having a limited (or no) retention overlap.



    • Proposed as answer by benweston Thursday, May 31, 2018 1:13 PM
    • Edited by benweston Thursday, May 31, 2018 1:13 PM
    Thursday, May 31, 2018 1:12 PM
  • Exactly 1 year ago I posted this. Last month I finally changes the retention. Now I see that my azure storage has been cleaned up. The storage got cut by 2/3. This is good, as it saves space and money, but it is not what I expected. I read articles stating changing the retention does not impact backups already in azure.

    I tried googling for an explanation for this behavior but all I find is the same as before, people asking why their azure storage is not being cleaned up. With answers that this is by design.

    Anyone have any articles or documentation to this behavior? (Why it is actually cleaned up).

    Thanks in advance.

    Thursday, October 18, 2018 10:08 AM
  • Changing a retention policy changes the retention of that Protection Group, not just the points from then on. This is true whether it's disk, Azure, or tape.

    I would argue that whilst this is completely logical - it's a policy, not a ruleset - in my experience often not what the user wants or necessarily expects, as in your case.

    I believe one way to work around this (in future) would be to remove your protection group to temporarily inactive, and recreate your Protection Group (with a new name), and the same data sources. This should associate all the existing retention with the old Protection Group, and the new policy will only apply to the new Protection Group.

    Btw I am far from an expert in this, but the above is correct to my knowledge and experience.

    Thursday, October 18, 2018 2:50 PM