Monday, November 02, 2009 1:18 AM
Some thoughts on protecting Sharepoint 2007 with DPM 2007 SP1
Disclaimer: I don't claim to be an expert in Data Protection Manager 2007! However after recent experiences, I believe that the following items should be considered when evaluating DPM 2007 SP1 for protecting your Sharepoint/MOSS 2007 farm. Note: DPM 2007 SP1 is required to protect backend SQL Server clusters. Don't even consider DPM 2007 without SP1.
The diagram outlines a typical minimum configuration for a highly available MOSS 2007 infrastructure, with DPM 2007 included. An organisation is free to add additional servers for further redundancy as required:
DPM 2007 SP1 backs up your MOSS 2007 farm in two ways:
- The databases are backed up directly from SQL Server using the SQL Server VSS writer
- A DPM agent installed on a MOSS WFE generates the heirachy of site collections, sites, items etc
When restoring an item, site, collection etc the following process is used (restoring an entire database or farm can be done directly to SQL Server):
- The relevant content database is copied to the standby/restoration MOSS server
- MOSS APIs are used to extract the relevant information and saved to a MOSS backup file
- This file is copied to the WFE that hosts the DPM agent, and is imported into your Production MOSS farm
When deploying DPM 2007 SP1 to protect your MOSS 2007 farm, the following needs to be considered:
- The DPM agent can only be installed on a single WFE in the farm. Even if you build a highly available MOSS farm with multiple web front ends, middle tier servers and a backend SQL Server cluster, your backups may fail because the single WFE with the agent installed is unavailable. You can transfer the agent between WFEs, but this is a process you need to manage yourself (whether manual or automated by scripts)
- The account that the DPM agent runs under needs to be both a SharePoint 2007 farm admin account, and a local Windows Administrator account on the WFE. Whilst the SharePoint minimum security configuration doesn't require the Farm Admin account to be a Windows Administrator account, you need to promote that account on the relevant WFE. If you wish to easily transition the WFE that the DPM agent is installed on between WFEs, you need to make the Farm Admin account a Windows Administrator account on all WFEs
- To restore anything less granular than a single content database, DPM will copy the entire relevant content database to the restoration MOSS server. This can involve significant amounts of time (e.g. you have a 100GB content DB, and you wish to restore a single document, DPM will still copy the entire 100GB content DB). This content DB is then mounted on the temporary server (ensure you have enough disk space on this server to cater for your largest content DB) and the relevant item(s) extracted. Maintaining this restoration SharePoint server consumes additional hardware, Windows OS license and SharePoint licence.
- When restoring any items to the Production SharePoint infrastructure, other than the original location, the Site Collection template of the source (i.e. what's being restored) and the destination (your temporary location) must match. The site template itself doesn't matter. This is not a requirement when using SharePoint's native backup/restore tools, but some requirement of the way DPM interacts with SharePoint. Unfortunately there is no way, from within the DPM console, to tell what the relevant site collection templates are
- If DPM is performing a backup, you can’t do a restore without cancelling the in progress backup. However in my experience the actual backup can take a long time (in the order of many hours) if the WFE that you have your DPM agent on is busy (e.g. participating in crawling content). DPM backups will also fail if the SQL Server is heavily loaded (e.g. backups of SQL Server or other maintenance operations are in progress). This can restrict what SLAs you are able to offer to your end users.
- Adding and removing content databases makes DPM unhappy. Adding a new content database merely requires a consistency check job to run. If you remove a content database this requires an entirely new base replica to be created. This can quickly blow out your storage requirements if you are in an environment (e.g. Dev/Test) when content databases are often added/removed
- DPM backs up in a couple of ways – it backs up the databases directly from the SQL Server via VSS, and then gets a catalogue of restorable items from the WFE. If the latter fails, half the time you don’t seem to get a decent warning about it. Instead, when you try to restore you find out that you can only restore an entire database. When you attempt to drill down to content, you simply can't (double-clicking on a content database in the console doesn't result in an error - simply nothing happens)
- Installing DPM relies on a bunch of hotfixes and other stuff to be installed to get it working properly. There’s even a DPM hotfix you need to install if you install MOSS Feb 2009 CU, because somehow that MOSS CU stops DPM discovering your MOSS installation as a protectable item. VSS is another thing that seems to require continual patching.
- The SQL Server VSS writer runs as LocalSystem on the SQL Server. This means that LocalSystem requires permissions to the Master and MSDB databases (DataReader seems sufficient) on every instance on every node on the backend SQL Server cluster. If you are have configured your SQL Server cluster to use separate process identities and removed LocalSystem from being able to login (e.g. to prevent Windows administrators from accessing SQL Server), then you'll need to add LocalSystem back in as a permitted login in SQL Server. The VSS writer needs to be able to find out where all the databases are located physically in the file system, and whether they are being mirrored or not, and to do that it needs to query Master and MSDB
Overall, in a smaller environment, DPM 2007 would be simple and easy to use. The console is quite intuitive (even if the setup requirements are a bit obtuse). In a larger enterprise enviroment, I would hesitate to recommend DPM 2007. There are simply too many limitations in the backup and restore process, that end up hobbling the product.