Plan the backup and restore strategy (FAST Search Server 2010 for SharePoint)
Applies to: FAST Search Server 2010
Use this article to select the backup type that best suits your requirements, and to plan the backup and restore strategy for FAST Search Server 2010 for SharePoint.
Important
Always test and verify your backup and restore procedures before you implement a new backup and restore procedure in a production system, and before you put a system into production.
For an overview of the different FAST Search Server 2010 for SharePoint backup and restore options, see Backup and restore (FAST Search Server 2010 for SharePoint).
You should combine the FAST Search Server 2010 for SharePoint backup with a Microsoft SharePoint Server backup. For information about SharePoint Server 2010 backup and recovery, see Backup and recovery for SharePoint Server 2010.
In this section:
Plan where you want to store the backup data
General considerations when planning the backup and restore strategy
Considerations for configuration backup and restore
Considerations for full backup and restore
Downtime considerations when planning the restore strategy
Run scripts with a saved password
Plan where you want to store the backup data
All backup scenarios require a backup store. The backup store is a location where the backup data is stored, and it should be an external data resource separate from the FAST Search Server 2010 for SharePoint farm. The backup store must be available as a UNC path, such as \\contoso\FASTSearchBackup, so that all servers can reach it. The user who runs the backup and restore scripts must have read and write access to this path.
Note
Access control lists (ACLs) are not preserved on the files that are stored in the backup stores. To prevent unauthorized users from reading indexed data, protect the backup store with an appropriate ACL.
For a full backup you can use multiple backup stores. The FAST Search Server 2010 for SharePoint backup script will try to balance how much data is stored in the different backup stores by assigning an even number of servers to each backup store.
To save bandwidth and time, you can re-use the backup store when you run a new backup. The full backup and restore runs the Robocopy command in incremental mode to transfer data. When you overwrite an existing backup, Robocopy only replaces the files that have been modified since the previous backup.
Important
Always make sure that you have a safe copy of the backup store before you run another backup to the same backup store. If the backup procedure fails while you run the new backup, the backup store might be corrupted.
When there are multiple servers in the FAST Search Server 2010 for SharePoint deployment, and multiple backup stores are specified in the –backuppath parameter, the system searches the content of all the backup stores to determine whether there is a backup for all servers in the backup stores. If all servers have an existing backup, and you have specified the –force parameter, the scripts will update the existing backups.
General considerations when planning the backup and restore strategy
You cannot use the backup and restore scripts to back up or restore individual servers in a multiple server deployment.
The certificates that authenticate FAST Search Server 2010 for SharePoint to Microsoft SharePoint Server are not included by the FAST Search Server 2010 for SharePoint backup and restore scripts. If the certificates have changed, for example if you restore on a reinstalled system, you must restore the certificates separately. See Restore a certificate.
The administration database backup file is generated locally on the SQL Server, and is not stored with the backup of FAST Search Server 2010 for SharePoint. To maintain a complete backup file set, you should copy the administration database backup to the backup store after you have run the backup script.
The FAST Search Server 2010 for SharePoint backup is sensitive to version differences between the backed up SQL Server and the restored SQL Server. The versions must be identical. If the SQL version changes between backup and restore, export the FAST Search Server 2010 for SharePoint administration database to a canonical format and import it.
Note
Backup procedures may interfere with the spell tuning process. To avoid this problem, schedule regular backups and spell tuning runs so that they do not interfere with one another. By default, the spell tuner is scheduled to run at 2:05 AM.
Considerations for configuration backup and restore
The configuration backup is not deployment-aware, and you can restore a configuration backup to a different set of servers from the servers where you made the backup.
Only configuration files that are not generated by the FAST Search Server 2010 for SharePoint installer are backed up. If you migrate the configuration to a different system, the content of the directory <FASTSearchFolder>\etc\config_data\deployment on the restored system is not modified, and the server-specific configuration from the installation is not overwritten.
The user inclusion and exclusion lists for company, location and person name property extraction, and the dictionaries of the custom properties extractors, are stored in the resource store and are not included in a configuration backup.
Considerations for full backup and restore
A full backup can only be restored to exactly the same set of servers as it was backed up from, and the farm topology cannot be changed between the backup and the restore operation. The number of servers must be the same, the server names must be the same, and the roles that the installer assigns to the servers must be the same.
For each server, the backup script stores a copy of the file system, except for the executable binaries and DLLs.
A full backup may require a large amount of storage space. The backup data volume will be equal to the sum of all installation folders on all servers. To help reduce disk space requirements, you can exclude the searchable index from the backup. If you exclude the searchable index from the backup, you can reconstruct it after a restore by using the backed up FIXML. This method saves time and space during backup because less data is transferred. The disadvantage is that it takes longer to get a restored system up and running, because the indexer must rebuild the searchable index from the FIXML files.
During a full backup, feeding and indexing will stop. The system will serve queries but no new items will become available in the index during the backup process. During a full restore, the complete FAST Search Server 2010 for SharePoint farm must be shut down.
Downtime considerations when planning the restore strategy
The downtime required to complete a system restore depends on the complexity of the deployment, how much data you have in the system, and whether the searchable index was included in the backup, or not. The targeted Recovery Time Objective (RTO), which is described in Plan for backup and recovery in SharePoint Server 2010, should influence your backup and restore strategy for FAST Search Server 2010 for SharePoint.
Use the following table to find the restore procedure that best matches your downtime requirements.
| Acceptable downtime | Backup and restore strategy |
|---|---|
No downtime accepted |
Use a fully or partly redundant setup of FAST Search Server 2010 for SharePoint to always have service available while you restore the farm. For redundancy recommendations, see Search redundancy and availability. |
One to several days of downtime accepted |
Use a full backup or a third-party backup solution to restore both configuration and data to the existing farm. |
Days to weeks of downtime accepted |
Install FAST Search Server 2010 for SharePoint on the same set of servers, restore the configuration from a valid configuration backup, and refeed the content. |
Run scripts with a saved password
The backup and restore scripts forward their credentials to the remote servers so that the scripts can authenticate themselves to remote resources. The scripts prompt for credentials to perform the authentication, and an administrator must be present to enter the credentials.
To run the scripts without the administrator having to enter passwords at a prompt, you can specify a saved password file. This password must be DPAPI (Windows Data Protection API) protected.
To generate a password file
Open a Windows PowerShell prompt as an administrator and run the following command:
$mypw = Read-Host -AsSecureStringEnter your password when you are prompted.
Enter the command:
Set-Content passwordfile (ConvertFrom-SecureString $mypw)
You can now run the backup and restore scripts with the –passwordfile parameter.
Note
The file that contains the password is encrypted by DPAPI, and you should protect it with a strong ACL.
Warning
If the password of the user who runs the backup and restore scripts is changed, you must update and regenerate the password file.
See Also
Concepts
Backup and restore prerequisites (FAST Search Server 2010 for SharePoint)
Configuration backup and restore (FAST Search Server 2010 for SharePoint)
Full backup and restore (FAST Search Server 2010 for SharePoint)
About backup and restore scripts (FAST Search Server 2010 for SharePoint)