currently using stsadm to backup and restore, thinking if it is necessary or required to backup the database wss_content and other database as well?

Are you doing a site collection backup (stsadm -o backup -url http://sitecollection ...) or a full farm backup (stsadm -o backup -directory ...)?Jason Warren Infrastructure Specialist Habaero Consulting Group www.habaneros.com/blog

site collection

Hi, No it is not necessary to explicitly backup the databaseSharepoint Dummy

Hi George, 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. Murugesa Pandian.,MCTS|App.Devleopment|Configure

Hi Murugesa, 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 backupBy having two backups (site collection and SQL backup) you have a redundant backupSQL 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 PlanIf using a full recovery model, SQL Backups provide point-in-time restoresSQL 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.Jason Warren Infrastructure Specialist Habaero Consulting Group www.habaneros.com/blog

Thanks Jason for pointing out !. Still except first 3 lines of my answer helpful for this thread!.I guess :)-Murugesa Pandian.,MCTS|App.Devleopment|Configure

Still except first 3 lines of my answer helpful for this thread!.I guess :)- 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.Jason Warren Infrastructure Specialist Habaero Consulting Group www.habaneros.com/blog

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 databasesSearch service, search databasesOther 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\backupsIISBack.VBSBack 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 farmCreate 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\backupsVerify 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. Jason Warren Infrastructure Specialist Habanero Consulting Group habaneroconsulting.com/blog

Hi Jason, 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, Uriel

Hi Jason, 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.