In the previous post, we’ve seen what is DPM and what can be achieved via DPM at a very High level. In this Blog Post, let’s see few GOTCHAS(The Oops Moments 😉 , things you should be aware of) to keep in mind implementing DPM.
Let me get this very straight, Absolute 100% protection/Up time is of course not possible. Yes, this is the same case with any other technology out there in market. Most of the cases, we the administrators, see Business saying ” we can’t tolerate even a single second of downtime, we can’t tolerate any data loss. Absolutely we need all the data to be recovered at any given point of time”. Let me say this, in practical world, this is not possible. Step back a little and work with your business to understanding the real business needs. Make them understand how technology works. Define RPO’s and RTO’s, Document SLA’s. Define allowable Maintenance Window, where we can perform any maintenance tasks on our Servers. The bottom line is, we should be able to recover from a disaster with least amount of data loss and least amount of time as much as we can!
Anyways, few things which one should be aware of before implementing DPM:
- DPM is heavily dependent on your Network Bandwidth as any other Backup tool available out there. Of course It has to copy data over wires across multiple Sites. With Compression enabled, make sure your servers have enough CPU cycles available.
- Of course, It’s also heavily dependent on your Disks performance.
- Initial Replica might take considerable amount of time depending on amount of data and Network Speeds.
- DPM doesn’t support FAT Based Disks. Disks can be either DAS, or SAN Based with NTFS.
- Disks within DPM Storage Pool should not contain any other Application Data, Volumes etc. All the Partitions/Volumes will be erased while initial Configuration of your Storage Pool.
- 15 Minutes is the least possible frequency for your Recovery Points.
- DPM Can’t be Installed on Machines with Fail Over Clustering Services being enabled. You’ve to remove that Role prior to Installation of DPM. Can’t be Installed on a machine with SCOM Agent on it.
- Be prepared for Multilpe Reboots for successful Installation of DPM.
- You can either Encrypt your Data or Compress your Data, but not both!
- If you’ve to use BMR(Bare Metal Recovery), System State Protection must be enabled.
- You can’t Backup Junction Points, recycle BIN, Paging File,SysVol Information Foder.
- Protected Systems can’t be moved between Protection Groups on fly. It’s not supported. You’ve to manually remove system from Protection Group and add it to new Protection Group.
- Don’t use SQL Server Application Protection for backing up your MOSS(Share point) Databases if you are already backing up MOSS Application. DPM will get confused with LSN’s and your Backups will fail.
- If you are backing up your SQL Databases, make sure that no other tool besides DPM is truncating your T-Logs. DPM Backups will fail in that case.
- If you plan to Install DPM SQL Databases remotely, make sure that you’ve to acquire License for your SQL Server. If you’ve chosen to Install Locally on the same machine, DPM will cover SQL License for you!
- DPM Installation will fail, if your SQL Installation fails. Make sure to Install DB Engine, SSRS, SQL Client Connectivity SDK and Management Tools as bare minimum. For remote SQL Deployments, Named Pipes must be enabled. We’ve to Install SQL Server DPM Support Files prior to DPM Installation( Can be found in SQLPREPINSTALLER folder in your DPM Media)
Hope this is informative! BTW, There’s fabulous documentation from microsoft on troubleshooting any issues related to DPM.
It can be downloaded from http://www.microsoft.com/download/en/details.aspx?id=15954.