In this article, we will address mainly the PowerShell approach, showing that this is the most complete and flexible approach when it comes to restore operations. All the PowerShell restore operations address well the flexible granularity of SharePoint 2010 restores, allowing farm-level, web/service application-level, and site collection/list/library-level restores. However, we will also explore how the SQL Server tools can be used to back up and restore content databases.
But first things first: let’s start with the initial configuration settings for restoring.
Initial Restore Configuration
First, what you need to do is start the SharePoint Foundation Administration Service on all farm servers. This is done through the Microsoft Management Console and the Services snap-in (services.msc).
The Administration Service is vital when it comes to running a SharePoint 2010 environment. It is required for creating and deleting web applications, as well as starting or stopping SharePoint-related services. It must be run on all servers of a SharePoint farm. If it does not run, any operations that deal with backing up and restoring (no matter which granularity level you are working with) might fail either entirely or at least partially.
As a consequence, for troubleshooting failed restore operations, it is usually a good idea to check whether the SharePoint Foundation Administration Service is running on each and every server of the farm. Often enough it is also a good idea to check whether the account running this service is part of the local administrators group. This is an absolute requirement for the service to run correctly.
The following general rules summarize the possibilities of what can and what cannot be restored with SharePoint 2010:
Config and content dattabases cannot be restored with SP2010 utilities.
After a restore with the SP2010 utilities, service applications must be restarted using either Central Administration or PowerShell.
When restoring/reattaching databases, it is best to choose the OVERWRITE option (this will keep the database IDs; hence, database change logs can continue to be used).
BLOB stores can be restored using SharePoint only if FILESTREAM is the blob provider.
Restoring an Entire Farm
There are a number of common scenarios when you might want to restore your entire farm environment to an earlier point in time.
The seldom occurring case is a disaster case, such as severe hardware failure (usually the disks) but also natural disasters, such as floods, fires, and so on. In such a case you might have to restore your SharePoint environment as soon as possible in order to regain your business’s operability. Also, if you want to restore your configuration data to a previous point in time, it is good practice to restore your entire farm environment. Third, if you plan to move to another farm topology, you will have to perform a farm restore. But be aware that a farm restore is not possible from single to multifarm, and vice versa, and it is also not possible between different versions of SharePoint 2010 (for example, switching from SharePoint Server 2010 Standard to the Enterprise edition).
A very straightforward mechanism to restore an entire farm is using PowerShell. The cmdlet Restore-SPFarm permits you to restore an entire farm, specifying nothing but the directory where the backup files are located and the restore method.
1
Restore-SPFarm –Directory "path" –RestoreMethod Overwrite [-BackupId "guid"]
Omitting the optional –BackupId parameter will cause the most recent backup to be taken. If, on the other hand, you would like to restore a specific backup, it is a very good idea if you knew which one to restore. Also for this task, PowerShell brings the proper out-of-the-box support using a dedicated cmdlet, which is called Get-SPBackupHistory.
1
Get-SPBackupHistory -Directory "path"
The previous cmdlet will output a list of all available backups within the specified directory.
Once you are done with the restore of your farm environment, it is an absolute necessity to restart the service applications. As mentioned, please do not use the Products Configuration Wizard, since this would not only restart the services but also reprovision them and therefore overwrite all custom settings for those service applications.
You have two ways of restarting the service applications in a safe manne: one is to manually click Stop in Central Administration for each of the services running on the server and then click Start. Note that some services (such as the User Profile Synchronization service) can take several minutes to start.
A more elegant way of restarting all the services is the PowerShell approach, where you can restart them using only two commands, involving just three different cmdlets. Get-SPServiceInstance retrieves a list of all the provisioned services. Using PowerShell’s piping feature, it is easy to stop all of them by issuing just one command:
1
Get-SPServiceInstance Stop-SPServiceInstance
Afterward, you can restart the services by using the following command:
1
Get-SPServiceInstance Start-SPServiceInstance
This looks straightforward, and it is usually also done within a few minutes, but there is one important thing to keep in mind: between the stopping and restarting of the services, your SharePoint environment is completely down. Even Central Administration will not be accessible.
Restore Using the SQL Server Tools
You do also have the possibility to restore a farm (better: its contents) using the SQL Server tools, namely, the SQL Server Management Studio (SSMS), respectively its Express variant. With this management tool, you can easily expand the Databases node, select the content database you would like, right-click it, and perform backup and restore tasks (All tasks Backup resp. Restore).
Using SSMS, you can easily perform a backup and restore on database levels. However, there are a few limitations to this approach:
You cannot restore the SharePoint 2010 configuration data.
You cannot restore SharePoint 2010 search.
There are a number of scenarios when adopting SSMS for a restore is considered a good practice:
Restoring the most recent full DB backup
Restoring the most recent differential DB backup
Restoring transaction log backups
After performing the actual backup and/or restore, you need to carry out a number of tasks; since SSMS is not capable of restoring configuration data, you need to restore this manually (ideally using PowerShell) and then restart all the services in order to ensure that the configuration data is used.
Restore the configuration database using Central Administration or PowerShell (PS: Restore-SPFarm -ConfigurationOnly).
Restart SharePoint Services Timer Services.
Restart the service applications (see the earlier section on how to restart all services).
Using SSMS is usually a quick means of reestablishing a previous content database state without a lot of effort. The only things to keep in mind are the post-restore actions mentioned earlier.
Backing Up and Restoring Configuration Settings on Another Farm
There are situations where you might want to back up your farm environment and rebuild it on another environment, such as when creating a test farm from an existing production farm. In such a case, you do not necessarily need the content databases. This makes backing up and restoring it a lot easier, since you need to copy and restore a lot fewer databases.
What you need to bear in mind for the mentioned scenario is that you must copy and restore the configuration settings for the following elements:
The farm
Web applications
Service applications
On the web application level, it is a good starting point to obtain a list of all the web applications and their content databases. The following command will output such a list:
1
Get-SPWebApplication %{$_.Name;$_.Url;%{$_.ContentDatabases%{$_.Name}; Write-Host “” }}
This way, you can further filter using WHERE for specific web applications. However, when reproducing a production environment on test, the usual case is that you want to have all your web applications present also on the test environment.
The next step consists of detaching all content databases from their web applications. Please schedule downtimes thoroughly beforehand, since this will stop all web applications from working properly. The following command will disconnect all content databases from their corresponding web applications so you can back up only their configuration settings.
1
Get-SPContentDatabase Dismount-ContentDatabases
This was already the tough part of saving configuration settings. With the known Backup-SPFarm cmdlet, you can simply back up the whole farm, not including the content databases.
1
Backup-SPFarm –Directory "path" -BackupMethod "Full Differential"
After backing up to the specified directory, it is about time you reattach the content databases to their respective web applications. For this purpose, you can reuse the list obtained using Get-SPWebApplication, combining web application names with their corresponding content databases.
The Mount-SPContentDatabase cmdlet, which takes the name of the content database as well as the respective web applications as parameters, performs this task.
1
Mount-SPContentDatabase –Name "WSS_Content" -WebApplication "URL"
So far, so good. Up to now, you carried out all tasks only on the base (production) machine, where you prepared all the backup of the configuration settings. It’s time to move on to the test environment.
You can make the backup files accessible to the test system either by using a share (recommended) or by copying the backup files to your new test system. Obviously, the latter approach is more time-consuming.
On the test system, you need to issue the already known Restore-SPFarm cmdlet, with one exception: this time, you will have to append the -ConfigurationOnly flag, which will tell the cmdlet that you are trying to restore only the configuration data settings, not the content databases. Issue the command as follows:
1
Restore-SPFarm –Directory "path" -RestoreMethod Overwrite -ConfigurationOnly
Using the same cmdlet, adding the parameter -Item, you can restore a single web or service application’s configuration settings. The same is valid also for restoring search applications and the Secure Store service (which is not possible using the SSMS restore approach).
1
Restore-SPFarm –Directory
However, additional tasks are required in order to fully restore the Secure Store service (SSS). If you do not perform these tasks, expect the SSS and all other service applications that depend on it to fail with corresponding exceptions, stating a problem with the used key.
The solution to this is quite simple: you have to update the SSS key, specifying the passphrase that you should have saved (or memorized) during the provisioning of the Secure Store service. This can be done using the Update-SPSecureStoreApplicationServerKey cmdlet:
1
Update-SPSecureStoreApplicationServerKey –Passphrase
PowerShell can also restore content databases; as a matter of fact, it is the only way of restoring read-only databases. Please note that restoring read-only databases will make them read-write automatically. Here is the command for the task:
1
Mount-SPContentDatabase –Name
Restoring Site Collections, Lists, and Libraries
Similar to the backup, the restore functionality of SharePoint 2010 offers a lot of granularity. Top-down, you can restore from the farm level through the web/service application level to the single list/document library/site collection level. Instead of Restore-SPFarm, Restore-SPSite is used for restoring site collection.
If your site collection exceeds 1GB in size, it is generally considered good practice to use the -GradualDelete parameter, which will greatly reduce the workload imposed by this operation.
1
Restore-SPSite –Identity "SiteCollection URL" -Path "path" [-DatabaseServer "server"] [-DatabaseName "database"] [-GradualDelete]
Restore-SPSite allows you also to change the database for an existing site collection and even the database server. This operation is supported only when performing a restore using PowerShell.Similarly, you can restore lists and libraries, using the Import-SPWeb cmdlet. The only two parameters that you need to specify are the name of the site where to restore your list/library and the path where the file resides. It’s as simple as that.
1
Import-SPWeb –Identity "URL" -Path "path"
Both tasks can be carried out also using Central Administration, specifically under Backup and Restore Farm Backup and Restore Restore a farm.
Conclusion
SharePoint 2010 offers a great level of flexibility and granularity when it comes to backing up and restoring whole farms or just single lists. This flexibility is once more underlined by the different methods that you can adopt for performing restores: Central Administration, PowerShell, or the SQL Server tools.
Although the first approach is certainly the easiest, especially for SharePoint 2010 beginners, you will probably soon recognize the benefits from adopting PowerShell. All restore operations can be performed also by using PowerShell, often offering additional functionality (such as changing the database and database server when restoring site collections). Plus, PowerShell offers the ability to automate many tasks, for example restarting all services at once, which is functionality missing in Central Administration. So, for daily use, the higher initial effort to learn the PowerShell approach soon pays off by offering automation and additional functionality.
The SQL Server tools approach is certainly not the most complete, but for performing quick restores of content databases, it can be the tool of choice. Usually, it is best to choose your tools according to your needs as a SharePoint 2010 administrator.
This concludes this second part of the mini-series about backing up and restoring SharePoint 2010 environments, focusing on PowerShell and different granularity. I hope you’ve enjoyed the ride and learned something you didn’t know before. Feel free to leave comments if you have questions or suggestions.
No comments:
Post a Comment