# Distinguish an OpenZFS scrub from a resilver when reviewing pool health

> Record reconstruction and whole-pool checksum review as distinct OpenZFS health events.

- Canonical URL: https://update.dsesecurity.com/updates/distinguish-an-openzfs-scrub-from-a-resilver-when-reviewing-pool-health/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T13:32:43+00:00
- Modified: 2026-10-15T13:36:15+00:00
- Last reviewed by DSE: 2026-10-15
- Resource type: Guide
- DSE priority: Information
- Topics: Business Continuity, IT
- Reading time: 2 minutes

## What you need to know

Record reconstruction and whole-pool checksum review as distinct OpenZFS health events.

## Potentially affected

This 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.

## DSE recommendation

DSE recommends keeping reconstruction and whole-pool verification as separate events in the storage record.

## Article

Record reconstruction and whole-pool checksum review as distinct OpenZFS health events.

## Source facts

OpenZFS 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.

Source: [OpenZFS 2.3 — zpool scrub](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-scrub.8.html).

## Applicability

This 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.

## DSE recommendation

DSE 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.

## Verification

On 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.

## Official reference

[OpenZFS 2.3 — zpool scrub](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-scrub.8.html). Reviewed October 15, 2026.

## Primary reference

- Name: OpenZFS 2.3 — zpool scrub
- Authority: openzfs.github.io
- URL: https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-scrub.8.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Distinguish an OpenZFS scrub from a resilver when reviewing pool health,” DSE Security, https://update.dsesecurity.com/updates/distinguish-an-openzfs-scrub-from-a-resilver-when-reviewing-pool-health/
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.