Software that lets the media underneath change without the applications above noticing.

Strip away the naming and the work divides into six jobs.

It presents an interface. The archive appears as an SMB share, an NFS mount point or an S3 bucket. Applications write to it the way they write to any other target, with no API integration and no operator in the loop.

It maintains a namespace. A file has one path. That path is what users, scripts and applications remember, and it does not encode which cartridge or platter the data currently lives on.

It classifies data against attributes the storage layer can see for itself: creation date, last access, last modification, size, extension, owner. No content analysis, no tagging effort from users.

It applies policy to those classes. Copy, move, migrate with a stub left behind, or delete. Triggered by high and low watermarks on the cache, or on a schedule.

It stages recalls. A read against archived data pulls the copy back into a flash or disk cache and serves it from there, so a second read within the retention window of the cache is fast.

It records what happened. Media location, copy count, offline cartridges held outside the library, retention state, legal hold, checksums taken at ingest and compared on read. This catalogue is the archive's memory.

Everything a product brochure says about tiering, replication, WORM behaviour or cloud gateways is a variation on those six.

Most deployments use two or three of these components. Almost none use all of them, and a proposal that includes everything is usually a proposal nobody has scoped properly.

Archive Manager also supports an optimised proprietary tape format alongside LTFS. That choice is worth making deliberately, because it trades portability for behaviour, and it is difficult to revisit once several thousand cartridges are written.

When a policy migrates a file, the archive keeps the path and replaces the local object with a stub: a small placeholder that holds the metadata and a pointer into the catalogue, not the data. Directory listings still show the file. Size and timestamps still look right. What has gone is the payload.

An application that opens that path issues an ordinary read. The archive software intercepts it, looks the file up in its catalogue, finds which volume and which medium holds a valid copy, mounts or fetches it, stages the data into cache, and completes the read. The application waits. It does not fail, it does not receive a different path, and it never learns which medium was involved.

That indirection is the whole point, and it is what makes a media change survivable. Migrating from LTO-7 to a later generation, or from an ageing optical library to object storage, becomes a background operation: read from the old copy, write to the new one, update the catalogue entry, retire the old media. The path an application holds is unchanged throughout, because the path was never a description of where the data was.

Two consequences follow. First, the catalogue is the archive. Lose it without a protected copy and you hold media whose contents you cannot locate. It needs its own backup, its own restore rehearsal, and a documented recovery procedure. Second, applications must tolerate a slow open. Most do. Some, particularly older clients with short timeouts, do not, and that is a compatibility question to settle in a test before it becomes a support call.

Front-end access is SMB, NFS and S3, with HTTP and FTP also listed. Behind, the archive addresses tape libraries over FC or SAS, object and cloud targets over HTTP, and disk arrays as ordinary storage. See tape and LTO systems and archive storage systems for what usually sits at that end.

In practice three integration patterns cover most GCC deployments. Backup platforms write to the archive as an on-premises S3 target or an NFS repository, taking long-retention copies out of the primary backup estate. Media asset managers and video systems treat it as a tier and issue restores through it. PACS and other clinical or document systems write studies and records to a share and expect them back on demand, which places the recall latency question in front of a clinician rather than an administrator. QStar documents transparent integration with document, DICOM, audio, video and database archiving applications, but the specific application and version pairing is something to validate per engagement rather than assume.

Recall latency is a property of the medium. Robotic mount, seek and stream from tape takes what it takes, and no namespace layer removes it. Software can hide the mechanics and it can cache intelligently. It cannot make cold media behave like flash, and a design that quietly assumes otherwise will disappoint its users in the first month.

It is also another supported component in the stack. It needs patching, licence continuity, a maintenance contract and a person who understands it. That is a real operational cost, set against the cost of the migration projects it prevents.

Software-enforced retention is enforced by software. It resists accidental and casual deletion well and is designed to prevent early removal, but it lives in the same trust domain as its own administrators. Where that matters, combine it with write-once media as covered in long-term data archiving.

Finally, versions and compatibility. Supported operating systems, library models, drive generations and cloud endpoints move between releases. Aban Smart validates the specific combination against current manufacturer documentation for each engagement rather than publishing a matrix here. The manufacturers we work with are listed on partners, and the wider technologies overview shows where this layer fits. For a scoped configuration, request configuration and pricing.