How to Verify Checksums After Replacing a Failed Drive

Verify data after a drive replacement at two layers: complete the array’s own scrub or consistency check, then compare file checksums against a manifest created before the failure or from a trusted backup.

A successful rebuild proves that redundancy was reconstructed, not that every file was compared with an independent known-good value. The best workflow preserves the original checksum manifest, verifies the storage layer, checks critical files, and records any mismatch before normal writes resume.

Finish the Rebuild Before Starting Verification

First confirm that the replacement is an active member, the array is no longer degraded, and no read, write, checksum, or media errors increased during reconstruction. A target that remains spare, ready, or rebuilding is not ready for a final data-integrity decision.

Save the final rebuild report and device serials. If the rebuild logged unreadable sectors on a surviving member, do not hide that event with a clean status screen. A reconstructed array can still contain a file-level loss when source data could not be read.

Run the Array’s Full Integrity Operation

Use the platform’s supported full check: a ZFS or Btrfs scrub, an md parity check, or the hardware controller’s consistency check. This reads data that ordinary use may not touch and compares it with checksums, mirrors, or parity according to the implementation.

A resilver and scrub are not interchangeable. The difference between scrub and resilver matters because replacement copies data needed for the new member, while a scrub examines the wider pool for silent errors.

Use a Preexisting Manifest for File-Level Proof

A file hash is useful only when it can be compared with a trusted earlier value. A checksum generated after the replacement describes the current file but cannot prove that the content is unchanged from before the failure.

For Linux files, SHA-256 manifest verification can generate and check a list with sha256sum. Keep the manifest on another system or immutable backup so a storage incident cannot silently alter both the file and its expected hash.

Verify a Representative Set When No Manifest Exists

Without earlier hashes, start with irreplaceable and structurally sensitive data: database dumps, archives, virtual-machine images, photo catalogs, encrypted containers, and large media files. Open or test the native format in addition to calculating a new hash.

A directory-level digest can reveal later changes, but it is not a historical reference unless it predates the incident. Techniques for a directory checksum inventory also show why stable sorting and consistent paths matter when many files are included.

Separate Content Checks From Metadata Checks

Content hashes normally ignore ownership, permissions, timestamps, ACLs, extended attributes, sparse allocation, and hard-link relationships. A file can pass SHA-256 while application behavior still changes because metadata was lost or restored differently.

For important services, validate from the application outward. A database consistency check or archive test can find logical problems that a block checksum does not understand.

Investigate Every Mismatch Before Rewriting It

Do not immediately regenerate the manifest after a failed check. Preserve the mismatched file, expected digest, current digest, path, size, modification time, and storage logs. Determine whether the file changed legitimately during degraded operation.

A clean follow-up scrub after repair is a useful boundary: corrected errors should be followed by another complete run that reports no new errors. Repeated corrections mean the cause is not resolved.

Build a Repeatable Verification Procedure

1. Freeze or minimize application writes and save the completed rebuild status.
2. Run the array-level scrub or consistency check and save the final report.
3. Check the trusted checksum manifest with the same algorithm and path rules used originally.
4. Validate critical application formats and compare metadata that content hashes omit.
5. Rerun the storage check after any repair and require a clean result before closing the incident.

Store the new incident report separately from the checksum baseline. The baseline should change only when content changes intentionally, not merely because a replacement drive was installed.

Save a New Trusted Baseline

After the clean scrub and file checks finish, export a fresh manifest, array report, and member inventory. Label this as the post-replacement baseline rather than overwriting the older evidence, because both versions help explain any later mismatch.

Schedule the next routine scrub and a smaller checksum sample while the incident is still recent. Early follow-up confirms that the replacement, cable path, and restored redundancy remain stable under ordinary workload.

FAQ

Is SHA-256 better than MD5 for accidental corruption checks?

Both can detect ordinary changes, but SHA-256 is the better default for a new manifest and avoids MD5’s known collision weaknesses. Consistency of the original algorithm matters when checking an existing manifest.

Can a successful scrub replace a checksum manifest?

No. A scrub verifies according to the filesystem or RAID metadata it has. An independent manifest compares the current file with a value stored outside the affected storage system.

Should every file be opened manually?

No. Hash the full protected set when practical, then perform native open or consistency tests on high-value formats and a representative sample of ordinary files.

Verification Is Complete Only at Both Layers

Close the replacement incident only after the array passes a full integrity operation and critical files match trusted external references. A healthy member count alone is not a content-verification result.