{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/",
        "slug": "dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning",
        "url": "https://update.dsesecurity.com/updates/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/"
        },
        "title": "Include resynchronization time in S2D per-server capacity planning",
        "summary": "How should per-server capacity be reviewed before expanding an S2D cluster?",
        "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-08T18:14:05+00:00",
        "modified_at": "2026-09-08T18:26:32+00:00",
        "reviewed_on": "2026-09-08",
        "reading_minutes": 1,
        "word_count": 214,
        "potentially_affected": "Administrators planning drive capacity for Azure Local or Windows Server storage clusters.",
        "dse_recommendation": "Prepare a per-node capacity inventory and a separate pool total.",
        "primary_source": {
            "name": "Choose drives for Azure Local and Windows Server clusters",
            "url": "https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/choose-drives",
            "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": "<h2>Source facts</h2>\n<p>Microsoft recommends limiting the total storage capacity on an individual server to about 400 terabytes. The source connects greater capacity per server with longer data-resynchronization time after an outage or reboot. It lists a four-petabyte maximum storage-pool size, with a one-petabyte limit for Windows Server 2016. <a href=\"https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/choose-drives\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn</a>.</p>\n<h2>Applicability</h2>\n<p>Identify the server version and distinguish capacity on one server from capacity across the whole pool. Review the current platform limits before applying the numbers. Ask the workload owner what recovery and maintenance duration is acceptable for the proposed expansion.</p>\n<h2>DSE recommendation</h2>\n<p>Prepare a per-node capacity inventory and a separate pool total. Pair the expansion request with an observed or tested resynchronization-time estimate appropriate to the actual hardware and workload. Have the storage owner explain how the larger node affects the maintenance plan. Avoid presenting a supported maximum as the preferred design target without considering operational recovery.</p>\n<h2>Verification</h2>\n<p>Measure a representative approved node-return and resynchronization exercise before accepting the expanded design. Record data volume, workload, hardware, elapsed time, and health at completion. Compare the result with the maintenance and recovery expectations. Retain the measured conditions so future capacity additions trigger another review rather than inheriting an unrelated timing assumption.</p>\n<h2>Official references</h2>\n<p><a href=\"https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/choose-drives\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn: Choose drives for Azure Local and Windows Server clusters</a>. Source reviewed September 8, 2026.</p>",
        "content_text": "Source facts\nMicrosoft recommends limiting the total storage capacity on an individual server to about 400 terabytes. The source connects greater capacity per server with longer data-resynchronization time after an outage or reboot. It lists a four-petabyte maximum storage-pool size, with a one-petabyte limit for Windows Server 2016. Microsoft Learn.\nApplicability\nIdentify the server version and distinguish capacity on one server from capacity across the whole pool. Review the current platform limits before applying the numbers. Ask the workload owner what recovery and maintenance duration is acceptable for the proposed expansion.\nDSE recommendation\nPrepare a per-node capacity inventory and a separate pool total. Pair the expansion request with an observed or tested resynchronization-time estimate appropriate to the actual hardware and workload. Have the storage owner explain how the larger node affects the maintenance plan. Avoid presenting a supported maximum as the preferred design target without considering operational recovery.\nVerification\nMeasure a representative approved node-return and resynchronization exercise before accepting the expanded design. Record data volume, workload, hardware, elapsed time, and health at completion. Compare the result with the maintenance and recovery expectations. Retain the measured conditions so future capacity additions trigger another review rather than inheriting an unrelated timing assumption.\nOfficial references\nMicrosoft Learn: Choose drives for Azure Local and Windows Server clusters. Source reviewed September 8, 2026.",
        "content_markdown": "## Source facts\n\nMicrosoft recommends limiting the total storage capacity on an individual server to about 400 terabytes. The source connects greater capacity per server with longer data-resynchronization time after an outage or reboot. It lists a four-petabyte maximum storage-pool size, with a one-petabyte limit for Windows Server 2016. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/choose-drives).\n\n## Applicability\n\nIdentify the server version and distinguish capacity on one server from capacity across the whole pool. Review the current platform limits before applying the numbers. Ask the workload owner what recovery and maintenance duration is acceptable for the proposed expansion.\n\n## DSE recommendation\n\nPrepare a per-node capacity inventory and a separate pool total. Pair the expansion request with an observed or tested resynchronization-time estimate appropriate to the actual hardware and workload. Have the storage owner explain how the larger node affects the maintenance plan. Avoid presenting a supported maximum as the preferred design target without considering operational recovery.\n\n## Verification\n\nMeasure a representative approved node-return and resynchronization exercise before accepting the expanded design. Record data volume, workload, hardware, elapsed time, and health at completion. Compare the result with the maintenance and recovery expectations. Retain the measured conditions so future capacity additions trigger another review rather than inheriting an unrelated timing assumption.\n\n## Official references\n\n[Microsoft Learn: Choose drives for Azure Local and Windows Server clusters](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/choose-drives). Source reviewed September 8, 2026."
    },
    "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-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/",
                "url": "https://update.dsesecurity.com/updates/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-09-08"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Include resynchronization time in S2D per-server capacity planning",
                        "item": "https://update.dsesecurity.com/updates/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/#article",
                "identifier": "https://update.dsesecurity.com/updates/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/",
                "url": "https://update.dsesecurity.com/updates/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/",
                "headline": "Include resynchronization time in S2D per-server capacity planning",
                "description": "How should per-server capacity be reviewed before expanding an S2D cluster?",
                "abstract": "How should per-server capacity be reviewed before expanding an S2D cluster?",
                "articleBody": "Source facts\nMicrosoft recommends limiting the total storage capacity on an individual server to about 400 terabytes. The source connects greater capacity per server with longer data-resynchronization time after an outage or reboot. It lists a four-petabyte maximum storage-pool size, with a one-petabyte limit for Windows Server 2016. Microsoft Learn.\nApplicability\nIdentify the server version and distinguish capacity on one server from capacity across the whole pool. Review the current platform limits before applying the numbers. Ask the workload owner what recovery and maintenance duration is acceptable for the proposed expansion.\nDSE recommendation\nPrepare a per-node capacity inventory and a separate pool total. Pair the expansion request with an observed or tested resynchronization-time estimate appropriate to the actual hardware and workload. Have the storage owner explain how the larger node affects the maintenance plan. Avoid presenting a supported maximum as the preferred design target without considering operational recovery.\nVerification\nMeasure a representative approved node-return and resynchronization exercise before accepting the expanded design. Record data volume, workload, hardware, elapsed time, and health at completion. Compare the result with the maintenance and recovery expectations. Retain the measured conditions so future capacity additions trigger another review rather than inheriting an unrelated timing assumption.\nOfficial references\nMicrosoft Learn: Choose drives for Azure Local and Windows Server clusters. Source reviewed September 8, 2026.",
                "datePublished": "2026-09-08T18:14:05+00:00",
                "dateModified": "2026-09-08T18:26:32+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/"
                },
                "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-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/#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": "Include resynchronization time in S2D per-server capacity planning"
                },
                "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": 214,
                "timeRequired": "PT1M",
                "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": "Choose drives for Azure Local and Windows Server clusters",
                    "url": "https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/choose-drives"
                }
            }
        ]
    }
}