Fuse is a Microsoft Partner, based in Northampton. We help organisations of all sizes to maximise IT efficiencies through the use of Microsoft cloud computing solutions.
Protecting Systems with Data Protection Manager 2007 - Our Experiences
We've been using Data Protection Manager 2007 to protect our internal and hosting environments for several months now, and undertaken a few customer deployments. We've learned a few things about it during this time, and as there's relatively little about it on the internet at the moment, have decided to write up what we've found here.
Firstly,
How we use DPM. DPM is essentially a backup and recovery tool, using a combination of disk-based backups, with tape archiving. We use it to protect all of our systems, where previously we had to use several different backup technologies - Exchange 2007, SharePoint (MOSS and WSS), SQL, Virtual Servers (Hyper-V and Virtual Server 2005) and Files. It also protects our Active Directories through system state backups. By having one centralised backup system, we have greatly reduced the administration and management involved in protecting our systems. Integration with System Center Operations Manager also means we get a much better view of our protection state.
Disk Based Backups
Originally we deployed DPM on Windows 2003 x64, using a PowerEdge 1850 connected to a SAN via iSCSI. Although this configuration worked, eventually the iSCSI support in Windows 2003 was unable to cope with the number of partitions that DPM created (mostly small ones for each SQL database we had, meaning there were over 300 partitions on each virtual disk). So we upgraded to Windows 2008 - big problem. Although iSCSI support is much better in Windows 2008 (and Microsoft will support DPM in this configuration), there was a memory leak in the virtual disk service, that meant after a couple of days, DPM would fall over. That was fixed by this
hotfix at the beginning of December. This fixed the VDS problem, but a few weeks later a new problem began - DPM's SQL server began crashing every time the tape backup job began...
Tape Based Backup
Our PowerEdge is connected to a Dell TL2000 tape library, an LTO autoloader with 24 slots. We've also deployed DPM with TL4000s and standalone tape drives. It is essential to get the correct driver for your tape libary when using DPM. It took us several attempts to find the correct driver from Dell and get our TL2000 to install correctly. Make sure you uninstall the drivers correctly if you pick the wrong one - you'll know it's the wrong one if DPM doesn't see the library. With the Dell drivers, we found the library has to be in random mode (not sequential) and the drivers have to allow non-exclusive access mode (unlike for other backup products such as Backup Exec).
Once you've bar-coded your tapes and loaded them into your library (and set up auto-cleaning), you have to do very little with DPM. It takes care of the tapes itself - no need for media groups, labelling or anything like that. We use the DPM inteface to remove weekly/monthly tapes from the library, and to pop in new/required tapes, but other than that, it manages itself.
Recovery
By far the biggest advantage of DPM is the ease of recovery. Recovering an Exchange Mailbox or SharePoint document library has become as easy as recovering a file, thanks to tight integration with the protected system. Here's some notes on what we've found with each type of recovery:
Files: Files are by far the easiest to recover, as with DPM they require no intervention from the IT department. DPM essentially takes over from the file server's own volume snapshots (otherwise known as "previous versions"), and redirects the user's view of these to the DPM snapshot volumes. So when a user needs to recover a file, all they do is right click the folder/drive it use to belong in (or the file itself if they need a previous version) and they get a long list of all the DPM disk based recovery points available. So end users can recover files from DPM in about three clicks. We retain 3 snapshots a day for at least 5 days using DPM, wheareas the files servers coldn't keep anywhere near that much many snapshots themselves. Things to bear in mind: FIle servers need to be patched with the DPM/VSS pre-requisites for this to happen; DPM needs to update AD to get permissions to the end-users; and you need to turn off "previous versions" on the DPM protected file servers.
SQL: DPM uses the same backup technology that SQL uses natively, so SQL is aware of the backups taking place, and you'll see this reflected in Enterprise Manager. However, this doensn't mean your SQL team will be able to recover databases using Enterprise Manager in the same way that file users can. You have to use the DPM manager to do this - however you do get the ability to recover to different instances, or copy the backup to a new location. In practice, we've found it's best to protect production databases through DPM, whilst development ones are best left to SQL management for ease - you can still backup the backup files through DPM if needed. Ensure also that DPM is the only application backing up a particular database - if you have maintenance plans doing the same job, neither DPM or Enterprise Manager will be able to sort out the resulting mess.
If you need to restore to alternate location, don't choose the "latest" recovery point, otherwise this option will be unavailable, so if you're using DPM to move databases, do a recovery point first.
Exchange: This is where DPM really pays for itself. Recovering Exchange, even Exchange 2007, is usually a long and difficult operation, requiring recovery databases, a strict sequence to be followed and lots of time. DPM makes it a simple wizard-led operation, requires no operations on the Exchange server, and can be used to recover an entire organisation, single mailbox, or item. Again you can restore to the original location, or redirect to a alternate location - even a .PST file. As with SQL and files, DPM for Exchange integrates completely with the Exchange backup API, taking care of truncating log files and meaning you can have multiple backup points available throughout the day without disrupting service.
SharePoint: DPM is rapidly becoming our recommended backup product for SharePoint. Of all the wokloads that DPM can protect, this is the one that requires the most configuration, and has given us the most problems, but once it's up and running, its easily the easiest to use of all the SharePoint recovery products we've used. 3 things you'll need to do to get SharePoint running with DPM:
1: Patch DPM, SQL and SharePoint with all the latest service packs and several hotfixes. As a minimum, we've needed SQL 2005 rollup 11, DPM SP1, and the SharePoint infrastructure update together with this
hotfix which enables DPM to catalog SharePoint items that are not approved - without all these we were getting the error below from DPM:
"DPM failed to obtain catalog information as part of the backup for SharePoint farm Sharepoint Farm\SQL Server\WSS_Config on
SharePointAgentServer. Your recovery point is valid, but you will be unable to perform item-level recoveries using this recovery point. (ID 3103)"
2: Create a "recovery farm". We use a virtual server that has MOSS and SQL installed, patched to the same level as the live enviroment. You need to configure SharePoint, and create a single site named DPMRecoveryWebApplication. Further details are
here. You will need to ensure your recovery farm has enough disk space to hold your SharePoint databases - we attach our virtual server to a iSCSI disk for this purpose.
3: Deploy the DPM agent to both your production and recovery SharePoint servers (if you have multiple front-end procduction servers, only one needs the agent). The run "configuresharepoint.exe" from the DPM\bin directory on each server. In DPM SP1 there are a few new options to this command, so with SP1 you'll need to enter as a minimum "configuresharepoint.exe -enableshareppointprotection" (you can use other options to support protecting indexes now, and if you have SQL mirroring - see
here).
You'll now be able to add the SharePoint farm to a protection group, and choose the recovery farm during recovery operations. Make sure you havn't protected any SQL databases that form part of the farm using SQL protection through DPM, otherwise you won't be able to select the farm for protection.
