The purpose of this blog article is to inspire and inform
you as a reader what you should consider before you start implementing System
Center Data Protection Manager 2016 as the restore-feature within your
datacenter.
Throughout the years, I have noticed a lot of different
designs that hasn’t played out well. So hopefully readers of this article will
avoid any of those pitfalls that either leads to reinstalling System Data
Protection Manager or realizing that you are not able to do that restore
scenario that you first thought of.
Having sorted out those questions I can assure you that the
road to a successful DPM implementation based on the BaaS concept will be
closer at hand for sure.
The start, building the restore scenario
The most important part when it comes to backup has always
been, and will always be one thing, restore. This should always be your major
and primary focus in any design regardless of technology.
Having a prober recovery-plan will provide you with an
optimal backup design and strategy that will meet the company need for
recovery. However, this is just the thing that the majority of companies misses
out on. Building the restore scenario first will provide you a more optimal
design when it comes to, for example, the number of DPM servers needed, time
for recovery point creations and also archiving/long-term protection and more.
The best way to get started with this strategy is to identifying two things:
- Infrastructural Services
- Business Services
Your Infrastructural Services is for example your Active
Directory meanwhile your Business Services could be your CRM solution that
consumes the Infrastructural Services that builds-up the Business Services. The
initial step in building a true restore scenario is to breakdown all the
Infrastructural Services that cooperates to deliver the Business Services. What
Windows Servers are involved? Does the Business Services use SQL Server and is
there any IIS also dependent for a successful delivery of the Business Service
from an end-user perspective and so on.
Having a detailed breakdown of a Business Service will also
help you identify and understand how you could consume Azure services like
Azure Site Recovery and others IaaS, PaaS or SaaS services in the most optimal
way for your restore-process of the Business Service.
Virtual vs. physical DPM servers
This is a very common discussion, even today, where people
tend to keep the physical concept for the DPM servers instead of virtualizing
them. The most important part when it comes to providing restore concepts for a
company is being able to simply scale and provide more resources to your BaaS
(Backup-as-a-Service) service that you provide and deliver for your company
regardless of the company size.
This is a simple task when you adapt a virtual concept for
your DPM servers where you are able to provide a deployment plan for new DPM
servers that will be associated with your BaaS.
The most important take-away; if you haven’t virtualized
your DPM servers yet and thinking of deploying DPM 2016, Microsoft highly
recommend you to virtualize them using Hyper-V to achieve the possibility of
providing scale.
DPM disk setup
To get the most out of your DPM servers, both form a performance
perspective but also from a disaster recovery perspective (restoring the DPM
server itself), you should use the following disk setup.
- OS disc (your
%systemdrive%)
- Program disc (Where
you install all software)
- DPMDB disc (dedicated
disk for the DPMDB)
- Azure Scratch (A
disc dedicated for the MARS agents scratch catalogue)
- Recovery disc (A
dedicated disc dedicated for the prestaging procedure for the MARS agent)
All discs should be in the VHDX format and the dedicated
DPMDB disc should be fixed in size due to performance; all other discs could be
dynamic discs.
SQL Server installation
There are some key points when it comes to delivering an
optimal SQL Server installation for System Center Data Protection Manager 2016.
The importance of having dedicated service-accounts for your DPM server is a must but also the fact of using
the correct collation of your SQL instance hosting the DPMDB. The only
collation you should use are SQL_Latin1_General_CP1_CI_AS
All other collations are unsupported, so keep in mind to use
the right one or you end up reinstalling your DPM servers from the beginning.
Also, remember to setup the amount of memory your SQL Server
should consume. This should be set accordingly to the number of GB you have,
spare at least 4-6 GB of RAM for the operating system. The SQL memory
configuration is defined in the SQL instance that hosts the DPMDB.
Having a poor or wrong setup or configuration will give you
a negative impression of DPM. Keep in mind that the SQL Server is the engine
behind it all; If its configured poorly the engine will perform badly, simple
as that.
Antivirus exclusions DPM and the MARS agent
The most common performance challenges there is regarding
DPM is the fact of not setting up the real-time protection on the antivirus
software correctly. If you don’t configure the exceptions for catalogues and
services, you will end up with possibly corrupted data.
For System Center Data Protection Manager you should exclude
the following catalogues that resides within the DPM installation catalogue:
The following process should be excluded from real-time
scanning:
For the DPM servers that has the MARS agent installed and
pushing data to Azure it's important to exclude the following catalogues:
- Microsoft Azure Recovery Agent\Bin
- Scratch folder
The following processes must be excluded from real-time
scanning:
- CBEngine.exe
- CSC.EXE (Goes
for both DPM and the MARS agent)
Not having the correct exclusions will end up with your
local antivirus scanning your DPM disk pool or the or scratch area for example.
However, there is one more thing you should keep in mind. In
the case where your antivirus software does find a threat you shouldn’t
quarantine it (which is the most common policy), you should have it deleted by
default.
Protection Group Designs
This is one of my favorite topics from the field. I have
seen a lot of interesting designs when it comes to designing Protection Groups
throughout the years and here is some of my thoughts that has played out very
well for a large number of companies.
The first thing to keep in mind is the Protection Group
name. The best staring point is to build your Protection Groups designs
according to your Business Services RTO, RLO and SLA (if any). The Recovery
Time Objectives (RTO) is the definition if how fast you should be able to be
back-on-track with your Business Service. System Center Data Protection Manager
can either synchronize your data changes every fifteen
minutes for workloads like SQL, Exchange and File. For other workloads
like SharePoint, Hyper-V etc., DPM can make Recovery Points every thirty
minutes. So, having a clear understanding of your Business Services and your
Infrastructural Services are crucial since the Protection Group is where you
set the actual backup strategy or plan that should correspond to your restore
plans.
Regarding naming of Protection Groups there are a few tips
that could hopefully inspire some DPM administrators. To get a decent start you
should consider using the following naming convention for your Protection
Groups:
- Workload +
“number of recovery points per day or week” + time + SYNC info + Azure + time
An example for a Protection Group having this naming
convention would be:
- File (1RP/d 01:00PM | 6h Sync | Azure 01:00 AM)
In some cases, you could also provide the retention range
for your on-prem disc and also Azure to make it even more clear. An example
would be:
- File (1RP/d 01:00PM 30 days|No Sync|Azure 01:AM
180 days)
In this latter example, you get a clear understanding of what
kind of members should be associated with this Protection Group but most
importantly your restore capabilities. Let’s break it down shall we. The
members of this Protection Group are for the File workload. Everyday a recovery
point is made 01:00 PM that has a Retention Policy that states that the data
should be available for 30 days on-prem meaning in the DPM disk pool. There is
no extra synchronization made for the members of this Protection Group and all
protection data will be sent to Azure 01:00 PM where it will be stored 180 days
back in time.
Replace your tapes, use Azure since it really works…
There are many companies that has now started their journey
to using Azure instead of tapes for their long-term retention. In many Business
Cases I have made, Azure is far most the most optimal and cost effective
solution when it comes to long-term retention for System Center Data Protection
Manager protected workloads.
More than 50% of the cases; using Azure will cut the cost in
half even for those companies that uses TaaS (Tape-as-a-Service) solutions or
VTL.
One important fact to point out is the possibility to
restore data from a Recovery Service Vault that is shared between DPM servers.
Let’s say that you have two or more DPM servers associated with the same
Recovery Services Vault. If one DPM server fail you are still able to restore
the data that the DPM server pushed to Azure by adding the Azure Passphrase
generated in the MARS setup. This could be done via the Add External DPM feature from the Recovery pane in DPM. This means one simple thing, as long as you
have your protected data in Azure, you will always be able to restore it.
