Share via

Disaster Recovery

  • Article

 

Applies To: Service Bus for Windows Server 1.0

Disaster recovery is a term that refers to the failure of key system components. Such failures usually require manual intervention to restore normal operation. In the case of the Service Bus for Windows Server, disasters can manifest themselves in several ways:

  • Loss of one or more databases used by the Service Bus for Windows Server. This outage can be caused by a hardware failure, an operator error, or a datacenter-wide disaster event.

  • Loss of nodes that run the Service Bus for Windows Server.

  • Loss of both Service Bus for Windows Server nodes and databases.

This topic discusses the following disaster recovery scenarios:

  • Preparing for disaster recovery

  • Failover farm nodes (reuse existing farm certificate)

  • Failover farm nodes (issue new farm certificate)

  • Failover SQL server

  • Fail over farm and SQL server (reuse existing farm certificate)

  • Fail over farm and SQL server (issue new farm certificate)

  • Restore Service Bus farm database

  • Restore gateway database

  • Restore container database

  • Restore a Service Bus entity

Preparing for disaster recovery

The Service Bus for Windows Server stores all of its data in SQL Server databases. To enable recovery from a disaster, set up periodic backups or facilitate data redundancy solutions.

The Service Bus for Windows Server uses the following databases:

  • One Service Bus for Windows Server farm database.

  • One gateway database.

  • One or more container databases.

Of these databases, only the gateway and the container databases must be mirrored or backed up. To recreate the Service Bus for Windows Server farm database, you can follow the steps in this section. If you choose to back up the gateway and the container databases, ensure that the times at which the backups of the different databases are taken are not too far apart.

For related information about implementing high availability and disaster recovery for SQL Server, see the following links:

Failover farm nodes (reuse existing farm certificate)

The Service Bus for Windows Server farm nodes are unavailable. The SQL server remains available. To recover from a lost farm, create a new farm and attach the gateway and container databases to the new farm. No data loss occurs. To create a new farm and attach the existing gateway and container databases, do the following:

Prerequisites: existing Service Bus for Windows Server farm certificate.

  1. Install the Service Bus for Windows Server and all its prerequisites on all new farm machines by using the Web Platform Installer.

  2. Install the farm certificate of the old Service Bus for Windows Server farm.

  3. On one of the new farm nodes, run the T:Microsoft.ServiceBus.Commands.Restore-SBFarm cmdlet with the following parameters:

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.RunAsAccount: Account under which the Service Bus for Windows Server services run. This account must be the same account that you used for the old farm.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.GatewayDBConnectionString: Connection string of the existing gateway database.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that this cmdlet creates.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.FarmCertificateThumbprint: Thumbprint of the farm certificate of the old Service Bus for Windows Server farm. Find the farm thumbprint in the Service Bus for Windows Server farm database [Store].[ServiceConfig] table under the ConfigName SBEncryptionCertificateThumbprint value.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.MessageBrokerPort: Port used for message broker communication. This port must be the same port that you used for message broker communication in the old farm. If not specified, the default port is used.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.HttpsPort: Port used for HTTPS communication. This port must be the same port that you used for HTTPS communication in the old farm. If not specified, the default port is used.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.TCPPort: Port used for TCP communication. This port must be the same port that you used for TCP communication in the old farm. If not specified, the default port is used.

    The T:Microsoft.ServiceBus.Commands.Restore-SBFarm cmdlet creates a new Service Bus for Windows Server farm database. You can delete the old Service Bus for Windows Server farm database.

  4. On all new farm nodes, run the T:Microsoft.ServiceBus.Commands.Add-SBHost cmdlet with the following parameters:

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that you created in step 3.

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.RunAsPassword: SecureString that contains the password of the account under which the Service Bus for Windows Server processes run.

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.EnableFirewallRules: Set to true if the firewall rules of the host should be updated to allow for Service Bus for Windows Server data to traverse the firewall. Otherwise, false.

Failover farm nodes (issue new farm certificate)

The Service Bus for Windows Server farm nodes are unavailable. The SQL server remains available. To recover from a lost farm, create a new farm and attach the gateway and container databases to the new farm. No data loss occurs. To create a new farm and attach the existing gateway and container databases, do the following:

