← Back to the catalog

Backup Tape or LTO Cartridge Unreadable

An unreadable backup tape or LTO cartridge is not automatically a damaged tape. The failure can be the cartridge itself, the tape drive, the read path between them, an LTFS or backup-application structure written on the tape, the backup catalog that describes what the tape contains, or an encryption key the backup depends on. Tape is sequential storage, not a disk, and it does not fail or get diagnosed the way a hard drive does — the wrong first move is writing to, initializing, relabeling or reusing the only cartridge before it is clear which of these layers actually failed.

Recovery decision

Tape or LTO cartridge unreadable: what should you do next?

Answer one question about the current state. The result suggests the safer next step rather than diagnosing the failure.

Typical source stabilityLayer-dependent

Default action riskHigh

Default first actionPreserve the cartridge

Check my situation

This guide classifies the next recovery action from observable information. It does not diagnose hardware condition or estimate a percentage chance of recovery.

First identify whether the failure follows the tape or the drive

Use the pattern of the failure as evidence, not as a conclusion:

This is evidence routing, not a definitive diagnosis. IBM's own tape-library troubleshooting documentation uses essentially this same logic operationally — trying a different, known-good, compatible cartridge to see whether a suspect drive is really at fault, and vice versa — but that testing should stop once it has told the cartridge and the drive apart; it is not a reason to cycle a fragile cartridge through many drives.

Tape is sequential storage, not a disk

A hard drive or SSD can seek to almost any address in roughly constant time; a tape drive has to physically wind past everything between its current position and the target. That has real consequences for recovery: there is no equivalent of a quick random-access scan across the whole medium, and positioning itself takes real time and real tape tension. Because tape is sequential and positioning requires physical transport, broad diagnostic reads can involve substantial positioning time and repeated media motion. On a marginal cartridge, repeated unfocused passes should therefore not be treated as a harmless diagnostic step. This also makes tape recovery a fundamentally different job from the block-device reconstruction elsewhere in this catalog — there is no member disk to image and no address space to virtually reassemble as with RAID or a storage pool; the unit of recovery is the backup set written sequentially along the tape, and it is read back and validated as such.

What the drive can report

Tape drives and libraries commonly expose status through the TapeAlert mechanism, a T10-standardized set of drive-reported flags that distinguish, among other things, hardware/media conditions from cleaning needs and drive faults. This is genuinely useful evidence — it comes from the drive itself, not a guess — but it is written from the standpoint of keeping a backup system operating reliably. TapeAlert is strong device-reported evidence, but some flags deliberately describe an unresolved drive-versus-media condition rather than a final diagnosis, so a single flag should not be read as conclusively identifying which component failed. A flag suggesting a cartridge be retired or a drive be cleaned is sound advice for ordinary operation; a recovery workflow may instead need to preserve a failing cartridge long enough to extract the one copy of data it holds, which is a different goal from returning the system to service.

LTFS and backup-application tapes are different recovery problems

LTFS (Linear Tape File System) formats a cartridge with two partitions: a small index partition holding filesystem metadata — filenames, structure, timestamps and the location of file extents — and a much larger data partition holding the file content itself. Mounting an LTFS volume means reading that index into memory first, after which the tape behaves somewhat like a browsable filesystem even though positioning to a specific file still means physically seeking to it. A cartridge written by ordinary backup software is a different situation: many backup applications write proprietary headers, sessions and backup sets sequentially, without an LTFS-style index, and rely on a separate catalog (see below) to know what is on the tape and where. A cartridge that fails to mount as LTFS is not automatically empty or unrecoverable — it may simply not be an LTFS tape at all — and a tape written by backup software should not be expected to behave like an ordinary mounted volume.

The backup catalog can be missing while tape data still exists

A missing or corrupted backup catalog is not the same thing as missing tape data. Major backup products document their own catalog-recovery paths precisely because this distinction matters in practice — a central catalog can be lost while the media itself still holds readable records, and some backup software can rebuild at least a partial catalog by reading headers directly from the tape. That is not guaranteed for every product, every version or every failure mode, and a catalog and its tape data can also both be damaged at once, or a backup can span multiple tapes with only part of the set physically present. Before treating a tape as unrecoverable because software reports no catalog entry for it, it is worth establishing separately whether the tape itself is still readable.

Encryption is a separate dependency

Backup-application encryption, hardware tape encryption, and an external key-management system can each sit on top of an otherwise-successful read. Recovering every physically readable record from an encrypted tape does not remove the dependency on the correct key or password — readable ciphertext is not the same thing as readable data. Modern tape encryption should not be treated as something recovery software can bypass or break; if the key or key-management system is unavailable, that is the actual blocking problem, separate from whatever condition the media and drive are in. It's the same key-versus-data split covered in Locked Out of an Encrypted Volume — the tape can be perfectly readable ciphertext with no usable key anywhere.

Multi-cartridge backup sets

A single backup job commonly spans more than one cartridge, and a backup application asking for “the next tape” is describing a spanning dependency, not necessarily reporting a failure. Before concluding that a set is damaged, confirm which cartridges actually belong to it and in what order, since a request for a tape that was never made or has been misplaced looks similar to a read failure from the application's point of view but is a completely different problem to solve.

What you can document safely

Record the cartridge's generation and type, its barcode or label, whether it is marked WORM, the tape drive's exact model and generation, the drive's firmware version if known, the backup software and version in use, whether LTFS was involved, whether hardware or software encryption was enabled and by what key-management system, the expected order of the media set, any TapeAlert flags or error codes and logs, the last known-successful read or write, whether the cartridge has already been tried in another known-good compatible drive, and whether any cleaning or repair action has already been attempted. None of this requires touching the cartridge further.

What changes recoverability

• Whether the cartridge has been reused, reinitialized or relabeled since the problem appeared. Subsequent writes can overwrite or supersede previously recorded regions and can reduce the amount of earlier data that remains recoverable; the effect depends on where and how the cartridge was rewritten.
• Exact drive/generation compatibility for this specific cartridge. LTO backward-read compatibility has narrowed across generations — some newer drive generations can no longer read media two generations back the way older generations could — so compatibility has to be checked for the actual hardware involved, not assumed from an older rule of thumb.
• Whether the failure has been isolated to the cartridge, the drive, or neither yet. For a cartridge with no signs of mechanical damage or unstable loading, one controlled test in a known-good compatible drive can help isolate drive versus media. If the cartridge will not load or thread normally, is visibly damaged, or produces a mechanical fault, do not use cross-drive testing as the next step.
• Whether the tape is LTFS, backup-application-formatted, or unknown. Each implies a different recovery path.
• Whether the catalog, the tape data, or both are affected. These call for different recovery approaches.
• Encryption and key availability. A key-management dependency can be the actual blocker even when the media reads cleanly.
• Physical condition. A cartridge that won't load, is visibly creased, or has exposed or damaged media should not be subjected to repeated load attempts.

The safer recovery path

This Case covers the tape and cartridge layer specifically. Where encryption is the actual blocker rather than the media, see Locked Out of an Encrypted Volume for the key-versus-data model; where the tape or drive is physically inaccessible rather than merely unformatted, professional, device-level recovery is usually the safer path · How to Validate Recovered Data · File-System Recovery vs. File Carving.