As with any development environment, it’s best to work with a product that is as close to live as possible. In SharePoint, it’s no different. You want to development on a system as close to the same as production as you can, so it’s necessary to “refresh” your development system as often as possible. There may be better ways to do this (SQL Mirroring) but this works quite well for myself. Please feel free to add your opinion and let me know if there’s a better way of accomplishing this.
To “refresh” a Development SharePoint server with a backup from the Production SharePoint 2010 Site
This guide assumes you have the following prerequisites:
- You have already deployed a Development Server and it is up and running, most likely with out of date content. This guide does not cover creating a Development Server, but here is a guide on how to do so.
- Both installs (Development and Production servers) are running the same version of SharePoint. To see the version number your SharePoint system is on, use the following Powershell Command:
get-spfarm | select BuildVersion BuildVersion ------------ 14.0.5050.5001
This process will not work if they are not on the exact same version.
- I have been told that it’s not a great idea to use snapshots when dealing with a virtualized SharePoint environment. Do what you can to make sure your data is backed up, but be weary of a snapshot as your only form of backup. See here for more info
You have made a snapshot or backup of both SharePoint Servers and their related SQL servers. If you’re running a virtualized environment, this should be fairly straight forward. Create a snapshot of each server in case something goes wrong. If you’re running a hardware setup, be sure to backup your system to an image file or use whatever your preferred backup software in case something doesn’t work out correctly.
- Any deployed “Farm Solutions” (WSPs) must be deployed on both systems. This process of backup and restore do not effect the Central Administration sites of either machine. Farm Solutions must be deployed manually on both machines or you risk breaking the site.
- You will need your Development Server SQL instance and database names. In my environment, I run a two-server farm for the production site and a single-server farm for the development system. This is fine, but you will need to know the instance name and database name of your SQL system in order for the backup to point to the proper database during the restore process.
- You will need to be able to log in with a user who has permission to write to the SQL server on the Development System. The restore writes data to the SQL server hosting the Development Site, so it makes sense that you will need admin access to it.
- Log in to the production server that hosts your live SharePoint site
- Open up SharePoint 2010 Management Shell (Powershell, but it’s important to use the SharePoint Powershell that is installed with SharePoint)
- We will be using the Backup-SPSite command with your own parameters. I’ll show you what I used and but you will want to customize it with your own environment.
The code below shows most of the parameters for the Backup-SPSite command. I’ll explain what they do and then show you my example for my environment.
Backup-SPSite -Identity SiteCollectionURLHere -Path BackupFilePathHere [-Force] [-NoSiteLock] [-UseSqlSnapshot] [-Verbose]
-Forceparameter simply allows you to overwrite an existing backup if found.
-NoSiteLockparameter prevents the site from going into “Read Only” mode while backing the system up if there are users actively working on the site while you are creating this backup.
-UseSqlSnapshotparameter specifies a SQL Database Snapshot will be created when the backup begins, and all site collection data will be retrieved directly from the database snapshot. This snapshot will be deleted automatically when the backup completes. The UseSqlSnapshot parameter is recommended if the database server hosting your content database supports database snapshots such as SQL Server Enterprise Edition and SQL Server Developer Edition. This is because it will ensure a valid backup while allowing users to continue reading and writing to the site collection during the backup. It is not necessary to specify the NoSiteLock parameter when specifying the UseSqlSnapshot parameter.
Here’s what I used:
Backup-SPSite -Identity http://sptest -Path C:\\Backup\bak1 [-Force]
Now that you have your file backed up, you can move it over to your Dev machine or just point to it if you have it set up on a network location.
- Our options using the Restore-SPSite PowerShell command to restore are shown below.
Restore-SPSite -Identity SiteCollectionURLHere -Path BackupFilePathHere [-DatabaseServer DatabaseServerNameHere] [-DatabaseName ContentDatabaseNameHere] [-Force] [-GradualDelete] [-Verbose]
Here is the breakdown of what each parameter does:
-DatabaseServer: This is the name of the computer where you are hosting the MSSQL Database. For me it’s the name of the local machine I’m working on because my Dev Server hosts its own MSSQL Database so I will be using
-DatabaseName: This is the name of the database itself. In my case, my Database name is the standard
-Force: Will force the backup to overwrite an existing SPSite. I will be using this parameter because I need it to overwrite my current testing environment.
-GradualDelete: Specifies that the site collection being overwritten with the
-Forceparameter should be gradually deleted over time by a timer job instead of all at once, which reduces its impact on SharePoint 2010 Products and SQL Server performance. This option is recommended for large site collections.
- Ok, now that we know our restore options, you can see my a screenshot of what I typed into SharePoint Management Shell.
- It will then ask you if you are sure you want to perform this action. I select the default of Yes and let it run. When it finishes you should have your test site updated.
I did have an issue the first time I refreshed my development server. For some reason the User Profiles service was not started. To fix it, I had to stop and then re-start the service. I haven’t had this happen since, but I figured it would be worth mentioning. Let me know if you have a better way of performing this!