Slowness issue when restoring a Linux VM

Hello CASTTDE,

Thank you for posting your query on Microsoft Q&A platform.

Linux VM restore in Azure Backup took 45 minutes during a DR drill, whereas it normally completes in ~4 minutes.

Azure VM restores can follow two different paths:

• Instant Restore (snapshot tier) – Fast (minutes) because disks are rehydrated from snapshots stored with the VM.
• Vault restore – Slower (tens of minutes) because data is copied from the Recovery Services vault to managed disks.

Your quick morning restore likely used Instant Restore, while the DR drill restore used the vault path or faced additional delays might be due to the below following reasons:

• Snapshot not available at drill time → fallback to vault restore.
• Restore option changed (example: “Create new VM” instead of “Restore disks”).
• Concurrent restores during DR drill → IOPS/network throttling.
• Linux boot initialization (fsck, cloud-init, extension provisioning).
• Quota or regional capacity checks causing allocation retries.

The primary cause is restore path difference (vault restore instead of Instant Restore) combined with environmental factors during DR drill (load, boot tasks, capacity).

As a workaround:

1. Ensure Instant Restore is available during DR drills
   • Adjust snapshot retention in backup policy.
   • Microsoft Doc: Instant Restore Capability
2. Use the fastest restore option
   • Prefer Restore disks and attach to a pre-staged VM template.
   • Microsoft Doc: Restore VMs using Azure Backup
3. Reduce contention
   • Stagger restores or use multiple vaults.
   • Microsoft Doc: About Azure VM restore process
4. Optimize Linux boot time
   • Review cloud-init logs and disable nonessential steps for DR images.
   • Microsoft Doc: Cloud-init-enabled VM takes a long time to start up
5. Validate capacity and quotas before drills
   • Check compute quotas and run a test failover.
   • Microsoft Doc: Run a disaster recovery drill

Thanks,

Suchitra.