Introducing Long Term Retention for DPM Azure cloud backups - The Official System Center Data Protection Manager Team Blog - Site Home - TechNet Blogs

Introducing Long Term Retention for DPM Azure cloud backups

Introducing Long Term Retention for DPM Azure cloud backups

  • Comments 12
  • Likes

We are pleased to announce the availability of long term retention for Azure cloud backups in Update Rollup 3 (UR3) for System Center 2012 R2 Data Protection Manager and the latest release of Microsoft Azure Backup. This is one of the most voted feature on Azure Backup feedback forum so we look forward to your feedback once you start using it.

We have integrated the experience in the same configuration screen that you currently use for setting retention policies when using Azure as the target in DPM. You need to select the weekly option that allows you to specify the schedule for longer retention range. The screenshot below shows as sample schedule with a maximum retention of 3360 days.

Figure 1: Once every 4 weeks backup on Sundays at 9pm

image

Before explaining the retention range and schedule, it is important to understand how the recovery points are modeled in Azure back-up.  Each back-up is stored as a recovery point and we can currently store up to 120 recovery points which is limited to a retention range of 120 days.  Although the 120 retention point limit is still in place, we have enhanced the feature to allow a less granular option of weekly back-ups to model a longer retention period. Here is the full range of options for the maximum retention possible with this change.

Synchronize every <n> weeks Maximum Retention computation Maximum Retention in days
1 120 x 7 x 1 840
2 120 x 7 x 2 1680
3 120 x 7 x 3 2520
4 120 x 7 x 4 3360

Instead of using the above calculation to compute the retention range, you might wish to specify the retention range in terms of your business requirement which might be “I need a monthly back-up to be retained for 5 years”.  In this case, you can derive the number of days by multiplying with 365 (adding a correction for leap years as needed).  Here are some of the popular retention ranges we have heard from customers to illustrate the calculation. You will need to derive it similarly for your business requirement

Retention in years Retention in days Leap year correction Total Retention in days
1 365 x 1 +1 366
5 365 x 5 +2 1827
9 365 x 9 +3 3288

Depending on either method you use  to compute the retention range, you need to then enter the value in the “Retention range in days” field.  The rest of the feature works as it does currently except that you can retain your data for a much longer period.  Please click the relevant links below to get started and do send us your comments/feedback.  Thanks !

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Awesome! Can't wait to try this out!

  • that's a winner - chicken dinner

  • Nando's for all!

  • Shame we're still restricted to 1.5TB :(

  • thanks

  • Thanks for the feedback (and the chicken :-))
    @Steve - we increased the DS size limit from 850GB to 1.6TB which our telemetry showed to be generally quite big for SQL DBs and VMs. We don't currently protect SP and Exchange, but even there sizes of individual DBs don't go much higher. SP guidance is to have individual content DBs no greater than 200GB for optimal performance. Are you thinking of very large Fileservers ? and if so, what size were you imagining ?

  • Agree with Steve, we have some file server volumes in the 3+TB range

  • Yes, we are also hampered by the 1.65TB limit. Something about 3TB+ would help us in most cases.