RAID, Thin Provisioning and Snapshots: Deletion Scope

Short answer

Deleting a file, overwriting a logical volume or discarding thin-provisioned blocks does not establish that every copy of the target data in a storage system has been sanitized. RAID, snapshots and thin provisioning introduce different relationships between the address space you see and the physical storage that can retain information.

Start with a map of current volumes, historical versions, shared storage and physical assets. Select a deletion or sanitization procedure for each required scope. Do not destroy a shared pool to solve one tenant's deletion request, and do not release physical drives on the strength of a logical-volume operation alone.

Who this is for

This is a scope-planning runbook for authorized storage administrators, ITAD teams and reviewers approving volume reassignment or hardware release. It explains why a clean logical view can coexist with outstanding data-disposition work elsewhere.

The implementation examples are Linux device-mapper thin provisioning, classic device-mapper snapshots and dm-raid documentation, reviewed at a pinned upstream revision on October 28, 2026. These examples are not commands for a proprietary storage array. An array's snapshot, cache, replication and secure-delete behavior must be qualified against its exact product and software version.

When to use this

Use this workflow before retiring an array, reassigning a logical volume, deleting a tenant's storage, or replacing drives that have held sensitive information. It is particularly useful when a report says “the volume is empty” but the intended outcome is “all released physical media has been treated.”

Define the disposal object first. A filesystem, a virtual disk, a pool and a set of physical members are distinct objects. Write the intended recipient and confidentiality boundary into the job so that a successful operation on one object does not silently close work on another.

When not to use this

Do not issue pool, snapshot or member-level destructive operations while ownership, retention or shared dependencies remain unresolved. A snapshot may be the remaining recovery point for an application that still needs it. Conversely, retaining it may prevent the deletion scope from being complete. Resolve that conflict explicitly with the information owner.

Do not detach a RAID member, wipe metadata or remove a thin-pool definition to make the inventory look simpler. Those changes can break service without establishing that the underlying information has been removed. This guide provides a planning workflow, not a generic array teardown script.

Workflow

1. Write a copy-and-component map

Create a restricted table of objects and relationships. Include the active volume, snapshots, clones, shared base images, replicas, backup copies, underlying pool, current members, spares, previously removed members and any persistent cache that falls within the asset scope. Mark each row as confirmed, excluded by an approved boundary, or unresolved.

Record the evidence used for each relationship: storage inventory, snapshot catalog, physical asset record or product-specific architecture description. Do not assume that every listed component necessarily contains the same user data; the point is to determine which ones require action, not to assert that all components always hold complete copies.

A useful row includes object identity, owner, software version, relationship, target-data scope, proposed disposition and acceptance evidence. Keep live customer identifiers out of a public example.

2. Separate RAID layout from sanitization

RAID describes how data and redundancy are organized. For example, dm-raid distinguishes striping, mirroring and parity layouts. None of those layout names is itself a sanitization result.

For physical release, inventory every relevant member and trace its disposition individually. Do not infer a sanitization outcome from a removed array definition or a healthy rebuilt array. A drive removed before the final logical overwrite was not necessarily part of that overwrite. A replacement drive's clean state says nothing about the earlier removed asset.

Treat a member that cannot be read or addressed as an exception, not as blank media. Preserve its custody while selecting the approved disposition. If the job only reassigns a logical volume inside a retained system, document that narrower boundary instead of claiming all physical members have been sanitized.

3. Identify the snapshot mechanism

Classic device-mapper snapshots preserve older chunks in a separate copy-on-write device when the origin changes. An overwrite of the current origin can therefore leave the older snapshot view intact. That is expected version preservation, not evidence that the overwrite tool malfunctioned.

Device-mapper thin snapshots instead share data blocks between logical devices and can be nested. Do not treat a snapshot as merely a shortcut name for the current volume. Inspect the applicable snapshot relationships and identify retained versions that remain inside the requested deletion scope.

For a fictional example, a current volume and two earlier snapshots are three logical views to account for. Overwriting the current view does not, by that fact alone, close the two historical-view rows. This is a scope illustration, not a measured reconstruction experiment or a count of independent physical copies.

4. Keep discard distinct from physical erasure

The thin-pool no_discard_passdown feature removes mappings without passing discards to the underlying data device. The ignore_discard feature disables discard support. These implementation choices make it unsafe to infer lower-layer treatment solely from a request made at the top of the stack.

