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.
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.
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
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 !
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 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