none
Advice on protection group design for bare metal recovery RRS feed

  • Question

  • Hello,

    I'm looking for a little advice on the design of protection groups where BMR is concerned (e.g. should you have separate PGs for BMR datasources?). The best practices articles for protection group design seem to be more art than science, so I was wondering what the current recommendations from MS are? I'd be very interested to hear the opinions of DPM admins too.

    Thanks for your help

    Steve

    Wednesday, August 21, 2013 12:10 PM

Answers

  • Hi,

    Yes, that would work. If the Physical DC is only a DC and plays no other roles, then maybe a daily BMR would work fine for you.  Daily SystemState is just as good from other DC's - I would also pay close attention to which FSMO roles are on which DC so you get adequate protection and know what roles to change to other DC's in the event of an outage.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, August 22, 2013 2:32 PM
    Moderator

All replies

  • Hi,

    <snip>
    The best practices articles for protection group design seem to be more art than science..
    >snip<

    The purpose of a protection group is for:

    A) Grouping servers and or data sources that have the same backup requirements (frequency and retention range and type (disk vs tape)) together.

    B) Help distribute backup times so not all backups run at the exact same time.  You can have same requirements for frequency and retention, but want to stager the start times by placing them in separate PG's.

    C) Group like data sources (SQL DB's, Exchange DB's, Hyper-V VM's)  together for ease of management of those data sources.

    You can mix and match based on your personal preference / requirements, so doses of both art and science.

    For BMR protection, it would be overkill to make multiple recovery points on the same day, so you would not want to include BMR in the same Protection group for SQL that may make four express full RP's per day.

    Except for Domain Controllers, you can usually get away with a weekly BMR backup if you are protecting application workloads separately. 


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, August 21, 2013 9:48 PM
    Moderator
  • Hi Mike,

    Thanks for your post, on the BMR recovery I was thinking of having a Saturday morning BMR backup but the thing that concerned me was the DC situation you mentioned- obviously I cant have a weekly BMR backup of the DC and a daily backup of the system state on it.

    Just kind of thinking out loud, say I went with a weekly BMR on the physical DCs if I encountered an AD issue I could get an AD restore from a virtual DC system state couldnt I, so maybe it isnt such an issue after all?

    Thanks

    Steve

    Thursday, August 22, 2013 8:08 AM
  • Hi,

    Yes, that would work. If the Physical DC is only a DC and plays no other roles, then maybe a daily BMR would work fine for you.  Daily SystemState is just as good from other DC's - I would also pay close attention to which FSMO roles are on which DC so you get adequate protection and know what roles to change to other DC's in the event of an outage.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, August 22, 2013 2:32 PM
    Moderator