From the Technet document, Restore a Farm: Backing up the farm will back up the configuration and Central Administration content databases, but these cannot be restored using Microsoft SharePoint Foundation 2010 tools. Documentation is copius regarding the restoration of content databases, but no word on these system databasesDisaster recovery articles all have the suspicious similarity of assuming the application farm is up after the disaster and ready for database recoveryWhat good is this backup -- configuration only or not -- if you can't reestablish the core farm with itWhat is the process to rebuild the farm

Documentation doesn't exist because the restoration of both the configuration database and Central Administration content database is unsupported. The supported method of fixing issues with these components is to create a new farm which creates both databases.The assumption that the farm exists before restoring is because having a farm running is a requirement for the restore to work. All the servers must exist and be joined to the farm in order to restore your data to them. Let me say this another way: When you create a farm and join servers to it, you are creating the destinations locations for the services and applications. The restore then programatically creates all the services and applications and restores the service and content databases to SQL Server. The full farm restore doesn't perform a restore as you would expect, i.e. overwrite the data, it actually creates everything through code and then attaches the databases.I can guess at a few reasons the full farm backup backs these up: Customers would flip out if the out of the box tool didn't back up everything in the farm.Microsoft could have future plans to support these components for restoresThe full farm backup actually performs a SQL backup on these databases. By default all SharePoint databases use the full recovery model, so by performing a backup against the databases it allows DBA to truncate the transactions logs. A quick search for "SharePoint configuration database growing" will show lots of people who don't follow SQL best practices ;) The high-level process is: Provision your servers (build them or spin up a VM), install OS, prerequistesInstall SQL ServerInstall SharePointConfigure a new farmJoin all servers to the new farmFull farm restore Jason Warren Infrastructure Specialist Habanero Consulting Group habaneroconsulting.com/blog

Beautiful! For the sake of satisfying my documentation requirements, where does Microsoft say this? Questions raised, some rhetorical, some not: 1) then why back them up? 2) so my SQL Server backups of the SP databases are good for nothing? 3.3) wouldn't the SP SQL backup process play hell with the SQL Server backup processes...where's that interim backup and logs? 4) where does the application of the more recent SQL Server backup databases come into the picture?

It doesn't. Or if it does, it's not in any documentation I've ever seen. Microsoft usually doesn't provide much information unsupported areas. You'll see something like "restoration of the configuration database is not supported using the built in backup and restore functionality" and "We do not support restoration of the configuration database in SharePoint Server 2007 and in Windows SharePoint Services 3.0 using the built in backup and restore functionality" Actually, that KB article does say a bit about why it's not supported: If you restore the configuration database, data in the configuration database will not be synchronized with data in other SharePoint Server 2007 or Windows SharePoint Services 3.0 databases. If this data is not synchronized, users may experience various random errors. For example, a Windows SharePoint Services 3.0 content database may contain data about a newer site. If the configuration database does not contain information about this site, the site is orphaned. I was originally drafting something along these lines, using the example of restoring a configuration database to a farm with more servers than was present in the original farm -- how should the restore handle these extra servers? Should it ignore them? Attempt to restore to them? Delete them from the farm since they shouldn't exist (as far as the data from the backup is concerned)? Like I said before, I have some guesses. I'm not aware of any official documentation about the reason. Another guess I just thought of is that the configuration database contains configuration information for the farm, specifically a list of services and web applications. The restore could use this information to support the restore of the other components, but without access to the source code I cannot say for certain.Your SQL backups are good for performing SQL restores. Depending on the backup architecture for your organization, it may be easier to restore a database using SQL tools (or whatever tool you use) than it is to restore it though the SharePoint interface. With the full recovery model you are also presented with the ability to perform point-in-time restores if you back up the SQL databases. It depends on your specific needs.The assumption is you are performing SQL maintenance tasks after the farm backup completes. Most of my experience with mid- to large-enterprises is they use a third party backup suite instead of the out of the box tools so this issue doesn't come up. I've seen some companies change all the databases to simple because they don't care about dealing with the transaction logs.I'm not sure I understand the context of this question -- what more recent SQL Server backups? Jason Warren Infrastructure Specialist Habanero Consulting Group habaneroconsulting.com/blog

No, I meant, where does Microsoft list out the steps you listed? The more recent SQL Server backups happened each hour after the SP backup for the logs and at midnight for the whole thing. In reference to your description, ...the restore restores the databases to SQL Server. Assumedly from the SP backup.

Ahh, my mistake. Here is the Office SharePoint Server 2007 TechNet documentation for backing up and restoring an entire farm, and here specifically is the documentation for restoring a farm with the built-in tools. You'll see none of the steps 1-5 listed. The documentation assumes the farm already exists. For reference, here is the documentation for deploying a farm. The SharePoint farm backups of the databases are just backups, they don't truncate the logs. If you're doing a SQL backup after the farm backup, you should also be truncating the logs unless you have reasons otherwise. The farm backup shouldn't impact your SQL backups or the ability to perform point-in-time backups since it doesn't do anything with the logs (hence the out of control growth some administrators see when they don't perform the truncations as part of a maintenance plan). Jason Warren Infrastructure Specialist Habanero Consulting Group habaneroconsulting.com/blog

Hmmm... 2010?

Same deal. Jason Warren Infrastructure Specialist Habanero Consulting Group habaneroconsulting.com/blog