Magnetic Tape Storage

Recording geometry belongs to the format, not to the whole medium category. IBM documents LTO as linear-serpentine: the drive writes along the tape and repositions the head for the return pass. ECMA-198 instead specifies a helical-scan DDS-2 format. That standard also requires agreement on information structure, labeling and any applied processing algorithms for system-level interchange; a cartridge fitting a drive is not enough. [3] [2]

Begin with the medium, not the cartridge label. Magnetic tape holds a recording along a flexible strip; the drive moves that strip to read, write or locate data. Reels, cartridges and recording formats have changed substantially. The Computer History Museum dates the UNISERVO introduction for UNIVAC I to 1951 and describes its plated metal tape. That is a commercial-computing milestone, not the invention date of every form of magnetic recording. [6]

Modern particulate tapes also differ in their recording material. IBM Research describes barium-ferrite media and a strontium-ferrite research demonstration. Calling all tape 'rust-colored oxide ribbon' obscures those distinctions. A laboratory density demonstration is not a shipping cartridge specification. [5]

Sequential access describes a physical cost, not an inability to locate a chosen record. Drives support positioning operations, but the medium must travel to the requested location. Linux's SCSI tape interface exposes records, filemarks and positioning operations, with fixed or variable block modes. Long ordered transfers and scattered small-file restores therefore present different workloads. [7]

Retrieval order is an optimization choice, not just a streaming-rate specification. Honore, Simon and Suter optimize average request completion in a single-track model with direction-reversal penalties. Minimizing the time until every request finishes is a different objective. Their evaluation uses filtered production requests in simulation; it does not establish an optimal policy for every serpentine drive or robotic library. [1]

Keep three boundaries separate. A filemark delimits logical tape files; end of data (EOD) marks the end of the recorded user-data sequence; end of medium (EOM) concerns the usable medium boundary. IBM documents distinct filemark, EOD and EOM sense conditions. Reaching EOD does not establish that the producer wrote every file it intended to back up. [14] [15]

A filesystem view does not change the transport. IBM Storage Archive uses LTFS indexes to expose files through ordinary filesystem calls. Its index partition may also hold selected file data under a placement policy, so 'metadata partition' and 'payload partition' are not exclusive-content promises. Other tape formats can require different catalog or application software. [8]

Compatibility is a recovery dependency. The LTO Program explicitly limits LTO-10 drives to LTO-10 media, while LTO-9 drives read and write LTO-8 and LTO-9. Do not apply an old two-generations-back rule to every drive. Keep exact reader and cartridge compatibility in the recovery inventory; the LTO card covers capacities and generation details. [9]

An air gap is about access paths. IBM documents a TS4300 driveless logical library that is hidden from backup applications; administrators with two-factor authentication can retrieve its cartridges. That is distinct from ejecting media into separate custody. Controls can be stronger than simple hiding: IBM's TS4500 API documents a localSafeguarded mode requiring an on-site session to unassign protected cartridges. Evaluate the configured management path and threat model instead of assuming either universal immunity or universal remote accessibility. [10] [11]

WORM, encryption and offline custody answer different questions. WORM constrains alteration of recorded data in the supported system; encryption protects confidentiality through control of the decryption keys; disconnection restricts electronic access while maintained. IBM's encrypted-recovery guidance warns that lost key-manager keys prevent decryption. CISA separately calls for offline encrypted backups and regular recovery testing. None of these controls substitutes for the others. [4] [13] [12]

Practical recovery planning follows the whole chain: readable medium, compatible drive and host connection, interpretable recording format and catalog or index, available keys, then application validation. Include cartridge retrieval, loading, positioning, transfer and validation in a restore exercise. This checklist is an engineering synthesis of the documented dependencies, not a measured recovery-time guarantee. [9] [8] [13] [12]