Prerequisites: none.

  1. Install the Service Bus for Windows Server and all its prerequisites on all new farm machines by using the Web Platform Installer.

  2. On one of the new farm nodes, run the T:Microsoft.ServiceBus.Commands.Restore-SBFarm cmdlet with the following parameters:

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.RunAsAccount: Account under which the Service Bus for Windows Server services run. This account must be the same account that you used for the old farm.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.GatewayDBConnectionString: Connection string of the existing gateway database.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that this cmdlet created.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.CertificateAutoGenerationKey: SecureString that contains the passphrase to secure the new farm certificate that this cmdlet creates.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.MessageBrokerPort: Port used for message broker communication. This port must be the same port that you used for message broker communication in the old farm. If not specified, the default port is used.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.HttpsPort: Port used for HTTPS communication. This port must be the same port that you used for HTTPS communication in the old farm. If not specified, the default port is used.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.TCPPort: Port used for TCP communication. This port must be the same port that you used for TCP communication in the old farm. If not specified, the default port is used.

    The T:Microsoft.ServiceBus.Commands.Restore-SBFarm cmdlet creates a new Service Bus for Windows Server farm database. You can delete the old Service Bus for Windows Server farm database.

  3. Run the T:Microsoft.ServiceBus.Commands.Restore-SBGateway cmdlet on one of the farm nodes with the following parameters:

    • P:Microsoft.ServiceBus.Commands.Restore-SBGateway.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that you created in step 2.

    • P:Microsoft.ServiceBus.Commands.Restore-SBGateway.GatewayDBConnectionString: Connection string of the restored gateway database.

  4. Call the T:Microsoft.ServiceBus.Commands.Update-SBHost cmdlet on all farm nodes.

  5. For each container database, call the T:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer cmdlet with the following parameters. Run this cmdlet on one of the farm machines.

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that you created in step 2.

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.ContainerDBConnectionString: Connection string of the container database.

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.Id: ID of the restored message container.

    Obtain the ID of the restored message container from the gateway database [dbo].[ContainersTable] table, which contains the IDs, connection strings, database server names, and database names of all message containers. Choose the ID of the container whose database name matches name of the original container database.

  6. On all new farm nodes, call the T:Microsoft.ServiceBus.Commands.Add-SBHost cmdlet with the following parameters.

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that you created in step 2.

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.RunAsPassword: SecureString that contains the password of the account under which the Service Bus for Windows Server processes run.

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.EnableFirewallRules: Set to true if the firewall rules of the host should be updated to allow for Service Bus for Windows Server data to traverse the firewall. Otherwise, false.

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.CertificateAutogenerationKey: SecureString that contains the passphrase to secure the new farm certificate that this cmdlet creates.

  7. All service namespace keys are encrypted with the farm certificate. Issuing a new farm certificate requires all service namespace keys to be replaced. For each namespace, call the T:Microsoft.ServiceBus.Commands.Set-SBNamespace cmdlet with the following parameters. Run this cmdlet on one of the farm machines.

    • P:Microsoft.ServiceBus.Commands.Set-SBNamespace.Name: Name of the service namespace.

    • P:Microsoft.ServiceBus.Commands.Set-SBNamespace.PrimarySymmetricKey: New service namespace key.

Failover SQL server

The SLQ server is unavailable. To recover from a lost SQL server, create a new SQL server and Service Bus for Windows Server farm, as described in the section “Failover farm and SQL server.”

Fail over farm and SQL server (reuse existing farm certificate)

The SLQ server and all farm nodes are unavailable. To recover from a lost farm and SQL server, create a new farm and a new SQL server, and attach the gateway and container databases to the new farm. To restore the Service Bus for Windows Server farm and SQL server, do the following:

Prerequisites:

  • Backups of the gateway and the container databases.

  • Existing Service Bus for Windows Server farm certificate.

  1. Set up and configure a new SQL server.

  2. Restore the gateway and container databases from the backup copies using the SQL Restore capabilities as described in Restore a Database Backup (SQL Server Management Studio).

  3. Install the Service Bus for Windows Server and all its prerequisites on new farm machines by using the Web Platform Installer.

  4. Install the farm certificate of the old Service Bus for Windows Server farm.

  5. On one of the new farm nodes, call the T:Microsoft.ServiceBus.Commands.Restore-SBFarm cmdlet with the following parameters:

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.RunAsAccount: Account under which the Service Bus for Windows Server services run. This account must be the same account that you used for the old farm.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.GatewayDBConnectionString: Connection string of the existing gateway database.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that this cmdlet creates.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.FarmCertificateThumbprint: Thumbprint of the farm certificate of the old Service Bus for Windows Server farm. Find the farm thumbprint in the Service Bus for Windows Server farm database [Store].[ServiceConfig] table under the ConfigName SBEncryptionCertificateThumbprint value.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.MessageBrokerPort: Port used for message broker communication. This port must be the same port that you used for message broker communication in the old farm. If not specified, the default port is used.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.HttpsPort: Port used for HTTPS communication. This port must be the same port that you used for HTTPS communication in the old farm. If not specified, the default port is used.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.TCPPort: Port used for TCP communication. This port must be the same port that you used for TCP communication in the old farm. If not specified, the default port is used.

    The T:Microsoft.ServiceBus.Commands.Restore-SBFarm cmdlet creates a new Service Bus for Windows Server farm database. You can delete the old Service Bus for Windows Server farm database.

  6. Call the T:Microsoft.ServiceBus.Commands.Restore-SBGateway cmdlet on one of the farm nodes with the following parameters:

    • P:Microsoft.ServiceBus.Commands.Restore-SBGateway.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that you created in step 5.

    • P:Microsoft.ServiceBus.Commands.Restore-SBGateway.GatewayDBConnectionString: Connection string of the restored gateway database.

  7. Call the T:Microsoft.ServiceBus.Commands.Update-SBHost cmdlet on all farm nodes.

  8. For each container database, call the T:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer cmdlet with the following parameters. Run this cmdlet on one of the farm machines.

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that you created in step 5.

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.ContainerDBConnectionString: Connection string of the container database.

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.Id: ID of the restored message container.

    Obtain the ID of the restored message container from the gateway database [dbo].[ContainersTable] table, which contains the IDs, connection strings, database server names, and database names of all message containers. Choose the ID of the container whose database name matches the name of the original container database.

  9. On all new farm nodes, call the T:Microsoft.ServiceBus.Commands.Add-SBHost cmdlet with the following parameter:

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that you created in step 5.

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.RunAsPassword: SecureString that contains the password of the account under which the Service Bus for Windows Server processes run.

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.EnableFirewallRules: Set to true if the firewall rules of the host should be updated to allow for Service Bus for Windows Server data to traverse the firewall. Otherwise, false.

