Disaster recovery

Overview

This article describes the disaster recovery (DR) strategy and recovery procedures for a Turbo360 private hosting instance. It covers recovery objectives, geo-redundant backup configuration, SQL geo-restore, and the steps to restore Turbo360 operations in a secondary Azure region after a primary region failure.

Business value

A documented disaster recovery plan reduces recovery time when a regional Azure outage affects your Turbo360 instance. Knowing which recovery steps to execute — and having the required backup configurations in place before a failure occurs — is the difference between a measured recovery within hours and an open-ended outage while steps are improvised under pressure.

Prerequisites

• A completed Turbo360 private deployment (see Deployment)
• Geo-redundant SQL backup storage configured (GRS or RA-GRS backup storage option on the SQL Server)
• GRS or GZRS redundancy configured on the Storage Account
• Contributor access to an Azure subscription in the target secondary region
• A service principal with the required deployment roles available for the secondary region

Required permissions

Dependencies

• Geo-redundant SQL backup storage must be configured before a regional failure occurs. It cannot be enabled retroactively after data loss.
• GRS or GZRS Storage Account redundancy must be configured before a regional failure.
• A Recovery Services Vault in the secondary region is required if long-term SQL backup retention is used for DR.

How it works

Turbo360 private hosting does not include an automated failover mechanism. Disaster recovery is a manual process that involves:

1. Restoring the SQL database to a new SQL Server in the secondary region using geo-redundant backups
2. Redeploying App Service resources (Web App and Function Apps) in the secondary region using the Turbo360 installer or by cloning the existing App Service configuration
3. Updating connection strings to point to the restored SQL database and the Storage Account failover endpoint
4. Validating the recovered instance

Recovery time objective (RTO) and recovery point objective (RPO) depend on the backup configuration:

Steps

Prepare for disaster recovery (before a failure)

Complete these steps during normal operations to ensure recovery is possible when needed.

Configure geo-redundant SQL backup storage

1. In the Azure portal, navigate to the SQL Server (not the database).
2. Select Backups under Data management.
3. Select the Retention policies tab.
4. Under Backup storage redundancy, select Geo-redundant backup storage.
5. Click Save.

Configure Storage Account redundancy

1. Navigate to the Storage Account in the Turbo360 resource group.
2. Select Redundancy under Data management.
3. Set redundancy to GRS or GZRS.
4. Click Save.

Document connection strings and App Service configuration

Export the current App Service configuration (see Backup & recovery) and store it in a location accessible from the secondary region — for example, a geo-redundant storage account or a key vault with geo-replication enabled.

Recover Turbo360 in a secondary region (after a failure)

Use the following steps after confirming that the primary region is unavailable and a regional failover is required.

Step 1 — Geo-restore the SQL database

Recovering the SQL database to a secondary region restores the Turbo360 configuration, monitoring data, and cost data as of the last available backup.

1. In the Azure portal, navigate to SQL databases and click + Create.
2. Under Data source, select Backup.
3. Select Geo-redundant backup as the backup type.
4. Choose the Turbo360 SQL database from the available geo-redundant backups.
5. Select the target secondary region and a new SQL Server in that region (or create one).
6. Complete the restore. The operation typically takes 10–60 minutes depending on database size.
7. Once the restore completes, note the new SQL Server FQDN and database name.

Step 2 — Fail over the Storage Account (if GRS is configured)

1. In the Azure portal, navigate to the Storage Account.
2. Under Data management, select Redundancy.
3. Click Prepare for failover and confirm. The failover converts the secondary region copy to the new primary.

Step 3 — Deploy App Service resources in the secondary region

Deploy the Turbo360 Web App and Function Apps in the secondary region using the Turbo360 installer. Use the Use pre-existing resources option if you have pre-provisioned the App Service Plan in the secondary region.

1. Run the Turbo360 installer and select the secondary region.
2. Point the installer to the restored SQL database by supplying the new SQL Server FQDN and database name.
3. Point the installer to the failed-over Storage Account endpoint.
4. Complete the deployment.

If the installer is not available, contact Turbo360 support to redeploy using the existing configuration export.

