Westminster College has made significant progress in migrating its backup operations from Backup Exec to Data Protection Manager 2010. Scott Lowe discusses some of the successes and the challenges of the project.
In a September 2010 TechRepublic article, I discussed Westminster College's migration from Backup Exec to Microsoft's Data Protection Manager (DPM) 2010 and outlined our reasons for making the switch. We were facing four challenges:
- Backup Exec licensing. We had been using Backup Exec for quite some time and needed to deploy additional servers and services and be able to protect some new workloads, including Exchange 2010 and SharePoint 2010 data. We were out of licenses to protect these workloads and would have needed to upgrade the existing software as well.
- Challenged backup window. Our backup window was starting to get a bit tight.
- Lack of continuous protection. We were using a very traditional backup operation that relied on full backups on weekends and differential backups once per day throughout the week. This left significant opportunity for data loss in between backups.
- Recovery time. When recovery operations needed to be performed, they could be monotonous, time-consuming tasks because we were still fully reliant on tape as our primary backup storage vehicle.
Since September 2010, we made significant progress in migrating our backup operations from Backup Exec to DPM 2010, although we still have a few workloads that reside on Backup Exec. Here's an update on our migration progress, in which I share some successes we've had, challenges we've identified and new opportunities that have arisen to improve our backup and recovery capability.
All of our critical workloads are being well protected under DPM 2010, including all of our enterprise, mission-critical database applications, Exchange 2007 and 2010, SharePoint 2010, and our file services.
I'm incredibly impressed by DPM, but I would probably feel the same way about just about any disk-based backup and recovery tool due simply to the sheer speed of recovery. Several weeks ago, we had a need to restore a backup from the previous evening of our ERP database, but we needed to restore it with a different name so that it could be modified by our ERP vendor for an implementation project that we have underway. Previously, this kind of activity would have taken an hour or two; however, we decided to give it a go with DPM. Between the time it took to stage the recovery and actually restore that database to a new name and location, we had invested a grand total of less than 10 minutes — for a 28 GB database.
My staff and I also learned that, although DPM doesn't come right out and say that you can rename a database during a restore, you can easily do so by telling DPM to restore the database to an alternate SQL instance and then simply choose the original instance, provide the new database name, and tell DPM to what location in the file system the databases should be restored.
Our ERP vendor was pretty surprised when we emailed them less than 15 minutes after receiving their initial request for this "play" database letting them know that their request had been completed. In the long term, this kind of turnaround time is good for us, too. Recovery time is surprisingly fast with DPM. Of course, we're recovering from disk over a 1 Gb Ethernet network in this example, so it should be faster than our previous tape-based recovery operations.
We're protecting mission-critical workloads much more often that we've ever been able to in the past. For example, we have our database applications updating the DPM replica every 15 minutes to hour, depending on workload.
The primary challenge that we still face is protection of our SharePoint 2007-based workloads; this is the last item still being protected by Backup Exec. The only limiting factor has been troubleshooting time, which we will get over the next couple of weeks. In the meantime, we've redirected Backup Exec-based protection to a disk-based virtual tape library. From there, we protect the Backup Exec data with DPM so that we're continuing to provide maximum protection to all data.
Another challenge is that we, unfortunately, have some Windows 2000-based services still in production that we had to find ways to protect. We've been able to work around DPM's inability to directly protect Windows 2000 machines by scheduling local backups and then simply handling those backups as file objects on other servers. We're working hard to get away from these Windows 2000 services.
More about our future plans
We house our backup systems outside our data center in another campus location that is, for all intents and purposes, underground. The location is not ideal from an accessibility standpoint, so we've been exploring other options. We could host backups completely off campus — and we will be doing so at some point — but as our primary backup mechanism, I don't believe in hosting the service anywhere near the data center.
As the college has been working on new construction, we've worked with our developer to create what I believe is a perfect solution for the backup hosting challenge. In one of our new buildings (it's about as far away from the data center as you can get and still stay on the campus network) the developers will be constructing in the basement a concrete bunker with 12-inch thick concrete walls and a concrete ceiling. They will also be installing a 3 hour rated fire door and standalone cooling for us. This room will be situated in the building so that it is as far underground as possible. In fact, on the other side of the outside wall will be nothing but earth.
The more I use DPM, the more satisfied I am with the product and the decision to move to it. It has proven to be very fast, easy to manage, and robust. Overall, it has been a great addition to our backup and recovery arsenal.