Interrupted Sanitization: Recover Evidence Before Retrying
Short answer
After power loss, a host crash or a disconnected management session, keep the media in controlled custody and reconcile its identity, operation and current device status before retrying. A lost progress window does not establish that sanitization stopped. A responsive drive does not establish that sanitization finished. Record the outcome as unresolved until the evidence supports a more specific decision.
For NVMe, distinguish completion of the command that starts sanitization from completion of the background operation. Read the appropriate Sanitize Status log for the intended target, preserve its full response and interpret it using the supported specification and firmware documentation. Do not turn a recovery action into a sanitization certificate.
Who this is for
This guide is for authorized ITAD, refurbishment and storage operations teams recovering an interrupted data-removal job. Its central task is deciding whether the original job can be accepted, must remain pending or needs an approved new attempt. It does not provide a universal command for restarting erasure.
The concrete command examples are read-only observations documented by Linux nvme-cli v2.15. Protocol interpretation was reviewed against NVM Express Base Specification 2.4, ratified July 31, 2026. That specification includes capabilities older devices and tools may not implement. Your drive's advertised revision, exact firmware and supported features determine what applies. SATA Security Erase, SCSI SANITIZE, host overwrites and vendor utilities need their own interruption procedures; NVMe behavior must not be transferred to them.
Verification note: These are recovery and acceptance criteria based on documentation review. No power interruption experiment, drive sanitization or hardware validation was performed for this article. Examples contain no observed device output.
When to use this
Use this workflow when a sanitization job loses its terminal, the processing host restarts, power disappears, a controller stops responding or the evidence recorder fails before the final result is saved. Also use it when a job tracker says failed while the device still appears busy. Those two reports may describe different layers of the same incident.
When not to use this
Do not use this article to declare an unidentified drive clean, recover customer files or work around a missing authorization. If the device is physically unsafe, unstable or required for incident investigation, obtain the relevant handling decision before reconnecting it. A recovery checklist cannot substitute for model-specific vendor instructions or the information owner's release criteria.
Name the interrupted layer
Write down what actually disappeared. Losing a browser tab, losing a host process and losing device power are separate events. A screenshot of a frozen progress bar cannot distinguish them.
For a host-driven overwrite, the writing process and its checkpoint record matter. For a device-managed operation, the host can lose contact while the device maintains its own operation state. NVMe defines continuity of sanitize processing across relevant resets and power cycles; this does not justify promising uninterrupted progress, an unchanged time estimate or successful completion on faulty hardware. Observe the recovered state instead of inferring it from the outage alone.
Separate four timestamps: the start request, the last saved observation, the interruption report and the first observation after access returns. If one is unknown, mark it unknown. Device clocks and host clocks may differ; preserve the clock source and timezone rather than silently combining their values into one precise-looking timeline.
Workflow
1. Freeze the asset's release decision
Mark the asset unavailable for shipment, reuse or reassignment while the result is unresolved. Preserve its approved handling boundary. Do not put it into a production workload merely to see whether normal I/O works, and do not format it to make a test filesystem.
Retain the original job identifier, method, requested scope, parameters, operator authorization, tool version and available response. Record which evidence is missing. A new attempt should be linked to this attempt, not used to overwrite its history.
2. Reconcile physical identity before the device path
After a host restart, a name such as /dev/nvme0 is only a current path. Match the asset label and expected serial/model to the detected controller. Account for adapters, multiple controllers and namespaces. Stop if identity is ambiguous or if the recovered topology differs from the approved target.
The following commands are inspection examples for nvme-cli v2.15 on Linux. /dev/nvme0 is a placeholder: substitute the verified controller path. Check the installed command help before running them; output and available options can differ between tool generations.
nvme version
sudo nvme list -v
sudo nvme id-ctrl /dev/nvme0 -H
Capture the controller identity and firmware together with the host-side asset mapping. Reading an Identify response is useful evidence of the device reached through that path. It does not demonstrate that erasure covered the intended media.
3. Save the status before changing the state
For the v2.15 interface, read and preserve both a human-readable interpretation and the underlying returned data where your evidence system supports it:
sudo nvme sanitize-log /dev/nvme0 -H
sudo nvme sanitize-log /dev/nvme0 -o json
These are log retrieval commands, not requests to start another sanitize operation. A successful read establishes that the query succeeded; its contents determine what it says about sanitization. Save command errors and stderr as well as stdout. An empty file created by shell redirection is not a successful observation.
Upstream development documentation now describes nvme log sanitize and treats sanitize-log as an older-name alias. That is a reason to bind the runbook to the installed version, not to assume an upstream example works on every packaged build. Preserve complete fields rather than making an automation depend on a label copied from another release.
4. Classify the evidence, not just the exit code
The following are recommended workflow labels for an operator's job record. They are not names of NVMe protocol states or a new sanitization standard.
| Evidence available after the incident | Job label | Next decision |
|---|---|---|
| No trustworthy status for the identified target | Unresolved | Keep custody; restore a supported observation path |
| Device reports an operation in progress | Pending | Monitor under the approved procedure |
| Device reports the relevant operation failed | Failed attempt | Preserve failure details; obtain a recovery decision |
| Device reports successful completion, with correct scope and linked attempt | Completed, awaiting review | Evaluate acceptance criteria and anomalies |
| Designated reviewer accepts the evidence and remaining scope | Accepted | Release only for the authorized disposition |
NVMe's Sanitize Operation Status occupies a subfield of SSTAT; the whole field also contains other information. Do not compare a complete SSTAT word with one small status value. Decode the applicable fields, and retain the raw response for review. A progress value alone is insufficient. Newer implementations can also expose Media Verification and related state information; absence of a field in an older tool is not evidence that the feature ran or was unnecessary.
5. Match the recovered result to this job
A status describing the most recent operation needs a timeline and a scope. If the original request was rejected, a previously successful result must not be attributed to the rejected request. If someone issued a second operation while the first record was incomplete, preserve both attempts and determine which result is being observed.
For NVMe, subsystem and namespace sanitization are distinct scopes in the current specification. A namespace result must not silently replace the subsystem result your original job required. Equally, a subsystem operation does not remove independent backups or copies on another device. Resolve those scope questions before asking whether a retry is necessary.
6. Authorize recovery separately from acceptance
Do not repeatedly power-cycle a busy device to make the interface responsive. Do not issue a new destructive command simply because the host job timed out. First determine the vendor-supported recovery path and whether any operation is still active. Capture available evidence before an approved action changes it.
NVMe Exit Failure Mode is a recovery action, not another erase pass or proof that the failed attempt removed its target data. Its applicability depends on the operation's mode and current state. An operator who restores access must still resolve the failed sanitization result. Likewise, a firmware update is not an evidence-preserving first step just because support may eventually recommend it.
If reliable access cannot be restored, retain the failed/unresolved disposition. Escalation can lead to another supported method or approved destruction, but a device that cannot return status must not acquire an accepted result by default.
An example of honest incident reconciliation
Consider an illustrative job whose terminal disconnects at 14:10. The recorder last saved an in-progress response at 14:08. At 14:20 an authorized operator reconnects, confirms the same asset and obtains a successful-completion response consistent with the original request. These invented times illustrate record keeping; they are not a test result.
The record can say that the interruption was observed at 14:10 and successful completion was observed at 14:20. It cannot claim an exact completion time of 14:10, or state that power loss occurred merely because the terminal disconnected. The reviewer still checks method, target, anomalies and policy before acceptance.
If the 14:20 query instead fails, record that observation failure. It does not convert the earlier in-progress response into a device-reported sanitization failure, and it does not prove completion. Keeping those distinctions preserves a useful record for the next operator.
Verification checklist
- The detected media identity matches the physical asset and original job.
- The interrupted layer and clock sources are recorded without invented timestamps.
- The original request, method, parameters and scope are preserved where available.
- Current device status is saved with tool version and query errors.
- Completion evidence belongs to the intended attempt and sanitization target.
- Anomalies, missing fields and any recovery actions remain visible.
- A separate acceptance decision resolves the information owner's criteria.
NIST SP 800-88 Rev. 2, published in September 2025 and superseding Rev. 1, distinguishes verification of the operation's outcome from validation of its effectiveness. A returned success result contributes evidence; it does not settle suitability or residual confidentiality risk by itself. An interruption is an anomaly to assess, not a reason to skip that decision.
Resale and evidence checklist
Keep the asset unavailable until its authorized disposition is decided. Attach the interrupted attempt, recovered observations, any subsequent attempt and the reviewer decision to one asset record. Record missing evidence explicitly. Preserve an unresolved or failed status when acceptance is unsupported, even if the drive enumerates and appears usable.
What not to publish
Keep customer identifiers, serial numbers, internal paths, raw security material and captured device responses in the approved evidence system. Public examples should explain interpretation without exposing customer data or presenting fabricated logs as real execution.
Common mistakes
Common errors include treating a command's return as background completion, resubmitting erasure without first reading status, accepting an old result for a new attempt, confusing a namespace with a subsystem and replacing failed-attempt history with a later success screenshot. Another error is assigning a pass because a host-visible sample is blank: that observation cannot establish cleanup of inaccessible physical regions.
CliDeck workflow fit
An interruption runbook should put identity checks and evidence capture ahead of state-changing recovery steps. Store the stop conditions and reviewer handoff alongside the operator's command list. This is workflow guidance, not a claim that forthcoming CliDeck wiping software supports a particular device, recovery feature, certification or automatic acceptance decision.
FAQ
Does closing the terminal cancel sanitization?
It depends on what was running. A device-managed NVMe sanitize operation is different from a host process performing writes. Determine the interrupted layer and query the supported device status; a closed window alone does not answer the question.
Can a drive be released after Exit Failure Mode succeeds?
Restored access is not an accepted data-removal result. Preserve the failed attempt and follow the approved method and review process before release.
Should a missing completion log trigger another erase immediately?
First establish identity, active state and scope. A new request can complicate the evidence or be rejected while another operation remains active. Obtain the supported recovery decision instead of using repetition as a substitute for diagnosis.