Friday, March 02, 2012 9:29 PMcurrently using stsadm to backup and restore, thinking if it is necessary or required to backup the database wss_content and other database as well?
Saturday, March 03, 2012 1:02 AM
Sunday, March 04, 2012 11:30 PM
Tuesday, March 27, 2012 3:07 PM
No it is not necessary to explicitly backup the database
Wednesday, March 28, 2012 2:18 AM
Best Practices will be :
Instead of using the deprecated stsadm command please use the "SharePoint PowerShell Command".
Plan your sitecollection to have separated Content Database using mounting content database commadn for hassel free maintenance.
Manual backup for your root site's web.config file also useful as it will gives lot of information about the activated features and custom solutions on your site/sitecollection.It will be helpful when restoring the site collection in an isolated environment.
- Edited by Murugesa Pandian Wednesday, March 28, 2012 2:19 AM
Wednesday, March 28, 2012 4:38 PM
As this is a pre-SharePoint 2010 forum, I'll point out that the SharePoint 2010 PowerShell cmdlets for SharePoint will not work for George. STSADM is deprecated for SP2010, but is required for v3 (WSS 3.0 and MOSS 2007) farms.
George, let's look at your options.
Currently you are performing site collection backups. My assumption is you are backing up all of the site collections in your farm. If this is the case, SharepointDummy is correct to say you do not need to also back up the SQL database.
There are benefits to also backing up the content databases:
- The backup contains all site collections hosted by the database, that is, one file instead of several (one for each site collection)
- The backup is of a type familiar to SQL Server DBAs. This is important because it is in a format they are familiar with and can work with. SQL DBAs have a few tricks up their sleeves to get content restored from a SQL backup so you can consider this as a more robust backup
- By having two backups (site collection and SQL backup) you have a redundant backup
- SQL backup tools include a verification integrity check. You can feel safe knowing your SQL backups are good.
- SQL backups can be scheduled as part of a daily SQL Maintenance Plan
- If using a full recovery model, SQL Backups provide point-in-time restores
- SQL Backups can be restored and content databases attached to different farms for testing or recovery
I should also point out that in addition to the site collection backups which are useful for restoring only the content of a site collection, you can also perform full farm backups (catastrophic backups). This is an out of the box SharePoint backup method that backs up the entire farm (some exceptions apply) -- that is web applications, services, farm configuration, and content. You can use these backups to rebuild your farm in a disaster.
Ultimately the decision to use SQL Backups depends on whether you have the storage space (disk or tape) to perform both types of backups, and whether you need any of the benefits that a SQL backup provides.
- Marked As Answer by Jinchun ChenMicrosoft Employee, Moderator Monday, April 02, 2012 6:54 AM
Wednesday, March 28, 2012 7:00 PM
Thanks Jason for pointing out !.
Still except first 3 lines of my answer helpful for this thread!.I guess :)-
Wednesday, March 28, 2012 7:07 PM
Still except first 3 lines of my answer helpful for this thread!.I guess :)-
Tuesday, July 03, 2012 10:08 PM
I am currently struggling getting a successful restore ( I am new to the world of SharePoint ). Your post stating "Totally. The IIS Metabase, web.config and the 12 hive are good things to backup as well and are not handled by the out of the box backup tools." seems to be the root of the issue for me.
I use the backup-spsite cmdlet and the restore-spsite cmdlet. The restore operation appears to have created the content databases on the locally installed db. Before that I created a web application manually and a site collection with the same host header as the original site so the the restore-spsite command will work
How do I know exatly what to take on the source SP farm and place it on the target SP farm from the items you mentioned are not handled by out of the box backup tools. From what I gathered when this site was built all that was added was images the rest is out of the box SharePoint.
I am doing this for a DR drill to see if my backups on a cloud server could be restored on one of our local servers.
When the restore finishes and I try to browse nothing appears not even empty place holders.
Any help would be GREATLY appreciated. ( I am taking drastic steps at the point by taking a full server backup (using wbadmin) of the cloud server with AD SP etc ... and FTPing the whole 100 GB to my local environment to attempt a full server backup. I would just like a simple SP restore to work though.
Wednesday, July 04, 2012 2:50 PM
The cmdlets Backup-SPSite and Restore-SPSite are only for SharePoint 2010. Which version of SharePoint are you running?
For disaster recovery, you should be using the catastrophic backup and restore ("the full farm backup and restore"). This is done with the backup stsadm operation using the -directory parameter (instead of the -URL parameter which backs up site collections).
The catastrophic backup in SharePoint 2007 includes:
- Web applications and content databases (sites, content, pages, web parts, features)
- SSP and databases
- Search service, search databases
- Other services (e.g. Excel Calculation Services, Business Data Catalog)
It does not include the following:
- Solution files (.wsp). Make sure you have a copy of the solution files deployed to the farm, along with any installation or configuration documentation. You can use the SPSolutionExtractor tool to retrieve the .wsp files from the configuration database if you no longer have them. Note however that this won't include any installation information.
- IIS Configuration ("IIS Metabase" and web.config for each web application). The IISBACK.VBS script that is included with IIS can back this up. See Back Up and Restore the IIS Metabase (IIS 6.0). This will backup the metabase to an xml file that you can then include in your regular server backup.
- Files stored locally on the server (such as the "12 hive"). If you have installed anything into the 12 hive, or changed any files here you will need to make a backup of these (or document how to make these changes again in a new farm). Include this in your normal server backup.
- The configuration database. Each configuration database is tied to a specific farm. If you are creating a new farm, you need a new configuration database. You cannot restore an existing configuration database so don't worry about this.
- Central Administration (it's backed up, but usually this is not necessary when restoring to a new farm).
Basically the backup steps are:
- stsadm -o backup -directory \\path\to\backups
- Back up farm servers file systems
The restore is a bit more involved. In this scenario, assume this is a restore to a new farm (caused by hardware failure of the original farm)
- Build new SQL/SharePoint servers. Install SharePoint to the same version as was in the original farm
- Create a new farm. This will create a configuration database and the central administration site.
- Install any .wsp solution files. Do not deploy to any web applications as there are not yet any!
- Perform a full farm restore (stsadm -o restore -directory \\path\to\backups
- Verify the restoration was a success. Check access to the web applications, run a full crawl, profile import, etc.
- If there are configurations you need from IIS, restore the IIS metabase (careful, as this will overwrite the metabase so make sure you need the configurations)
- Restore any other files from the 12 hive if needed.
Wednesday, July 04, 2012 5:13 PM
I apologize for not mentioning that I am working with SharePoint 2010. I am trying to restore a site collection I backed up from another SharePoint 2010 server / farm. I hope you had this answer in a template already :-)
At his point I found a tool called SharePoint Content Deployment, http://www.sharepointnutsandbolts.com/2007/12/introducing-sharepoint-content.html it was mentioned in one of the threads. ( Have you heard of it before?).
I am now trying either to use the restore-spsite command Restore-SPSite -Identity "http://pnmsrv01:21044" -Path "R:\AUTOFTP\new_members_site.bak" -DatabaseName "NMS" -DatabaseServer "SQLSRV" -HostHeader "PNMSRV01" -Force -GradualDelete -Verbose
I attached a newly db to the web app before running the restore and it failed. Would there be any negative implications if I left the database options blank? Last time I tried that it created an instance SQLSRV\sharepoint that had a lower version of SQL ( lower than from where I backed it up from)
As well as perhaps attach the DB to web application create a site collection manually and then attempt to deploy the application via SharePoint Content Deployment or another method which I may not know of yet.
I am shocked the Microsoft did not build in a tool for the app deployment part.
I would appreciate and insight or suggestions based on the aforementioned.
Thanks in advance,
- Edited by uz127 Wednesday, July 04, 2012 5:14 PM