{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/", "slug": "dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback", "url": "https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/" }, "title": "Account for disks added in Azure before Site Recovery failback", "summary": "Which data needs a separate return plan if disks were attached while a failed-over workload was running in Azure?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:22:42+00:00", "modified_at": "2026-09-10T02:14:30+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 234, "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.", "primary_source": { "name": "About failover and failback in Azure Site Recovery - Modernized - Azure Site Recovery | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/site-recovery/failover-failback-overview-modernized", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts

\n

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.

\n

Applicability

\n

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.

\n

DSE recommendation

\n

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.

\n

Verification

\n

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.

\n

Official references

\n

Microsoft Learn: About failover and failback in Azure Site Recovery – Modernized.

", "content_text": "Source facts\nDuring 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.\nApplicability\nReview 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.\nDSE recommendation\nBuild 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.\nVerification\nDuring 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.\nOfficial references\nMicrosoft Learn: About failover and failback in Azure Site Recovery – Modernized.", "content_markdown": "## Source facts\n\nDuring 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).\n\n## Applicability\n\nReview 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.\n\n## DSE recommendation\n\nBuild 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.\n\n## Verification\n\nDuring 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.\n\n## Official references\n\n[Microsoft Learn: About failover and failback in Azure Site Recovery – Modernized](https://learn.microsoft.com/en-us/azure/site-recovery/failover-failback-overview-modernized)." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/", "url": "https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Account for disks added in Azure before Site Recovery failback", "item": "https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/", "url": "https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/", "headline": "Account for disks added in Azure before Site Recovery failback", "description": "Which data needs a separate return plan if disks were attached while a failed-over workload was running in Azure?", "abstract": "Which data needs a separate return plan if disks were attached while a failed-over workload was running in Azure?", "articleBody": "Source facts\nDuring 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.\nApplicability\nReview 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.\nDSE recommendation\nBuild 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.\nVerification\nDuring 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.\nOfficial references\nMicrosoft Learn: About failover and failback in Azure Site Recovery – Modernized.", "datePublished": "2026-09-10T00:22:42+00:00", "dateModified": "2026-09-10T02:14:30+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-554-account-for-disks-added-in-azure-before-site-recovery-failback/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Account for disks added in Azure before Site Recovery failback" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 234, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "About failover and failback in Azure Site Recovery - Modernized - Azure Site Recovery | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/site-recovery/failover-failback-overview-modernized" } } ] } }