How to back up SQL failover EC2 instance after successful DRaaS failover

Problem description

When performing a Disaster Recovery as a Service (DRaaS) failover for a production SQL virtual machine (VM) from VMware to an AWS EC2 instance, users may experience issues discovering or backing up the SQL instance on the newly spun-up EC2 failover instance.
In this scenario, after activating the Druva SQL agent on the failover EC2 instance, the SQL workloads may fail to show up or register properly within the Druva Phoenix Management Console. This prevents the continuation of critical database backups post-disaster recovery, leaving the databases unprotected in the cloud environment.

Cause

This issue typically occurs due to one of the following root causes:

Missing System Databases/Installation Paths: The VMware backup policy for the source production VM excluded the virtual disk (VMDK) that contained either the SQL Server installation directory or critical SQL system databases (master, model, msdb, resource, tempdb). If the installation files are stored on a drive other than C: (e.g., E:) and that drive is excluded during VMware backup, the SQL Server services will fail to start on the converted EC2 instance.
Missing SQL Agent Activation: The Druva SQL agent has not been properly installed or activated on the newly created failover EC2 instance, preventing communication back to the Druva Phoenix Cloud.
Database Separation: User databases stored on separate volumes (e.g., F:) require deliberate re-linking or independent recovery strategies post-failover if they were omitted from the infrastructure-level snapshot.

Traceback

While specific software traceback logs can vary, administrative symptoms include:

SQL Server Service failing to launch on the EC2 instance with Windows Event Viewer errors pointing to missing system files or paths.

Error during SQL agent handshake:

[ERROR] Failed to discover SQL instances. SQL Writer service or MS-SQL Server service may not be running or reachable.

Resolution

Follow these step-by-step procedures to ensure that your SQL Server instance is fully prepared for backup on the failover EC2 instance following a DRaaS transition.

Step 1: Ensure Required Disks Are Included in VMware Backup

Review your source production SQL VM configuration. Verify that the VMware backup includes the exact disk containing the SQL installation directory and its system databases (master, model, msdb, resource, tempdb).
If the SQL installation directory is mapped to a non-C: drive (such as an E: drive), verify that its corresponding VMDK disk is explicitly not excluded within your backup settings. Note: Excluding the installation path or system databases causes the SQL Server service to break during conversion, which completely blocks database discovery in the Druva console after agent activation.

Step 2: Manage User Database Backups

If user databases are located on an isolated drive (e.g., F:) and do not require block-level backup via VMware snapshots, you may exclude this specific VMDK.
If user databases must be backed up securely at the application level, ensure that the Druva SQL agent is installed on the source production SQL VM to keep user database backups separate from the VM storage snapshot.

Step 3: Configure the Backup Policy

Navigate to the Druva Phoenix console and assign the production SQL VM to a backup policy that has the quiesced snapshot option enabled.
Configure your exclusions carefully: exclude only the disk containing user database files (e.g., F:), ensuring that the disks holding the Operating System files (C:) and the SQL installation directory (E:) remain fully included.

Step 4: Perform DR Restore & Failover

Initiate the Disaster Recovery (DR) restore and failover process using standard Druva DRaaS automated workflows. This will generate your target EC2 instance in AWS.

Step 5: Verify SQL Services on the Failover EC2 Instance

Once the DRaaS failover successfully completes, log into the newly created production SQL EC2 instance on AWS.
Open the Windows Services console (services.msc) and verify that both the MS-SQL Server service and the SQL Writer service are up and running.
Install or activate the Druva SQL agent directly on this failover EC2 instance.
Once completed, verify that the failover SQL instance successfully appears under the SQL workload section in your Phoenix management console.

Step 6: Restore User Databases

Run a restore job to pull the user databases from the original production SQL VM backups onto this active failover SQL EC2 instance. This provides a fully operational environment with both system structures and transactional data intact.

Include and exclude filters

Include: Ensure the OS drive (typically C:\) and any custom drives housing SQL Server binaries, instance configurations, or system databases (e.g., E:\) are strictly included in the VMware backup policy filters.
Exclude: Application data-only disks (e.g., F:\ containing only user .mdf/.ldf files) can safely be excluded from the VMware policy only if they are being protected natively via the Druva SQL app agent.

Verification

To verify that the configuration and resolution have worked successfully:

Confirm that the failover EC2 instance's SQL Server shows a status of Connected/Registered under Enterprise Workloads > SQL in the Phoenix Console.
Trigger an on-demand incremental backup of the SQL instance from the Phoenix console for the failover EC2 instance.
Confirm that the job completes with a status of Successful in the jobs page.