Overview
This article describes the backup and recovery options available for a Turbo360 private hosting instance. It covers automatic Azure SQL backups, point-in-time restore, storage account redundancy, and the steps to recover Turbo360 after data loss or a failed deployment.
Business value
Understanding backup coverage and recovery procedures reduces mean time to recovery (MTTR) when failures occur. Knowing which data is backed up automatically, which requires additional configuration, and how to initiate a restore ensures you can recover a Turbo360 private instance with minimal data loss and without waiting for Turbo360 support to provide steps under pressure.
Prerequisites
- Contributor access to the Turbo360 resource group in the Azure portal
- SQL Server Contributor or higher role if initiating database restores
- A completed Turbo360 private deployment (see Deployment)
Required permissions
| Task | Required role |
|---|---|
| Initiate SQL point-in-time restore | SQL Server Contributor or Contributor on resource group |
| Configure long-term SQL backup retention | SQL Server Contributor |
| Configure Storage Account redundancy | Storage Account Contributor or Contributor |
| Restore from Azure Backup vault | Backup Operator |
How it works
Turbo360 private hosting runs on Azure-managed resources. Backup coverage for these resources is provided by Azure natively:
- Azure SQL Database — automatic backups run continuously. Full backups occur weekly, differential backups every 12–24 hours, and log backups every 5–10 minutes. Point-in-time restore (PITR) is available within the configured retention window (7–35 days for Standard and Premium tiers).
- Azure Storage Account — storage redundancy (LRS, ZRS, GRS, GZRS) protects against hardware failure and, for geo-redundant options, regional outages. Storage does not provide point-in-time restore by default; Azure Backup for Blobs can be configured separately.
- App Service (Web App and Function Apps) — no persistent data is stored in App Service. Application configuration is stored in the SQL database and Azure App Service configuration settings. App Service configurations can be exported manually.
No Turbo360-specific backup agent or tool is required. All backup operations use Azure-native mechanisms.
Configuration
SQL backup retention
Azure SQL automatic backup retention defaults to 7 days. Extend this to meet your recovery time objectives.
Configure retention period:
- In the Azure portal, navigate to the SQL Server (not the database) in your Turbo360 resource group.
- Under Data management, select Backups.
- Select the Retention policies tab.
- Set the Point-in-time restore retention period (up to 35 days for Standard/Premium tier).
- Click Save.
Configure long-term retention (beyond 35 days):
- On the same Backups page, select the Long-term retention tab.
- Select the database and click Configure policies.
- Set weekly, monthly, or yearly backup retention periods.
- An Azure Recovery Services Vault is required to store long-term retention backups.
Storage Account redundancy
The default redundancy tier for the Turbo360 Storage Account depends on the region and installer defaults. Review and upgrade if required.
Change redundancy level:
- In the Azure portal, navigate to the Storage Account in the Turbo360 resource group.
- Select Redundancy under Data management.
- Change the redundancy option (LRS, ZRS, GRS, or GZRS) and save.
| Redundancy | Protection |
|---|---|
| LRS | Single datacenter. No protection against datacenter failure. |
| ZRS | Three availability zones in the same region. Recommended minimum. |
| GRS | LRS in primary region + asynchronous copy to secondary region. |
| GZRS | ZRS in primary region + asynchronous copy to secondary region. Highest redundancy. |
Enable Azure Backup for Blob storage (optional)
For point-in-time recovery of blob data:
- Create or select an Azure Backup vault in the same region.
- Navigate to the Backup vault > Backup > + Backup.
- Select Azure Blobs (Azure Storage) as the data source.
- Select the Turbo360 Storage Account.
- Configure the backup policy (retention period and operational backup schedule).
Steps
Restore SQL database to a point in time
Use this procedure to recover the Turbo360 SQL database after data corruption, accidental deletion, or a failed upgrade.
- In the Azure portal, navigate to the SQL database in the Turbo360 resource group.
- Select Restore from the top action bar.
- Under Restore point, select the date and time to restore to. The earliest available point depends on the configured retention period.
- Enter a name for the restored database. The restore creates a new database — it does not overwrite the existing one.
- Click Review + create, then Create.
- Wait for the restore operation to complete (typically 5–30 minutes depending on database size).
- Once the restore completes, update the Turbo360 connection string to point to the restored database, or swap the database names in the SQL Server.
:::(Warning)(Important:)
Restoring creates a new database. You must update the Turbo360 Web App and Function App connection strings — or rename the databases — before the restored data becomes active. Contact Turbo360 support if you are unsure how to swap the active database.
:::
Export App Service configuration
Use this procedure to capture the current App Service configuration as a backup before making changes.
- In the Azure portal, navigate to the Web App or Function App.
- Select Configuration > Advanced edit.
- Copy the JSON configuration and save it to a secure location outside the resource group.
Repeat for all three Function Apps and the Web App. Store exported configurations in a storage account or key vault outside the Turbo360 resource group.
Example scenario
A platform engineer initiates a Turbo360 upgrade that modifies the SQL schema. The upgrade fails partway through, leaving the database in a partially migrated state. The engineer initiates a point-in-time restore to 30 minutes before the upgrade began, creating a restored database named turbo360-db-restored. After verifying the restored database is intact, they update the Web App and Function App connection strings to reference the restored database and restart the application. Turbo360 returns to a healthy state within 45 minutes of the failure.
Limitations
- Point-in-time restore is only available within the configured retention window (7–35 days). Data loss beyond this window cannot be recovered without long-term retention configured.
- Long-term SQL backup retention requires an Azure Recovery Services Vault, which incurs additional Azure cost.
- Blob storage point-in-time recovery requires Azure Backup for Blobs to be configured before data loss occurs. It cannot be enabled retroactively.
- App Service configurations are not automatically backed up. Manual export is the only mechanism available. Changes made after the last export will be lost if the configuration needs to be restored.
- Restoring the SQL database creates a new database instance. Turbo360 connection strings must be updated manually to activate the restored data.
Troubleshooting
-
Point-in-time restore option is not available for the target date
Cause: The requested restore point is outside the configured retention window.
Fix: Check the retention period configured on the SQL Server > Backups page. If the required date is beyond the retention window, data cannot be recovered via PITR. Enable long-term retention going forward to avoid this situation. -
Restore operation completes but Turbo360 still shows data from before the restore
Cause: The Web App and Function Apps are still connected to the original database, not the restored one.
Fix: Update the connection strings in the App Service Configuration settings to point to the restored database name, then restart all App Service resources. -
Storage Account shows unexpected data loss
Cause: Blobs were deleted and no Azure Backup for Blobs policy was configured.
Fix: If soft delete was enabled on the Storage Account, recover deleted blobs from the Storage browser within the soft delete retention period. If soft delete was not enabled, data cannot be recovered. Enable Azure Backup for Blobs to protect against future loss. -
Long-term retention configuration fails
Cause: An Azure Recovery Services Vault does not exist in the target region, or the vault is in a different subscription.
Fix: Create a Recovery Services Vault in the same region as the SQL database. Ensure the vault is in the same subscription or that cross-subscription backup policies are permitted by your organisation. -
App Service configuration restore required but no export was saved
Cause: Configuration was not exported before the change that caused the issue.
Fix: Review Azure Activity Logs for recent configuration changes and manually reconstruct the settings. Contact Turbo360 support for assistance with configuration recovery.
FAQs
-
Are Turbo360 SQL backups enabled by default, or do I need to enable them?
Azure SQL automatic backups are enabled by default for all Azure SQL databases on Standard and Premium tiers. No action is required to activate them. The default retention period is 7 days — extend this in the SQL Server backup settings if your recovery requirements demand a longer window. -
Does Turbo360 store any data in App Service that would be lost if the App Service was deleted?
No. Turbo360 does not use App Service local storage for persistent data. All configuration and operational data is stored in the SQL database and Storage Account. Deleting and redeploying App Service resources does not result in data loss, provided the connection strings are reconnected to the original SQL database and Storage Account. -
How do I protect against a full region failure?
Configure GRS or GZRS redundancy on the Storage Account and enable long-term SQL backup retention with geo-redundant backup storage. In the event of a regional failure, restore the SQL database to a secondary region SQL Server using the geo-redundant backup copy and redeploy the Turbo360 App Service resources in the secondary region. See Disaster recovery for the full procedure.