If you have a small SharePoint infrastructure it'll probably work OK. If you're looking at a more enterprise level setup, then here's a few things I ran into...
a) DPM requires LocalSystem to be sysadmin in the SQL Server instance that SharePoint is installed into. That's for the SQL Server VSS writer to be able to enumerate databases. It also requires DataReader permissions in every other SQL Server instance on the machine (or cluster node). That's a violation of Microsoft's best practise guides for securing SQL Server. If you have the same people administering SQL Server as you have for Windows, then probably not so much of an issue. If you have separate teams, then the DBAs will probably not be happy b) DPM agent can only be installed on a single SharePoint WFE at a time. So you build a highly available MOSS installation with multiple WFEs, clustered SQL Server etc, but your backup solution falls over because one crucial WFE is offline c) DPM restoration requires a separate, standalone, MOSS installation. To restore anything less granular than a single database (e.g. a site or document or list), DPM copies the entire content database to this standalone MOSS installation, then uses SharePoint APIs to extract the necessary documents into a backup file, then copies that to your Production MOSS installation, and then imports it. So, you are paying for extra MOSS license. d) The Site Collection template of the site you are restoring must match the site collection that you are restoring into. But you can't see what those site collection templates are from within DPM. e) 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) f) If you remove a content database, you need to take an entire baseline replica again and start taking new snapshots. This can start to blow out your DPM storage requirements if you frequently add/remove content databases g) 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 can't h) 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. Cheers Ken From: Tim Evans [mailto:tev...@sparling.com] Sent: Friday, 9 October 2009 9:39 PM To: NT System Admin Issues Subject: RE: Backup/Restore best practices for Sharepoint 2007 Interesting. We are looking at evaluating DPM. Can you elaborate on why you recommend against it? Thanks ...Tim From: Ken Schaefer [mailto:k...@adopenstatic.com] Sent: Friday, October 09, 2009 6:19 AM To: NT System Admin Issues Subject: RE: Backup/Restore best practices for Sharepoint 2007 AvePoint also have a popular product (DocAve) in addition to the two listed below. I would strongly recommend against DPM 2007. Cheers Ken From: Steven M. Caesare [mailto:scaes...@caesare.com] Sent: Friday, 9 October 2009 8:49 PM To: NT System Admin Issues Subject: RE: Backup/Restore best practices for Sharepoint 2007 Indeed. I can confirm both Veritas NetBackup and CommVault Simpana both have Sharepoint agent document-level capability. We are moving from the former to the latter. -sc From: Sherry Abercrombie [mailto:saber...@gmail.com] Sent: Friday, October 09, 2009 8:40 AM To: NT System Admin Issues Subject: Re: Backup/Restore best practices for Sharepoint 2007 You'll need to have a backup solution that is Sharepoint aware not just SQL aware. Backup Exec has an agent specifically for Sharepoint that will do the document level backup/restore you are asking for. Otherwise, if you just rely on SQL backups, you'll have to restore the entire SQL db to recover, which means everything since the backup is lost. I think most of the major backup software packages have something like BE has now for Sharepoint. A few years ago, that wasn't the case and you had to go with 3rd party backup to get the document level restore capability. We used a product called AvePoint for that for a couple of years until BE came out with their SP agent. On Fri, Oct 9, 2009 at 7:30 AM, Erik Goldoff <egold...@gmail.com<mailto:egold...@gmail.com>> wrote: Wonder if anyone has any good links for best practices in backup and restore for Sharepoint 2007 data ( ie, how to recover a document after user accidentally deletes it from the sharepoint database, recovery after drive corruption, etc ). I have an 'associate' that has just installed Sharepoint 2007 at one of his law office clients at their request, but needs to learn more about it. I've done *some* work with Sharepoint but don't consider myself at the expert/specialist level and could use some feedback from those that have the proper experience ... Thanks in advance Erik Goldoff IT Consultant Systems, Networks, & Security ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~