Best Practice on Backups
In a recent thread with Bill Baer and an external consultant we had an interesting conversation on Backups, the Config DB, and Alternate Access mappings. The conversation was fairly rich, so I thought I'd share. You may want to start at the bottom, since this is an email thread. (portions removed to create anonymity)
Summary from my side on best practice... With disk based backups... Use catastrophic backup with a scheduled task for the most simple environment, then monitor the events for failed jobs or failed backups. Use SQL backups with jobs and then use stsadm to backup your indexes for the environment where you have a separate SQL team who monitor failed SQL jobs. It will be faster and easier to add other SQL jobs like DBCCs and verifications. For granular recovery, it's mostly about setting expectations and SLAs. The recycle bin in the product is a must use, you may want to consider extending the retention time at the web application level. For site backups/restores, I don't recommend doing stsadm backups on a daily basis unless you are ok with the overhead for disk space, and you don't mind blocking in the databases. You will see locks and blocking during site backups on large sites especially. What I do recommend is using the site delete capture tool on codeplex. Other granular recovery options exist with partner solutions such as from Avepoint, Commvault and Quest.
I do like DPM 2007 (http://www.microsoft.com/dpm) and am already a big fan (with the current beta and builds), but in the mean time I like what I've seen from third parties like AvePoint and Commvault and do recommend people check them out for full backup solutions.
Joel
From Bill Baer:
I have found the following >> "stsadm -o enumalternatedomains" which produces a great little export >>
AlternateDomains>
<Collection Count="1" Name="Central Administration">
<AlternateDomain>
<IncomingUrl>http://drp1:50000</IncomingUrl>
<UrlZone>Default</UrlZone>
<MappedUrl>http://drp1:50000</MappedUrl>
</AlternateDomain>
</Collection>
<Collection Count="2" Name="Portal1">
<AlternateDomain>
<IncomingUrl>http://portal1.local</IncomingUrl>
<UrlZone>Default</UrlZone>
<MappedUrl>http://portal1.local</MappedUrl>
</AlternateDomain>
<AlternateDomain>
<IncomingUrl>https://portal1.local</IncomingUrl>
<UrlZone>Extranet</UrlZone>
<MappedUrl>https://portal1.local</MappedUrl>
</AlternateDomain>
</Collection>
<Collection Count="1" Name="SSP">
<AlternateDomain>
<IncomingUrl>http://drp1:888</IncomingUrl>
<UrlZone>Default</UrlZone>
<MappedUrl>http://drp1:888</MappedUrl>
</AlternateDomain>
</Collection>
</AlternateDomains>
-----Original Message-----
From: Bill Baer
Sent: Friday, 6 July 2007 8:10 AM
To: Consultant
Cc: Joel Oleson
Subject: RE: Questions to pass on.
--Snip-- Correction SharePoint backup will not truncate your logs.
We rely on a combination of SQL backups and handle search through the OOB backup utility. This provides us a relatively safe recovery structure with a reliable percentage of success in terms of recovery. As we move forward in our DPM v2 testing we will likely drop the native backups and OOB backup of the search and indexing components. AAM is not backed up using the catastrophic backup, this is where DPM comes into the picture, but since it's not available to every customer - you should consider handling this via scripting or otherwise. I've never tried recovery based solely on catastrophic backup so cannot provide a great deal of input on configdb recovery issues in that space.
Load "Bill",8,1
-----Original Message-----
From: Joel Oleson [mailto:joelo@microsoft.com]
Sent: Friday, 6 July 2007 1:50 AM
To: MS
Subject: RE: Questions to pass on.
I'd say best practice is to use catastrophic backup to backup the index and Sql jobs to backup the databases. You don't want to back up the dbs twice.
For people that aren't comfortable with Sql... The easy thing to do is the catastrophic backup daily. The incremental diffs are good practice but do add to the complexity.
The config db restore is ok if all databases are being restored from a sql perspective, but under nearly all other circumstances you need a new config db which does mean redeploying features, solutions, remapping web apps... Redoing search and content sources doesn't make sense since that shouldn't be in the config db. I'd need more info.
You should loop in Bill Baer from MS IT and Samer Sawaya for details.
Joelo
-----Original Message-----
From: Consultant
To: MS
Sent: 7/5/07 5:44 AM
Subject: Questions to pass on.
Hi Could you please pass these questions on to the SharePoint guys:
1. The STSADM catastrophic backup switch also truncates the SQL logs (stsadm.exe -o backup -directory \\unc<file:///\\unc> -backupmethod full) once the backup is complete.
My question relates to "Best Practice"
In my opinion, "MOSS DRP Best Practice" should really be about telling our customers to perform both a SQL backup of databases as well as STSADM catastrophic backup (as above) to cover all bases.
Due to the fact that the Stsadm utility will truncate the SQL logs, should we be telling our customers to schedule the catastrophic backup after the SQL Database backup has occurred?.
By doing so, it ensures the transaction logs has been backed-up to tape before being "dumped".
Please pass this scenario on as I would like to get some feedback. Perhaps I'm being paranoid.
2. I have read the following two statements in Technet regarding the built-in backup:
a. SharePoint Backup/Restore will not backup "Alternate Access Mappings"
b. SharePoint Backup/Restore will not backup "Global Search Settings".
I'm just curious how we should be dealing with this if the tool doesn't cover it. Should we find a way to backup these settings via script or is this a manually re-instated setting? (which means also ensure it is documented to begin with). I want to ensure that we cover all aspects of SharePoint DRP in this document.
3. The Stsadm catatrophic restore option is able to restore the Configuration database and Central Admin database and web site.
I'm curious to obtain feedback from other SharePoint consultants out there regarding how you can actually use this to perform a DR as I can only seem to successfully bring back an environment by re-creating the Configuration database.
I'm assuming this option is available in the event of a corrupted Configuration database or Central Admin Database or web site.
Thank You.
Kind Regards,
XXX
Sr. Consultant
