FAQ about SQL Server databases that are running on an Azure VM backup

Yes, you can have both VM backup and SQL backup on the same VM. In this case, we internally trigger copy-only full backup on the VM to not truncate the logs.

Under some circumstances, the Azure Backup service triggers remedial backups. Auto-heal can happen for any of the following six conditions:

• If log or differential backup fails due to LSN Validation Error, next log or differential backup is instead converted to a full backup.
• If no full backup has happened before a log or differential backup, that log or differential backup is instead converted to a full backup.
• If the latest full backup's point-in-time is older than 15 days, the next log or differential backup is instead converted to a full backup.
• All the backup jobs that get canceled due to an extension upgrade are retriggered after the upgrade is completed and the extension is started.
• If you choose to overwrite the database during Restore, the next log/differential backup fails and a full backup is triggered instead.
• In cases where a full backup is required to reset the log chains due to change in database recovery model, a full gets triggered automatically on the next schedule.

No, you can’t cancel an auto-heal job. However, you can opt out of it by following these steps:

1. On the SQL Server instance, in the C:\Program Files\Azure Workload Backup\bin folder, create or edit the ExtensionSettingsOverrides.json file.
2. In the ExtensionSettingsOverrides.json file, set {"EnableAutoHealer": false}.
3. Save the changes and close the file.
4. On the SQL Server instance, open Task Manage, and then restart the AzureWLBackupCoordinatorSvc service.

Yes. You can throttle the rate at which the backup policy runs to minimize the impact on a SQL Server instance. To change the setting:

1. On the SQL Server instance, in the C:\Program Files\Azure Workload Backup\bin folder, create the ExtensionSettingsOverrides.json file.

2. In the ExtensionSettingsOverrides.json file, change the DefaultBackupTasksThreshold setting to a lower value (for example, 5).
   {"DefaultBackupTasksThreshold": 5}
   The default value of DefaultBackupTasksThreshold is 20.

3. Save your changes and close the file.

4. On the SQL Server instance, open Task Manager. Restart the AzureWLBackupCoordinatorSvc service.
   
   While this method helps if the backup application is consuming a large quantity of resources, SQL Server Resource Governor is a more generic way to specify limits on the amount of CPU, physical IO, and memory that incoming application requests can use.

No. Successful backup jobs don't generate alerts. Alerts are sent only for backup jobs that fail. Detailed behavior for portal alerts is documented here. However, if you're interested in having alerts even for successful jobs, you can use Monitoring using Azure Monitor.

Yes, you can achieve this capability with autoprotection.

If a database is dropped from an autoprotected instance, the database backups are still attempted. This implies that the deleted database begins to show up as unhealthy under Backup Items and is still protected.

The correct way to stop protecting this database is to do Stop Backup with delete data on this database.

Yes, you can protect databases on virtual machines that have Azure Disk Encryption (ADE) enabled.

Yes, Azure Backup supports backup of SQL Server databases or server with TDE enabled. Backup supports TDE with keys managed by Azure, or with customer-managed keys (BYOK). Backup doesn't perform any SQL encryption as part of the backup process so the database will stay encrypted when backed up.

We do perform a checksum operation on the data stream. However, this isn't to be confused with SQL checksum. Azure workload backup computes the checksum on the data stream and stores it explicitly during the backup operation. This checksum stream is then taken as a reference and cross-verified with the checksum of the data stream during the restore operation to make sure that the data is consistent.

Yes. Azure Site Recovery will trigger a copy-only full backup while taking the application consistent snapshot on the VM not to truncate the logs. Learn more.

The Backup Job menu shows all scheduled and on-demand operations, except the scheduled log backups since they can be very frequent. For scheduled log jobs, use Monitoring using Azure Monitor.

If you do stop backup with retain data, no future backups will take place and the existing recovery points will remain intact. The database will still be considered as protected and be shown under the Backup items.

If you do stop backup with delete data, no future backups will take place and the existing recovery points will also be deleted. The database will be considered un-protected and be shown under the instance on the Configure Backup blade. However, unlike other up-protected databases that can be selected manually or that can get autoprotected, this database appears greyed out and can’t be selected. The only way to re-protect this database is to disable auto-protection on the instance. You can now select this database and configure protection on it or re-enable auto-protection on the instance again.

A renamed database is treated as a new database. So the service will treat this situation as if the database weren't found and with fail the backups.

You can select the database, which is now renamed and configure protection on it. If the auto-protection is enabled on the instance, the renamed database will be automatically detected and protected.

A database that you add to an autoprotected instance might not immediately appear under protected items. This is because the discovery typically runs every 8 hours, and the actual protection of the system can take additional time as it depends on the size of the VM. However, you can discover new databases immediately if you manually run a discovery by selecting Rediscover DBs, as shown in the following image:

Yes, you can download files partially as documented here.

Yes, you need a file path in a registered VM to download files. That path can be a network share too. Configure a network share from the unregistered VM to the registered VM and then choose the registered VM as target and the network share as the target file path. Once files are downloaded, you could simply unmount the network share from the registered VM and the files are now available in the unregistered VM.

During the backup operation, the backup job connects to three Service Endpoints - AzureBackup, AzureStorage, and Microsoft Entra ID. In this scenario, we recommend you to configure the Service Endpoint to AzureStorage, which helps to send the traffic from the Virtual Network to the Storage directly. For Azure Backup and Microsoft Entra ID, you can configure UDR over service tags so that the traffic travels to backbone network instead of on-premises.

Next steps

Learn how to back up a SQL Server database that's running on an Azure VM.