Step 4 — Validate the recovered instance

1. Access the Turbo360 portal at the new Web App URL.
2. Navigate to Platform Administration > Infrastructure & Maintenance > Environment health and confirm all components show healthy status.
3. Verify that monitored resources, Business Applications, and Cost Analyzer data are visible.
4. Confirm alert channels are operational by sending a test notification.

Step 5 — Update DNS (if a custom domain is in use)

If your organisation accesses Turbo360 via a custom domain, update the DNS record to point to the new Web App URL in the secondary region.

Example scenario

A regional Azure outage in West Europe takes down the Turbo360 instance. The platform engineer confirms the outage is regional via the Azure service health dashboard. They initiate a SQL geo-restore to North Europe, creating a new SQL Server and database from the most recent geo-redundant backup (RPO: 45 minutes). They fail over the Storage Account to North Europe, run the Turbo360 installer in North Europe pointing to the restored database and storage, and validate the recovered instance within 2 hours of the outage start. They update the internal DNS record to redirect users to the North Europe Web App URL.

Limitations

• Disaster recovery requires manual execution. There is no automated failover mechanism built into Turbo360 private hosting.
• SQL geo-restore creates a new database. Transactions committed after the last log backup (up to 1 hour) are lost. This is the inherent RPO of the automatic backup mechanism.
• Storage Account failover is irreversible. After failover, geo-redundancy must be reconfigured manually.
• App Service resources in the secondary region must be redeployed using the installer. There is no live replication of App Service instances across regions.
• Custom domain DNS changes take time to propagate. Users may experience continued failures during DNS TTL expiry after a failover.
• The secondary region must have sufficient Azure resource quota for the required App Service Plan, SQL database tier, and Storage Account before recovery can complete.

Troubleshooting

1. Geo-redundant backup is not available for the SQL database
   Cause: Backup storage redundancy was set to LRS or ZRS (not GRS) before the failure.
   Fix: Geo-restore is not possible without GRS backup storage. Contact Turbo360 support. Going forward, configure GRS backup storage during initial deployment.

2. SQL geo-restore fails with a region capacity error
   Cause: The target secondary region does not have sufficient SQL capacity at the required tier.
   Fix: Select a different secondary region with available capacity. Check Azure subscription quotas for SQL in the target region.

3. Turbo360 portal is accessible after recovery but shows no data
   Cause: The Web App connection strings are pointing to the original primary region SQL database, which is unavailable.
   Fix: Update the connection strings in App Service Configuration to reference the restored SQL database FQDN and restart the App Service resources.

4. Storage Account failover completed but Function Apps cannot access blobs
   Cause: The Storage Account connection strings in Function App configuration still reference the primary region endpoint.
   Fix: Update the AzureWebJobsStorage and any Turbo360 storage connection strings in the Function App configuration settings to reference the new primary (formerly secondary) endpoint, then restart the Function Apps.

5. Environment health shows degraded status after recovery
   Cause: One or more App Service resources has not completed startup, or a connection string is incorrect.
   Fix: Review Application Insights for startup exceptions. Verify all four connection strings (SQL, Storage blob, Storage queue, Application Insights) are correctly set in each App Service resource's configuration.

FAQs

1. Does Turbo360 support active-active or active-passive multi-region deployments?
   Turbo360 private hosting is designed as a single-region deployment. Active-active configurations are not supported. DR recovery deploys a new single-region instance in the secondary region.

2. How long does a typical disaster recovery take?
   For a standard deployment with geo-redundant backups in place, recovery typically takes 1–3 hours: 10–60 minutes for SQL geo-restore, 15–30 minutes for App Service redeployment, and 15–30 minutes for validation. Total time depends on database size and secondary region resource availability.

3. Should I test my DR plan before an actual failure?
   Yes. Testing the DR plan in a non-production environment before an actual failure is strongly recommended. A DR test confirms that geo-redundant backups are being created, that the recovery steps work as documented, and that recovery time meets your RTO. Contact Turbo360 support to coordinate a DR test.

Related articles

• Backup & recovery
• High availability
• Environment health
• Infrastructure requirements
• Private hosting architecture