Sanitise a SCSI Disk Safely with sg_sanitize

Before you wipe a disk for good, sg_sanitize is the SCSI command that actually erases it, and there is no undo once it starts. It runs a SCSI SANITIZE operation on a deliberately identified disk, lets you select an erase method, and checks its progress. Once it starts, the disk's user data is gone and there is no undo command.

Before you begin

• Time needed: at least several hours for a block erase on a large disk.
• Versions used here: package sg3-utils 1.46-3ubuntu4, binary reporting sg3_utils version 1.15 20201223, matching the December 2020 manual page. Device, transport and firmware behaviour still vary, so check the disk documentation before choosing an erase method.
• What you need: the device path, permission to issue SCSI commands, and a current backup if the data matters.
• Before running anything: unmount every filesystem on the target, stop services that use it, remove it from any mount or storage pool, and confirm it is not a boot disk. Commands that access the device may need sudo; the examples below show it where elevated access is normally required.

Checkpoint: Do not continue until you can name the target by a stable identifier and have checked it twice. A path such as /dev/sdm can change after a reboot or storage re-scan.

1. Confirm the program and target

First check the installed implementation. This does not touch a disk:

sg_sanitize --version

sg_sanitize: version: 1.15 20201223

Now identify the disk using your normal inventory process, then inspect the selected SCSI device before any destructive command. Use sg_inq, for example, to read its inquiry strings:

sudo sg_inq /dev/sdm

Compare the vendor, model and serial information against the physical device or storage inventory, and replace /dev/sdm in every later example with the confirmed path. No reliable mapping means stop here: a successful command against the wrong disk is still a failure.

2. Choose an erase operation

The utility requires exactly one of four operation options:

• --block requests block erase and can take about as long as formatting the same disk.
• --crypto requests cryptographic erase and may be quick, because the device just replaces an internal encryption key. It cannot be reversed.
• --overwrite writes an initialisation pattern and requires either --pattern=FILE or --zero.
• --fail exits a previous failed sanitize operation; it is not an erase method for ordinary use.

For a supported disk, the simplest block erase is:

sudo sg_sanitize --block /dev/sdm

For an overwrite with zero bytes, use:

sudo sg_sanitize --overwrite --zero /dev/sdm

The command rejects an overwrite without a pattern. With a pattern file, its length is normally used as the pattern length:

sudo sg_sanitize --overwrite --pattern=/path/to/pattern.bin /dev/sdm

When a disk is reached through SCSI to ATA Translation, the manual page says an overwrite pattern must be four bytes long. Use --zero, or provide a four-byte pattern; do not assume a larger file will work through the translation layer.

3. Keep the safety pause

With --block, --crypto or --overwrite, the utility prints inquiry information and gives you fifteen seconds to reconsider. Leave that pause enabled for a real run. The --quick option skips it, and belongs only in a workflow where the device identity has already been checked immediately before execution.

Warning: Do not add --quick merely to avoid waiting. Do not use it in a copied command until you have replaced the placeholder path and rechecked the device details.

4. Decide whether to wait

By default, the SANITIZE command starts with the SCSI IMMED bit set. The utility then polls for progress every 60 seconds until progress is no longer reported. It may take hours, and a zero exit status without --wait does not prove the disk has actually finished.

To keep the command attached until completion or failure, use --wait:

sudo sg_sanitize --block --wait /dev/sdm

To return soon after the device acknowledges the command, use --early:

sudo sg_sanitize --block --early /dev/sdm

--early and --wait cannot be combined. Choose --early and you monitor the device separately:

sudo sg_requests --num=9999 --progress /dev/sdm

Warning: closing the terminal does not cancel sanitisation. The manpage states that, once successfully started, the operation continues after a power cycle until it completes. Plan for the disk to stay unavailable.

5. Verify the result and handle failures

For a waited run, check the shell status immediately:

printf 'exit status: %s\n' "$?"

Status zero means the utility reported success. Without --wait, that status may not represent the final result. Add --verbose for a short completion message, but do not treat more output as a substitute for progress monitoring.

If the device reports that a sanitize operation failed, do not start unrelated writes or recreate filesystems over it. Preserve the sense information and investigate the device documentation. The utility's --fail operation is meant to exit failure mode, typically after a preceding command set the AUSE bit; it is not a general support probe. The manual page recommends a supported REPORT SUPPORTED OPERATION CODES query, such as the one sg_opcodes provides, where the device supports it.

Recovery: there is no recovery path for successfully sanitised user data. If you must prove that a particular block changed, take care with caching: the manual page recommends direct I/O when comparing reads, using a command such as dd with iflag=direct. Treat any remaining readable data as an incident to investigate, not as permission to keep using the disk.

Done means

• Target verified. Vendor, model, serial and device path were checked before the command ran.
• Disk taken offline. All filesystems and services using it were stopped or unmounted.
• One method chosen. Exactly one supported sanitize method, with the required overwrite pattern where applicable.
• Safety pause kept. The 15-second reconsideration pause stayed on unless an explicitly controlled workflow needed --quick.
• Outcome recorded. The command was waited on or its progress was monitored, and its final outcome logged.
• Irreversibility understood. A started sanitisation cannot be undone and continues through a power cycle.