We are having SP 2013 production farm with storing documents in individual site collections using workflow management.

One of the content databases is growing large with 250GB data storage in SQL server.

This content database mainly consists of two large site collections each showing 75 GB data when I checked through SPSite.usage.storage.

I am planning to separate one site collection to another new content database and I should not have option to create new web application as per application design and also should have same site2 url.

   Take complete content database full backup.
   Take site 2 back up separately using Backup-SPsite command (backup-spsite –identity https://site2  -path \\backupsite2.back )
   Remove the site2 permanently using Remove-SPSite –identity https://site2
   Create the new content database using New-SPContentDatabase pointing existing web application.
   Restore the site2 backup using same site2 url and attaching it to the new database created in step4 using Retore-SPSite
   The command should be Restore-SPSite –identity https://site2 –Path \\backupsite.back –ContentDatabase –NewSite2DB -force

We tested this approach in lower environments with site size around 10 GB and worked fine without issues.

This Restore-SPSite operation is taking long time to restore the site (e.g: 3.5 GB data took 4 hours in test server).

I am afraid whether the SP built in tools (Backup & restore commands) can manage taking large site collections with 100GB size

As per this TechNet link, Microsoft recommends to use Built in tools for backup & restore for size upto 100GB.

Is this 100GB site usage size like (SPSite.usage.Storage) or actual size of site backup up file (backup-spsite) ?

1 Answer 1


There are couple of ways which i think you can test for this move.

  1. as you mentioned, taking the backup of site collection and restore it in new content database. most of time it work but with large site it cause issue. I had tried a 55GB site but restore command timed out. there are many factors in this, So i would recommend test the scenario in lower farm.
  2. Move-Spsite, this is the great method, it will take time but eventually move the site collection into own content db. You have to make sure, new content Database should be on same web application and SQL server, Set the Auto growth for that DB at higher number as you are moving the site in it. At the end of completion, you have to run IISreset in the farm...quite possible this command also end up with timeout error, so you have to test in lower farm 1st with original site.
  3. This is the method which work all the time.

    • take the backup of Content Database
    • Restore it on lower farm sql server with different name
    • Now attach it to the web application in lower farm using mount-spscontentdatabase command with assign new database id.

    Mount-SPContentDatabase "MyDatabase" -DatabaseServer "MyServer" -WebApplication http://sitename -AssignNewDatabaseId

    • Once database attached then delete the other site collection (dont delete the site collection which you want to move into own db). once deleted,shrink your content database to reduce the size of content database.
    • Now take the backup of database from lower farm sql server than restore it in production farm.
    • Attach it to your production farm and test it.
    • Risk is here some time you have to delete the current site in production than attach the restore db. if something wrong with the db it will be DR situation.

All the above method required a down time, 1st and 2nd require a lot compare to 3rd. But you have to evaluate all the process and pick the one which works for you.

  • Hi Waqas, Tested 1 and 2 in test servers but as you said its timed out operaitons. I had the plan 3 in my mind and worried about shrinking database operation. Post shrinking the database, would it cause any issues when we restore back in production environment. Thanks for the response
    – kumar
    Commented Nov 21, 2017 at 14:09
  • it should not, make sure after shrinking, run the Maintenance job on the database from sql (which is rebuild index and update statistics). it should be fine. if you dont want this operation from SQL, in central admin > health analyzer rule...there is one rule which can shrink database. try that
    – Waqas Sarwar MVP
    Commented Nov 21, 2017 at 14:12
  • 1
    All of these approaches work well. The biggest issue you will face is how well SQL is optimized. Most admins don't pay attention to best practices. For example, pre-grow your database before you perform the move. You know how big it is going to get. The SQL default of 1MB and 10% is terrible and will lead to issues. Commented Nov 22, 2017 at 15:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.