Azure DevOps Server rollback consistency using VM snapshots versus SQL backups

Azure DevOps Server upgrades involve in-place modifications to the configuration and team project collection databases via the upgrade wizard. Because there is no supported in-place downgrade, the only documented recovery path is restoring from backups taken prior to the upgrade attempt.

A technical challenge arises when choosing between utilizing standard SQL Server database backups and virtual machine (VM) snapshots for a multi-server deployment. While SQL backups allow for point-in-time recovery across the configuration and collection databases, VM snapshots capture the application-tier state and file system simultaneously.

There is uncertainty regarding whether a snapshot-based rollback can lead to inconsistencies between the application-tier metadata and the SQL database state if the databases are hosted on a separate SQL instance.

• What are the specific risks of using VM snapshots for rolling back Azure DevOps Server compared to manual SQL database restores?
• Does restoring a VM snapshot require manual re-configuration of the application tier to ensure compatibility with the restored databases?