The Hardware Behind a Backup Ransomware Can't Encrypt

A nightly backup job that reports success answers one question — did the data get copied — and leaves several others open: can it be restored inside the time the business can tolerate being down, is the copy itself intact, and was it reachable by whatever compromised production in the first place? Ransomware response postmortems keep surfacing the same gap: backups existed, the job logs looked clean, and the restore still failed or took days longer than planned, because nobody had rehearsed it end to end.

The specific failure mode that matters for hardware buying is reachability. If the backup repository is managed from the same console, joined to the same domain, or addressable from the same subnet as production, an attacker with administrator rights on one has a path to the other. Segmentation and credential separation matter as much as the storage itself, but the storage layer is where those controls get enforced or bypassed — a backup target with its own isolated management plane closes a door that firewall rules alone tend to leave open.

Immutable storage — commonly implemented as WORM (write once, read many) at the array level, or object lock on S3-compatible object storage — sets a retention timer on written data that nothing short of physically destroying the media can shorten. Once a backup lands and the lock engages, no login, including an administrator account or the array's own management API, can delete or overwrite it before the retention period expires. That's a meaningfully different guarantee than a permissions-based "read-only" flag, which a sufficiently privileged account can simply reverse.

The trade-off is that immutable storage is still online and still on the network — it is unrewritable, not unreachable. A determined attacker who compromises the array's management plane before backups are written, or who has enough time to wait out shorter retention windows across a rolling set of copies, can still cause damage. That's why immutability and an air gap are treated as a pair rather than alternatives: immutability defeats the fast, opportunistic case, and isolation covers the situation where the attacker has more time and more access.

An air gap, in its strictest and most reliable form, means physical separation: media that is disconnected from any network once it holds data, full stop. A tape cartridge ejected from a drive and racked in a vault has no listening port, no IP address, and no credential an attacker could use against it — it simply isn't a target while it sits on the shelf. That property is why tape, despite being the oldest technology on this list, hasn't been displaced from serious backup architectures.

Where a true offline air gap isn't practical for every copy, a "logical" air gap on disk narrows the same exposure: a replication link that opens on a schedule and stays closed otherwise, or a target with no standing credentials and a separate authentication domain from production, so a compromise of the primary environment doesn't hand over a usable path to the backup. It's a real mitigation worth deploying, but it's a narrower guarantee than a cartridge that isn't plugged into anything.

Current-generation LTO tape holds more per cartridge than most buyers expect: an LTO-9 cartridge is rated at 18 TB native and roughly 45 TB compressed, and the drives, autoloaders, and libraries that write to it remain an active product line. The catalog carries LTO-6 through LTO-9 drives and media, including cartridges explicitly rated for WORM writes, so a single tape can serve as both the immutable and the offline copy at once.

An autoloader adds unattended capacity without adding attack surface: a magazine of cartridges cycles through a single drive on a schedule, and finished tapes can still be pulled and shelved for a true offline copy once the write completes. A 9-slot LTO-9 autoloader can carry upward of 160 TB of native capacity in a single rack unit before a cartridge is ever ejected — real headroom for a retention window measured in months rather than days.

An immutable or air-gapped copy proves the data survived. It doesn't answer the next question, which is where it gets restored to and how long that takes. Restoring straight back onto compromised production storage isn't an option until that environment is rebuilt and cleared, which can take days on its own — and running the restore, along with the workloads it brings back online, needs storage that is physically separate from whatever just got attacked.

That's the role of a dedicated recovery target: a storage array — sometimes disk, sometimes a hyper-converged appliance — sized and provisioned in advance to receive priority systems and get them running while the primary environment is still being investigated and rebuilt. Uniqcli's storage-arrays catalog runs from compact NAS units up through purpose-built appliances rated for hundreds of terabytes of installed capacity, any of which can be staged as that target. What we supply is the hardware and the sourcing behind it; standing up the recovery runbook, or running incident response on the compromised side, is work for the buyer's own team or their IR partner.