Record the actual discard configuration and lower-layer support rather than assuming the default. Even successful space reclamation is an allocation observation; it is not an accepted physical-media sanitization result. A reduction in pool usage does not explain what happened to inaccessible areas of an SSD or to another retained copy.

Do not change discard settings as a substitute for a deletion plan. Such changes affect storage behavior and can have dependencies outside the single target volume. Use the installed platform's supported administration procedure and evaluate the intended confidentiality outcome separately.

5. Choose the operation at the correct boundary

For a logical reassignment, identify exactly which active and historical views must stop exposing the target data. Determine whether a product-supported selective deletion process can satisfy that boundary while preserving unrelated owners' data. If evidence is insufficient, retain restrictions and escalate; do not quietly redefine the target as only the visible files.

For hardware release, plan the physical assets and other relevant nonvolatile components through approved device-specific or physical disposition methods. A command to a virtual disk cannot be assumed to reach all retained versions, free pool space, removed members or controller storage.

For cryptographic deletion, separately map the encryption scope and key dependencies. A snapshot may share an encryption domain; a key may still be required by other data. Deleting a key without resolving those relationships can destroy unrelated access, while keeping an overlooked usable copy can defeat the intended outcome. See the key-copy and recovery-path guide.

6. Define acceptance evidence before execution

Specify what record will demonstrate completion for each scope row. That may be a product-supported logical deletion result, a snapshot disposition record, an individually attributed drive sanitize result, or a physical-treatment record. Do not collapse these different artifacts into one generic green status.

Require final results and exception handling, including missing assets and interrupted work. A job manifest with ten in-scope objects and nine accepted outcomes still has an unresolved row. Counting logical views and physical devices together as if they were equivalent can also mislead; use counts appropriate to the decision.

NIST SP 800-88 Rev. 2, September 2025, treats target-data scope and acceptance as central concerns. A technically completed operation may remain insufficient if the target was defined too narrowly. Keep the scope decision visible throughout review.

Verification checklist

• Is the request about a logical reassignment, selective data deletion, whole-system retirement or physical release?
• Are active and historical views identified, with unresolved dependencies listed?
• Are thin allocation and discard behavior documented for the installed implementation?
• Does each physical asset requiring release have attributable treatment evidence?
• Are shared owners, retained copies, key dependencies and exceptions resolved or explicitly restricted?
• Has a reviewer accepted the result for the stated boundary without expanding the claim?

Verification note: evidence requirements

No array, snapshot, logical volume or physical device was modified or examined for this article. The Linux examples explain implementation boundaries; the invented view and count examples illustrate recordkeeping. An actual job requires observed topology, exact product versions, supported procedure semantics and final results. A zero-filled logical read or successful discard cannot prove erasure of inaccessible physical locations.

Resale and evidence checklist

Bind released hardware to physical identifiers and accepted disposition records. Include previously removed or failed members that remain part of the job. Keep unresolved assets segregated. If only a volume was reassigned within a retained system, describe that result accurately rather than issuing a whole-array release claim.

What not to publish

Keep customer names, volume identifiers, replication locations, key hierarchies, raw storage maps and recovery information restricted. A public process summary should describe boundaries and exceptions without disclosing the environment it protects.

Common mistakes

Common errors include treating RAID initialization as an erase certificate, assuming an origin overwrite removes snapshots, equating free space with sanitized space, and forgetting removed drives. Another error is deleting shared infrastructure before determining whether the task concerns one owner's data or the entire storage system.

Do not use a recovery failure from one logical view as proof that all copies are gone. State the observation layer and what the result actually establishes. The coverage accounting model can help expose incomplete records, but its fraction is not a probability of irrecoverability.

CliDeck workflow fit

A repeatable runbook can keep the target map, operator actions, authoritative tool results and reviewer decisions together. Preserve the evidence record separately from the storage being retired. This is an operational pattern, not a claim that CliDeck currently implements array-specific deletion, snapshot traversal or certified wiping.

FAQ

Does overwriting the current volume remove every snapshot?

No such conclusion follows from the current-volume result. Identify the snapshot mechanism and process every in-scope retained view through its supported disposition path.

Does discard mean the physical drive was sanitized?

No. Discard behavior depends on the stack, and allocation changes do not establish every lower-layer confidentiality outcome.

Must I destroy a shared pool for one deletion request?

Do not make that assumption. Determine a supported selective method and its evidence first. If the required scope cannot be established, keep the case unresolved and obtain an authorized disposition decision.

Related guides

See SCSI/SAS target and completion checks, SSD translation-layer coverage, and the sanitization process guide.