Record reconstruction and whole-pool checksum review as distinct OpenZFS health events.
\nOpenZFS 2.3 distinguishes a scrub, which checks all pool data for checksum correctness, from a resilver, which examines data known to need reconstruction. Replicated devices can repair discovered damage using available redundancy. A scrub and a resilver cannot run simultaneously because both consume substantial I/O. Scrubbing encrypted datasets does not require loaded keys, but without those keys an unrepairable error cannot include the affected filename in the verbose status report. Pool status records progress and results.
\nSource: OpenZFS 2.3 — zpool scrub.
\nThis applies to the OpenZFS 2.3 scrub command and its documented pool-health reporting. It does not assert that every detected error is repairable or that a completed scrub proves application correctness.
\nDSE recommends keeping reconstruction and whole-pool verification as separate events in the storage record. After a disk incident, identify which operation is actually running and which result the operator still needs. Assign an owner to unresolved errors rather than accepting a progress percentage as the health decision. Plan the observation window around workload impact, and state whether encrypted-dataset keys will be available when file-level diagnosis is required. Keep a separate recovery path for data that cannot be repaired.
\nOn a test pool, compare the status fields produced by scrub and replacement activity. Verify that monitoring recognizes an unfinished operation and retains the final error summary. Review encrypted-dataset reporting with the intended key state, and document any remaining uncertainty about affected files.
\nOpenZFS 2.3 — zpool scrub. Reviewed October 15, 2026.
", "content_text": "Record reconstruction and whole-pool checksum review as distinct OpenZFS health events.\nSource facts\nOpenZFS 2.3 distinguishes a scrub, which checks all pool data for checksum correctness, from a resilver, which examines data known to need reconstruction. Replicated devices can repair discovered damage using available redundancy. A scrub and a resilver cannot run simultaneously because both consume substantial I/O. Scrubbing encrypted datasets does not require loaded keys, but without those keys an unrepairable error cannot include the affected filename in the verbose status report. Pool status records progress and results.\nSource: OpenZFS 2.3 — zpool scrub.\nApplicability\nThis applies to the OpenZFS 2.3 scrub command and its documented pool-health reporting. It does not assert that every detected error is repairable or that a completed scrub proves application correctness.\nDSE recommendation\nDSE recommends keeping reconstruction and whole-pool verification as separate events in the storage record. After a disk incident, identify which operation is actually running and which result the operator still needs. Assign an owner to unresolved errors rather than accepting a progress percentage as the health decision. Plan the observation window around workload impact, and state whether encrypted-dataset keys will be available when file-level diagnosis is required. Keep a separate recovery path for data that cannot be repaired.\nVerification\nOn a test pool, compare the status fields produced by scrub and replacement activity. Verify that monitoring recognizes an unfinished operation and retains the final error summary. Review encrypted-dataset reporting with the intended key state, and document any remaining uncertainty about affected files.\nOfficial reference\nOpenZFS 2.3 — zpool scrub. Reviewed October 15, 2026.", "content_markdown": "Record reconstruction and whole-pool checksum review as distinct OpenZFS health events.\n\n## Source facts\n\nOpenZFS 2.3 distinguishes a scrub, which checks all pool data for checksum correctness, from a resilver, which examines data known to need reconstruction. Replicated devices can repair discovered damage using available redundancy. A scrub and a resilver cannot run simultaneously because both consume substantial I/O. Scrubbing encrypted datasets does not require loaded keys, but without those keys an unrepairable error cannot include the affected filename in the verbose status report. Pool status records progress and results.\n\nSource: [OpenZFS 2.3 — zpool scrub](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-scrub.8.html).\n\n## Applicability\n\nThis applies to the OpenZFS 2.3 scrub command and its documented pool-health reporting. It does not assert that every detected error is repairable or that a completed scrub proves application correctness.\n\n## DSE recommendation\n\nDSE recommends keeping reconstruction and whole-pool verification as separate events in the storage record. After a disk incident, identify which operation is actually running and which result the operator still needs. Assign an owner to unresolved errors rather than accepting a progress percentage as the health decision. Plan the observation window around workload impact, and state whether encrypted-dataset keys will be available when file-level diagnosis is required. Keep a separate recovery path for data that cannot be repaired.\n\n## Verification\n\nOn a test pool, compare the status fields produced by scrub and replacement activity. Verify that monitoring recognizes an unfinished operation and retains the final error summary. Review encrypted-dataset reporting with the intended key state, and document any remaining uncertainty about affected files.\n\n## Official reference\n\n[OpenZFS 2.3 — zpool scrub](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-scrub.8.html). Reviewed October 15, 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/distinguish-an-openzfs-scrub-from-a-resilver-when-reviewing-pool-health/", "url": "https://update.dsesecurity.com/updates/distinguish-an-openzfs-scrub-from-a-resilver-when-reviewing-pool-health/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-15" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/distinguish-an-openzfs-scrub-from-a-resilver-when-reviewing-pool-health/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Distinguish an OpenZFS scrub from a resilver when reviewing pool health", "item": "https://update.dsesecurity.com/updates/distinguish-an-openzfs-scrub-from-a-resilver-when-reviewing-pool-health/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/distinguish-an-openzfs-scrub-from-a-resilver-when-reviewing-pool-health/#article", "identifier": "https://update.dsesecurity.com/updates/distinguish-an-openzfs-scrub-from-a-resilver-when-reviewing-pool-health/", "url": "https://update.dsesecurity.com/updates/distinguish-an-openzfs-scrub-from-a-resilver-when-reviewing-pool-health/", "headline": "Distinguish an OpenZFS scrub from a resilver when reviewing pool health", "description": "Record reconstruction and whole-pool checksum review as distinct OpenZFS health events.", "abstract": "Record reconstruction and whole-pool checksum review as distinct OpenZFS health events.", "articleBody": "Record reconstruction and whole-pool checksum review as distinct OpenZFS health events.\nSource facts\nOpenZFS 2.3 distinguishes a scrub, which checks all pool data for checksum correctness, from a resilver, which examines data known to need reconstruction. Replicated devices can repair discovered damage using available redundancy. A scrub and a resilver cannot run simultaneously because both consume substantial I/O. Scrubbing encrypted datasets does not require loaded keys, but without those keys an unrepairable error cannot include the affected filename in the verbose status report. Pool status records progress and results.\nSource: OpenZFS 2.3 — zpool scrub.\nApplicability\nThis applies to the OpenZFS 2.3 scrub command and its documented pool-health reporting. It does not assert that every detected error is repairable or that a completed scrub proves application correctness.\nDSE recommendation\nDSE recommends keeping reconstruction and whole-pool verification as separate events in the storage record. After a disk incident, identify which operation is actually running and which result the operator still needs. Assign an owner to unresolved errors rather than accepting a progress percentage as the health decision. Plan the observation window around workload impact, and state whether encrypted-dataset keys will be available when file-level diagnosis is required. Keep a separate recovery path for data that cannot be repaired.\nVerification\nOn a test pool, compare the status fields produced by scrub and replacement activity. Verify that monitoring recognizes an unfinished operation and retains the final error summary. Review encrypted-dataset reporting with the intended key state, and document any remaining uncertainty about affected files.\nOfficial reference\nOpenZFS 2.3 — zpool scrub. Reviewed October 15, 2026.", "datePublished": "2026-10-15T13:32:43+00:00", "dateModified": "2026-10-15T13:36:15+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/distinguish-an-openzfs-scrub-from-a-resilver-when-reviewing-pool-health/" }, "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/distinguish-an-openzfs-scrub-from-a-resilver-when-reviewing-pool-health/#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": "Distinguish an OpenZFS scrub from a resilver when reviewing pool health" }, "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": 255, "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": "OpenZFS 2.3 — zpool scrub", "url": "https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-scrub.8.html" } } ] } }