Moving Site Collection Databases from Production to a Test environment and renaming Site Collections
I am looking for some advice on moving site collections from a production environment to a test environment in SharePoint 2013.
We have a production farm with several host-named site collections. Each site collection uses its own content database and some of these are rather large. (80-130GB) In the past, we used to make a backup of the site collections using the PowerShell "Backup-SPSite" command and then copy those backup files over to our test environment and restore them using the "Restore-SPSite" commands, however since this locks the site collection into read-only mode and with the size of our collections being so large, this is proving to be not an acceptable method of transferring Site Collections to our test farm.
Additionally, our test farm uses a "TST-" prefix for the site collections, so for instance in production we would have http://mysite.domain.com and in test the same site would be http://tst-mysite.domain.com.
I am considering doing this a different way, by copying the database backups from our production environment over to our test environment's SQL server and then restoring those or attaching the database to this server and then mounting and renaming the site collection contained in the database.
So my question is, does anyone have any recommendations for performing this, or any links you can point me to? I've googled and searched but I cannot find anything similar to my situation. My initial thoughts were to delete the site collection in test, along with it's content database, then attach and mount the new content database to the test SQL server. Once this was done, I would issue an SP-Site.Rename method on the site collection to restore the original host name to the newly restored site collection.
Are there any drawbacks to doing this? Any better or preferred way to perform this task? I have about sixteen site collections that I'll need to move to test in order to bring our test environment up-to-date with production.
You need to pay attention to the following points:
1. You need to lock the site collection into read-only mode when you copy content database.
2. If the site collection is a root site collection, you need to attach content database under a web application without root site collection. If not, the root site collection will be overwritten.
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact email@example.com
A simpler option would be to use the existing backup files for the database as a source for the restore action.
There is no real risk to your production instance here. I haven't moved HNSCs before so i can't shed much light on the problem. However there's a nice blog post by Kirk Evans on moving to HNSCs that may help you out with some of the process here: https://blogs.msdn.microsoft.com/kaevans/2013/09/09/moving-path-based-to-host-named-site-collections/
There's also a technet thread here that seems to include the process: https://social.technet.microsoft.com/Forums/en-US/6a7d9550-c282-4c00-9885-5023de0c1906/mountspcontentdatabase-with-host-named-site-collections?forum=sharepointadminEdit: One thing to consider is security. If your test environment isn't secured to the same level as your production environment (password complexity, resets, access audits/restrictions) then you shouldn't be putting production data on it.
- Edited by Alex Brassington Wednesday, April 05, 2017 8:21 AM
That was my original thought. I can copy the backup files over from our production's nightly backup to our test server and then restore the database to the test farm's SQL server.
I'm thinking that I would need to remove the original site collection and it's database before hand, then restore the backup from production, and mount the database to the web application. Once this has been done, I should be able to rename the site collection and see how this works.
My only concern was with how renaming the site collection would impact anything else within the collection, but I suppose the only way to confirm that this works would be tro try it first.
I'll report back on how this worked.
If you've only got one Site Collection per DB then it should be case of detatching the current one, mounting the new one with this powershell https://technet.microsoft.com/en-gb/library/ff607581.aspx?f=255&MSPPError=-2147217396 and that should work.
Unless you're using Host Named Site Collections then the 'tst' part is in the web application, so you wouldn't need to rename the sites at all. 'example' would move from http://portal.domain.com/sites/example to http://tst-portal.domain.com/sites/example
So restoring the backup from production to the test server works... I am finding that I have to rename the site collection after the new database is restored, otherwise I end up with the production's URL. This is a quick process and works. I'm mostly going to do this for larger collections, whose databases are 25+GB. For smaller collections, I'm going to do the Backup/Restore-SPSite method.
I've run into another issue that I am not sure how to address and I cannot seem to find any information on this. We have Workflows in production and test. I'm not sure how this is going to work with workflows. I'm guessing I will just have to republish workflows, but I've seen problems with the workflow farm and scopes becoming corrupted. The other issue is that we are using Access 2013 services and that uses a separate database server to host the databases. I'm not sure how to handle these since they all use databases with GUIDs and matching user accounts in SQL with those same GUIDs.
Everything worked out with transferring the site collections and workflows. I was able to republish them to the test farm and they worked. The only item I'll need to figure out is how the Access 2013 services will work, but that is something I can address at a later time.
Thanks for everyones imput.