Move Sites from one Content Database to another

When a Content DB contains too many sites, we can script the migration process of the selected sites to be moved to another Content DB.

The purpose, is to reduce the number of sites from the DataBase1_site, and balance them between the 2 other DB, leaving Sharepoint the ability to distribute the sites on the DB's.

Step 1 :

First things first, the DataBase1_site Maximum Number of Sites is set to a lower limit (in this case, I divided by 2 the Warning and Number  - my choice)

This will leave Sharepoint to restore the sites to the lowest populated DB ( DataBase3_site in my case)

Step 2 :

Then, it's time to give some work to the SQL Team :

-          Full backup of the DataBase1_site as it is a customer requirement (and this time, I was happy to have it done !!! )

When backup is completed, I've locked all the sites that will be moved.

Then, time for SQL Team to do a differential backup of the DataBase1_site.

Step 3 :

I've written a .bat file with all those commands (according to the explanations of my SharePoint Guru), for each site that will be moved :

stsadm -o backup -url "http://<URL>/sites/<SiteToMove>" -filename "<SiteToMove>.bak"

stsadm -o setsitelock -url "http://<URL>/sites/<SiteToMove>" -lock none

stsadm -o deletesite -url "http:// <URL>/sites/<SiteToMove>"

stsadm -o restore -url "http:// <URL>/sites/POL_CONINO" -filename "<SiteToMove>.bak"

stsadm -o setsitelock -url "http:// <URL>/sites/<SiteToMove>" -lock none

1-      Backup:               Local backup to restore the site into to new DataBase

2-      SetSiteLock:      Unlock the site, or the DeleteSite will not be possible

3-      DeleteSite:        Delete the site from DataBase1_site

4-      Restore:              Restore the deleted site into the allowed DataBase

5-      SetSiteLock:      Unlock the site, as the restore was made from the backup of a locked site

If all is correctly done, job is finish.

But …. In case of problem … as the backup command didn't succeed for any reason, the restore of the full DB is needed, and must be done on SQL side.

Step 4 :

Now, the restore of the DB is done by SQL Team, and we must add the Content DB to Sharepoint, then create a backup of the lost site.

I've wrote a little script that will do all step, with a little "pause" to check the restore of the lost site, before deleting the Backup DB from Sharepoint.

As the Backup DB contains exactly the same sites as the production DB, a new ID must be set to the Backup DB using the stsadm.exe parameter :  –assignnewdatabaseid .

You can find all the details to the Microsoft TechNet Site:

stsadm -o addcontentdb -url http://backupsitemove -assignnewdatabaseid -databasename xxxxxxxxxx1_Site -databaseserver SQLServer\InstanceName

stsadm -o backup -url http://backupsitemove/sites/<SiteName> -filename "<BackupPath>\Backup\<SiteName>.BAK"

stsadm -o restore -url http://<Destination _URL>/sites/<SiteName> -filename "<BackupPath>\Backup\<SiteName>.BAK"

pause

stsadm -o deletesite -url http://backupsitemove/sites/<SiteName>

stsadm -o unextendvs -url http://backupsitemove -deletecontent -deleteiissites

pause

The last command will delete the Database from SharePoint AND from the SQL Server if the used account is set as dbo of the Content DB.

Step 5 :

A full Cralw had to be done to refresh the Search engine.

Step 6 :

Take a deep breath, a coffee and be proud of your job done without losing any user's data.

Nb:  for the little story, I've done all this recovery for one site… that had its last modified document/folder set to 2009 …

That's all folks