none
Moving SQL servers from one Protection group to another RRS feed

  • Question

  • We are using DPM 2012 R2 Update Rollup 4. We have started to move some SQL servers from a Protection group with 90 days of retention to a Protection group with 15 days of retention.  The recovery data is co-located on the backup device and we are using disk based backup.  A couple days after moving a couple of the servers, I have noticed that the number of recovery points has stayed the same and not decreased.  It would seem that when moving to a different protection group, that the SQL server would inherit the new retention settings instead of retaining the ones from the old protection group.  When I moved them, I stop protection of the databases and then added them to the new group.  Why is this occurring and how do I get the new retention settings in the new protection group to take affect?

    Friday, January 9, 2015 2:59 PM

Answers

  • Hi,

    I confirmed with Mike with your question and here is the reply:

    The following TechNet pages describes the behavior of stopping protection or moving co-located data sources between PG’s  

    Moving Between Co-Located and Non-Co-Located Protection Groups
    http://technet.microsoft.com/en-us/library/ff399045.aspx

    Stopping Protection for Co-Located Data
    http://technet.microsoft.com/en-us/library/ff399221.aspx

    To see what SQL databases are co-located on same replica, you can use the below script – then make sure you stop and reprotect ALL the databases together and we might re-use the same replica.

    $pg = get-protectiongroup (&hostname) | ? { $_.friendlyname -eq 'protectiongroup_name'} 
    get-datasource $pg  | sort-object -property replicapath | ft replicapath, name, diskallocation -AutoSize


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    • Marked as answer by WSUAL2 Thursday, January 22, 2015 10:07 PM
    Wednesday, January 14, 2015 1:59 AM
    Moderator
  • Thanks for the information.  DPM is really a pain when trying to move co-located data sources to different protection groups.  I do hope in future versions that this is simplified and corrected.  I am now stuck for 90 days with data that I don't want and I can't get rid of without getting rid of every recovery point for that group.  That is bad news when my LDM DB is almost full. 

    An important note for those who are trying to see how many extents certain data sources have when following this article http://blogs.technet.com/b/dpm/archive/2010/03/30/what-volume-to-migrate-first.aspx
    If your DPM DB has changed from "DPMDB" to DPMDB with bunch of random characters, you will need to this line in the script for it to work. 

    $db = $srvr.Databases["DPMDB"]   <-- change this to your server’s DPMDB name

    Also, you will need to greatly increase the width of your command window to see the "NumberOfExtents" column which is the most important column.

    • Marked as answer by WSUAL2 Thursday, January 22, 2015 10:07 PM
    Thursday, January 22, 2015 10:07 PM

All replies

  • Hi,

    I happened to find the following thread which is referring the same question as yours:

    https://social.technet.microsoft.com/Forums/en-US/34ff8ba9-c44d-4dd8-ab2c-e59c1946c093/move-protected-server-out-of-a-protection-group-and-into-a-new-protection-group?forum=dpmfilebackup

    For data sources that are not co-located - you can simply stop protection and retain the replica.  It will be moved to an inactive protection group.  when you make a new protection group and  re-protect the same data source, DPM will move it out of inactive protection and add it to the new protection group and automatically run a consistency check.  Normal protection will resume based on new protection group settings.

    ...data sources like SQL Databases, Client protection, and Hyper-V VM protection that allow multiple data sources to be co-located on the same replica volume. For those data sources, unprotecting and re-protecting in a new protection group will make new replica and recovery point volumes which you wanted to avoid.


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, January 12, 2015 5:40 AM
    Moderator
  • Ok, that clears up what I shouldn't do when moving co-located data.  So what is the correct way to move co-located data sources to new protection groups?

    Also, since I did it the wrong way, how do I get rid of the old recovery points and the old replica?  Basically cleanup the mess that has been created.  My logical disk manager database is at 89% so this needs to be fixed ASAP.  Thanks.

    Monday, January 12, 2015 2:04 PM
  • Hi,

    I confirmed with Mike with your question and here is the reply:

    The following TechNet pages describes the behavior of stopping protection or moving co-located data sources between PG’s  

    Moving Between Co-Located and Non-Co-Located Protection Groups
    http://technet.microsoft.com/en-us/library/ff399045.aspx

    Stopping Protection for Co-Located Data
    http://technet.microsoft.com/en-us/library/ff399221.aspx

    To see what SQL databases are co-located on same replica, you can use the below script – then make sure you stop and reprotect ALL the databases together and we might re-use the same replica.

    $pg = get-protectiongroup (&hostname) | ? { $_.friendlyname -eq 'protectiongroup_name'} 
    get-datasource $pg  | sort-object -property replicapath | ft replicapath, name, diskallocation -AutoSize


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    • Marked as answer by WSUAL2 Thursday, January 22, 2015 10:07 PM
    Wednesday, January 14, 2015 1:59 AM
    Moderator
  • Thanks for the information.  DPM is really a pain when trying to move co-located data sources to different protection groups.  I do hope in future versions that this is simplified and corrected.  I am now stuck for 90 days with data that I don't want and I can't get rid of without getting rid of every recovery point for that group.  That is bad news when my LDM DB is almost full. 

    An important note for those who are trying to see how many extents certain data sources have when following this article http://blogs.technet.com/b/dpm/archive/2010/03/30/what-volume-to-migrate-first.aspx
    If your DPM DB has changed from "DPMDB" to DPMDB with bunch of random characters, you will need to this line in the script for it to work. 

    $db = $srvr.Databases["DPMDB"]   <-- change this to your server’s DPMDB name

    Also, you will need to greatly increase the width of your command window to see the "NumberOfExtents" column which is the most important column.

    • Marked as answer by WSUAL2 Thursday, January 22, 2015 10:07 PM
    Thursday, January 22, 2015 10:07 PM