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/>  ~

Reply via email to