# Account for disks added in Azure before Site Recovery failback

> Which data needs a separate return plan if disks were attached while a failed-over workload was running in Azure?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:22:42+00:00
- Modified: 2026-09-10T02:14:30+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

Which data needs a separate return plan if disks were attached while a failed-over workload was running in Azure?

## Potentially affected

Review workloads that changed their disk layout while operating in Azure after an on-premises outage. Compare the original protected disk inventory with the current Azure VM rather than relying on its name or the apparent completeness of its application.

## DSE recommendation

Build a return manifest that assigns an owner and destination to every newly attached disk and its data.

## Article

## Source facts

During modernized Site Recovery reprotection to on-premises, only disks previously replicated from the source are copied back. Disks newly attached to the failed-over Azure VM are not included. The on-premises VM, when present, is shut down during reprotection for consistency. After failback, protection toward Azure must be enabled again; returning the workload and restoring its protection direction are separate stages. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/site-recovery/failover-failback-overview-modernized).

## Applicability

Review workloads that changed their disk layout while operating in Azure after an on-premises outage. Compare the original protected disk inventory with the current Azure VM rather than relying on its name or the apparent completeness of its application.

## DSE recommendation

Build a return manifest that assigns an owner and destination to every newly attached disk and its data. Resolve the separate transfer and application-consistency plan before approving failback. Keep the original replicated disks visibly distinct from cloud-added storage, and agree which application checks must pass before the Azure-side recovery work is considered complete.

## Verification

During an approved rehearsal, reconcile source-era disks, current Azure attachments, and the expected on-premises result. Verify that the separate data-return plan covers every new disk, including application dependencies that refer to it. After the workload returns, check replication toward Azure independently. Do not accept an accessible on-premises VM as evidence that all cloud-era additions were transferred or protection was restored.

## Official references

[Microsoft Learn: About failover and failback in Azure Site Recovery – Modernized](https://learn.microsoft.com/en-us/azure/site-recovery/failover-failback-overview-modernized).

## Primary reference

- Name: About failover and failback in Azure Site Recovery - Modernized - Azure Site Recovery | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/site-recovery/failover-failback-overview-modernized
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Account for disks added in Azure before Site Recovery failback,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.