Fail over farm and SQL server (issue new farm certificate)

The SLQ server and all farm nodes are unavailable. To recover from a lost farm and SQL server, create a new farm and new SQL server, and attach the gateway and container databases to the new farm. To restore the Service Bus for Windows Server farm and SQL server, do the following:

Prerequisites:

  • Backups of the gateway and the container databases.

  1. Set up and configure a new SQL server.

  2. Restore the gateway and container databases from the backup copies using the SQL Restore capabilities as described in Restore a Database Backup (SQL Server Management Studio).

  3. Install the Service Bus for Windows Server and all its prerequisites on new farm machines by using the Web Platform Installer.

  4. On one of the new farm nodes, call the T:Microsoft.ServiceBus.Commands.Restore-SBFarm cmdlet with the following parameters:

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.GatewayDBConnectionString: Connection string of the existing gateway database.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that this cmdlet creates.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.CertificateAutoGenerationKey: SecureString that contains the passphrase to secure the new farm certificate that this cmdlet creates.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.MessageBrokerPort: Port used for message broker communication. This port must be the same port that you used for message broker communication in the old farm. If not specified, the default port is used.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.HttpsPort: Port used for HTTPS communication. This port must be the same port that you used for HTTPS communication in the old farm. If not specified, the default port is used.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.TCPPort: Port used for TCP communication. This port must be the same port that you used for TCP communication in the old farm. If not specified, the default port is used.

    The T:Microsoft.ServiceBus.Commands.Restore-SBFarm cmdlet creates a new Service Bus for Windows Server farm database. You can delete the old Service Bus for Windows Server farm database.

  5. Call the T:Microsoft.ServiceBus.Commands.Restore-SBGateway cmdlet on one of the farm nodes with the following parameters:

    • P:Microsoft.ServiceBus.Commands.Restore-SBGateway.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that you created in step 4.

    • P:Microsoft.ServiceBus.Commands.Restore-SBGateway.GatewayDBConnectionString: Connection string of the restored gateway database.

  6. Call the T:Microsoft.ServiceBus.Commands.Update-SBHost cmdlet on all farm nodes.

  7. For each container database, call the T:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer cmdlet with the following parameters. Run this cmdlet on one of the farm machines.

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that you created in step 4.

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.ContainerDBConnectionString: Connection string of the container database.

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.Id: ID of the restored message container.

    Obtain the ID of the restored message container from the gateway database [dbo].[ContainersTable] table, which contains the IDs, connection strings, database server names, and database names of all message containers. Choose the ID of the container whose database name matches the name of the original container database.

  8. On all new farm nodes, call the T:Microsoft.ServiceBus.Commands.Add-SBHost cmdlet with the following parameter:

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.SBFarmDBConnectionString: Connection string of the Service Bus for Windows Server farm database that you created in step 4.

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.RunAsPassword: SecureString that contains the password of the account under which the Service Bus for Windows Server processes run.

    • P:Microsoft.ServiceBus.Commands.Add-SBHost.EnableFirewallRules: Set to true if the firewall rules of the host should be updated to allow for Service Bus for Windows Server data to traverse the firewall. Otherwise, false.

    • P:Microsoft.ServiceBus.Commands.Restore-SBFarm.CertificateAutoGenerationKey: SecureString that contains the passphrase to secure the new farm certificate that this cmdlet creates.

  9. All service namespace keys are encrypted with the farm certificate. Issuing a new farm certificate requires all service namespace keys to be replaced. For each namespace, call the T:Microsoft.ServiceBus.Commands.Set-SBNamespace cmdlet with the following parameters. Run this cmdlet on one of the farm machines.

    • P:Microsoft.ServiceBus.Commands.Set-SBNamespace.Name: Name of the service namespace.

    • P:Microsoft.ServiceBus.Commands.Set-SBNamespace.PrimarySymmetricKey: New service namespace key.

