Instructions on restoring a content database to a new farm.

Over the past week I've been working on a system where I've had to restore a very large content database from one farm to another. STSADM kept failing. The easiest way was to do a SQL backup of the database and restore it on the new farm's SQL server. Once we did that, through central admin we created a new web application, removed the content database associated with it from within central admin and added the restored content database.

Please note, you might sometimes see that once you attach it, it comes up saying sites as 0. To fix this, open up your restored database and configuration database in SQL Server. Then find the sites table in the restored database and located the ID of the site. Now open up the configuration database and find the SiteMap table. Located the row with the same site ID and then delete it. You should now be able to attach the restored database without issue.

Let me know if you have any problems with this.

Fadi

Backup and Restore

Many of you may have come across this, but I thought i'd write about it. We have a SharePoint application who's database has hit over 50gb (should split it, but ill post about that later). Anyway, TSM backups keep failing and stsadm backups work fine, however fail during the restore process. A qucik way to fix this is to use Central Admin backup and restore. Its simple, and it worked fine for the problem we were having.

I still HIGHLY recommend spliting the content database to more than one db as it's getting very big and SQL will manage it much better. As I said, I will post about how to split it later when I get a chance.

Web Applications and System Accounts

It's been a couple of weeks since my last post but I've been flat out fixing some SharePoint issues. I will add a post about it in a few days (it's a huge issue involving performance).

Anyway, I'm building a new farm for a client. It's a pretty large farm involving 6 servers (not including the DB). One thing I recommended was to have a different system account for each application they install on the farm. The main reason for this is to limit problems like accounts being locked or passwords being changed etc. This way, if a system account becomes locked, only the application using that system will stop functioning (instead of the entire farm). Now there's a bit more maintenance involved, however in the long run it's worth the work.

Fadi