Restore Service Bus farm database

The Service Bus for Windows Server farm database is corrupted or lost. To recover from a lost Service Bus for Windows Server farm database, re-create the farm as described in the section “Fail over farm (reuse existing farm certificate).”

Restore gateway database

The Service Bus for Windows Server gateway database is corrupted or lost.

This cmdlet tries to connect to all container databases. Any container whose database cannot be reached is marked as faulty in the gateway database. To enable a faulted container, run the T:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer cmdlet for the faulted container.

Prerequisites:

  • A backup of the gateway database.

  1. Restore the gateway and container databases from the backup copy using the SQL Restore capabilities as described in Restore a Database Backup (SQL Server Management Studio).

  2. Call the T:Microsoft.ServiceBus.Commands.Stop-SBHost cmdlet on all farm nodes.

  3. Call the T:Microsoft.ServiceBus.Commands.Restore-SBGateway cmdlet on one of the farm nodes with the following parameter:

    • P:Microsoft.ServiceBus.Commands.Restore-SBGateway.GatewayDBConnectionString: Connection string of the restored gateway database.

  4. Call the T:Microsoft.ServiceBus.Commands.Update-SBHost cmdlet on all farm nodes.

  5. Call the T:Microsoft.ServiceBus.Commands.Get-SBMessageContainer cmdlet on one of the farm nodes. Note if there any message containers that have a Faulted status.

  6. For each message container whose status is Faulted, call the T:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer cmdlet on one of the farm nodes with the following parameters:

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.ContainerDBConnectionString: Connection string of the container database.

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.Id: ID of the message container.

  7. Call the T:Microsoft.ServiceBus.Commands.Start-SBHost cmdlet on all farm nodes.

Restore container database

One or more Service Bus for Windows Server container databases are corrupted or lost. To restore the lost container databases, do the following.

Prerequisites:

  • Backups of each of the lost container databases.

  1. Restore all lost container databases from the backup copies using the SQL Restore capabilities as described in Restore a Database Backup (SQL Server Management Studio).

  2. For each lost container database, call the T:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer cmdlet with the following parameters. Run this cmdlet on one of the farm machines.

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.ContainerDBConnectionString: Connection string of the restored container database.

    • P:Microsoft.ServiceBus.Commands.Restore-SBMessageContainer.Id: ID of the restored message container.

    Obtain the ID of the restored message container by calling the T:Microsoft.ServiceBus.Commands.Get-SBMessageContainer cmdlet on one of the farm nodes. This cmdlet returns the IDs, connection strings, database server names, and database names of all message containers. Choose the ID of the container whose database name matches the name of the original container database.

  3. Call the T:Microsoft.ServiceBus.Commands.Stop-SBHost cmdlet on all farm nodes.

  4. Call the T:Microsoft.ServiceBus.Commands.Start-SBHost cmdlet on all farm nodes.

Restore a Service Bus entity

A Service Bus queue or topic was deleted. To restore a lost entity, do the following. The entity is restored in one of the current container databases.

Prerequisites:

  • Backups of the gateway database and all of the container databases.

  1. Restore all container databases using the SQL Restore capabilities as described in Restore a Database Backup (SQL Server Management Studio). Restore the container databases into temporary databases. Do not overwrite the current container databases.

  2. Restore the gateway database using the SQL Restore capabilities as described in Restore a Database Backup (SQL Server Management Studio). Restore the gateway database into a temporary database. Do not overwrite the current gateway database.

  3. Call the T:Microsoft.ServiceBus.Commands.Restore-SBEntity cmdlet on one of the farm nodes with the following parameters:

    • P:Microsoft.ServiceBus.Commands.Restore-SBEntity.EntityPath: URI of the entity to restore.

    • P:Microsoft.ServiceBus.Commands.Restore-SBEntity.SourceGatewayConnectionString: Connection string of the restored temporary gateway database.

    • P:Microsoft.ServiceBus.Commands.Restore-SBEntity.SourceMessageContainersConnectionStrings: List of connection strings of the restored temporary container databases.

  4. Call the T:Microsoft.ServiceBus.Commands.Stop-SBHost cmdlet on all farm nodes.

  5. Call the T:Microsoft.ServiceBus.Commands.Start-SBHost cmdlet on all farm nodes.

  6. Delete the temporary gateway and container databases.