Oxford Style Debate – Episode 2: Tape Is Dead. Or Is It? Let’s Debate.

I challenge ​@jos.maliepaard 

Tape is the new cloud!!! 

Tape is actually quite fast for sequential writes, and when you have multiple drives streaming, you can bring back 100's of TB’s very quickly.  LTO10 is no longer running on 8Gb FC connections and has had a recent upgrade as well as running at 400MB/s and can store 40TB of raw data (100TB compressed)

The cost for Tape is significantly lower than storage, and if you are keeping data for many years, you will not have to migrate production storage as frequently.

Cloud archives are great, but I actually control my data with tape. What happens when there is an outage, security breach, or you need to pull your data back on prem quickly? Tape is right there waiting for you.

I can export tape for a REAL immutable copy. There is no back door to SSH into tapes exported from a library. Someone can sit on your network and blow away the storage or server running your immutable copies via a management port if things are not locked down.  The word is “AIRGAP” because there is air between your tape and the machine the attacker could get their hands on. 

With extreme retention policies, in the multi PB scale, when a cloud archive provider decides to increase their prices, the egress charges will be HUGE!!!!. There is no lock in with tape.  I can move that data and bring it back as I choose without receiving a huge bill.  Migrating an entire LTO pool is easy if you have the right software to skip a few versions of LTO for your next evergreen. 

Libraries are fun to watch the grippers grab the tapes and move them around. 

If I needed to seed data or bring up my servers at another location, a suitcase full of tapes weighs a lot less than a SAN.  It’s also faster to drive 1PB of tapes across the city than download it from the cloud or ship over the network. 

Tape libraries are rock solid and rarely have issues in the enterprise world. I receive many more email alerts from a specific cloud platform talking about outages or potential outages than my tape libraries send me. 

Who is going to be the outlier this time? I actually have very strong arguments for both sides despite leaning towards the “against side more - tape is not dead). 

Who is going to be the outlier this time? I actually have very strong arguments for both sides despite leaning towards the “against side more - tape is not dead). 

I was considering going the other way. I have a bunch of things I could argue both ways on this one so it’s a good topic to choose. 

Who is going to be the outlier this time? I actually have very strong arguments for both sides despite leaning towards the “against side more - tape is not dead). 

 

I was considering going the other way. I have a bunch of things I could argue both ways on this one so it’s a good topic to choose. 

Do it, Scott🤞 There are too many against! It’s a debate and there isn’t a wrong or right answer. I might swing ‘for’. 

Well ​@Iams3le & ​@Scott ...it will be MEEEE this time! 💀

I haven't used tape in quite some time, almost 20yrs ago actually. When I did, it was on the tail end of being retired within the org I was working for at the time, so I'll admit I don't have much hands-on experience with current Tape technology.  As such, my perspective comes moreso from practical experience with current Backup technologies rather than direct expertise in implementing Tape. That said, I am still FOR the statement "Tape is Dead". My reasons are given below…

First and foremost is simplicity. Using Tape requires specialized hardware as well as the knowledge and expertise to deploy and maintain it, thus adding unneeded complexity. Additionally, while Tape Cartridge themselves may be cheaper, that cost advantage is significantly reduced when you factor in Tape hardware, maintenance, drives, administration, etc. to manage the environment. Also, disk costs have significantly reduced over the years narrowing any cost gaps between disk & Tape. I certainly believe in a defense-in-depth approach to security, but most of the arguments advocating for Tape can essentially be done with disk or object storage without the complexity. I'll touch on some of these in my other points below.

My second argument FOR is the flexibility disk & object storage offer. Unlike Tape, you're not tied to a specific physical medium or dependent on vendor-specific drivers for operability (Tape Devices > Tape Servers). And, within Veeam, Disk/OS allow orgs to fully implment the 3-2-1-1-0 rule without the limitations shared that Tape has → Backup verification using SureBackup for one. Even more important in my opinion, Disk/OS does support Instant Recovery for significantly quick restores.

My third argument is security. Disk & object storage both offer sound immutability capabilities to satisfy many regulatory and compliance requirements, while also protecting against ransomware. An argument can be made physical compromise to a system (immutable Repository) can still render data unusable by wiping disks, etc; but by the same token, physical access to Tape media can occur leading to the same outcome. I think for both options (Disk/OS and Tape), the physical access argument is really quite negligible. Michael shared above Tape can be portable, enhancing its air-gap capabiltiy. I would argue modern Backups using Disk/OS are as well, by using Cloud-based solutions, Copy Jobs, Replication, etc, but without the need for manual transport intervention. Tape is seen as a true air-gap solution. And rightfully so. But, there are similar alternative solutions with disk. For example, Backups can be targeted to a remote physical Linux hardened repository, then a cron job can be run to disable the switch port to the Repo until Backups need to run again, essentially making the Repo and its Backup data "air-gapped".

My fourth argument is stability. Disks do have moving/spinning parts (non-SSDs) and wear out. But likewise, tape cartridge re-use can also cause wear and tear potentially leading to either decreased data integrity or even damage.

Lastly my fifth agument that Tape is Dead is performance. I know I covered this a bit already, and was shared by others, but Disk/OS-based restores provide significantly faster recovery times to help orgs meet their RTO SLAs. Depending on the business, those SLAs may be quite aggressive and needed. Couple this with the simplicity argument I started with in that sometimes staging data on Tape to disk might be needed before data restore can take place, again adding complexity, and further delaying getting a business back up & running in a timely manner.

In all honesty, I'm not at all against Tape and certainly recognize and understand all the benefits and arguments made for it (and AGAINST the argument Tape is Dead). But, for businesses I've worked in, the added complexity and operational overhead far outweigh what I see as minimal benefits Tape can provide.

So there ya have it. 😉

Alright…since others I wanted to tag have already commented or were tagged, I'll tag someone I think who can provide some sound arguments FOR or AGAINST. Hey ​@leaha … what is your take on this Tape argument?? 🤔

Thanks for the challenge ​@Michael Melter - great write up by the way!

I understand the intent here is to challenge perspectives, but I’m aligned with your view, particularly on the point around ransomware resilience.

With ransomware front of mind, many of the customers I work with are still using tape due to its ability to provide a true offline air gapped solution against ransomware attacks. Short of someone gaining access into a secure offsite storage facility and accessing the physical tape, the data cannot be compromised - something that is not possible with more modern online solutions.

Sending the challenge back over to Germany again with ​@Dynamic 

Tape is not dead. In many enterprise environments, it remains one of the most effective and cost-effective defences against ransomware.

The reason is simple: a disconnected tape drive creates a true physical air gap. If an attacker compromises the infrastructure, they cannot encrypt data that is inaccessible from the network. Many object storage solutions and deduplication appliances offer immutability, but they remain online systems that still require proper configuration and management.

Furthermore, for long-term archiving and large volumes of data, the cost per TB of tape remains extremely competitive, especially given its virtually zero energy consumption when idle.

Another often-overlooked advantage is the ability to store copies at highly secure remote sites: certified vaults, bunkers or facilities designed to withstand fire, flooding, infrastructure failures and other disasters. This adds a further layer of physical protection that many online solutions cannot guarantee with the same ease.

And let’s dispel a myth: modern tapes are no longer synonymous with extremely slow restores. Current-generation LTO drives offer high capacities and transfer speeds that are more than adequate for many disaster recovery and archiving scenarios. Admittedly, they do not have the random access speed of online storage, but when it comes to restoring large amounts of data, their performance is often better than many people expect.

P.S. Even though I’m not a fan of this technology 

Thanks ​@Scott 

Tape is Dead!

A lot of arguments are already given, but I do have some additions to my fellow FOR people.

Handling:

Tapes should be removed when written. When leaving them in the library they are still vulnerable and NOT airgapped

Storing tapes is not easy, should be labeled properly (especially for longer retention periods) so they are easy to find back when needed.

Storing location is important, offside but than there is are risks when moving the backups to another location, anything can happen. I've seen them on shelves in an office location in a simple closet, or at a home location of an administrator. physical acces to backup media is the weakest point of immutability. In a datacenter access is controlled, but what happens if the tapes leaves the datacenter. 

Tape libraries need their maintenance, cleaning tape. compatibly over time. yes you can read from 2 versions back on LTO, but still with very long retentions this can be an issue

Price per stored TB, a tape has maybe the lowest price per TB, but it doesn't have any space optimization features. With a longer retention scheme maybe 99% of the data is written multiple times to tape. A optimized disksystem could be cheaper in the end per (price per unique stored TB vs tape handling cost by third party)

And one of the more important argument is backup verification feature like healthcheck, malware scanning and Surebackup (and instant-VM recovery). A backupfile written to tape is never checked again. and backup are nice, but if you can't recover them, they are useless. You never know if the backup is recoverable or clean from malware.

Modern Object Storage solutions have Absolute Immutability that's third party tested ;) and are the more up-to-date way of storing long-term retentions with all the advanced feature to make sure your data is recoverable in a clean state.

Great points, Shane. I actually agree with a lot of what you said, especially around simplicity, operational restores and RTO.

If the discussion is about day-to-day recovery, I would not choose tape as my first option either. Disk and object storage are clearly better for Instant Recovery, SureBackup, granular restores and fast operational recovery.

But that is exactly why I still don’t see tape as dead.

For me, tape is not competing with disk or object storage in the performance tier. Tape has a different role: it is the last line of defense when the environment itself is no longer trusted.

The point about complexity is fair. Tape needs hardware, handling, rotation, cataloging and people who know what they are doing. But in real environments, I have also seen “modern” solutions become complex very quickly: object lock configuration, lifecycle policies, permissions, API keys, MFA, compromised admin accounts, clock dependency, network exposure, repository OS hardening, patching, monitoring, and so on.

So yes, tape has operational complexity. But disk and object storage have logical and administrative complexity. Both can fail if the process around them is weak.

About security, I agree that immutable disk and object storage are very strong options. I use them and I like them. But I still see a difference between “immutable and reachable” and “offline and unreachable”.

A hardened repository with the switch port disabled is a clever approach, but it still depends on automation, network configuration, credentials, and the assumption that the attacker did not compromise the control plane around it. With exported tape, the attack surface is simply different. There is no API, no SSH, no lifecycle policy, no repository OS, no exposed management interface and no active network path.

Of course, if someone has physical access to the tapes, that is also a risk. But that becomes a physical security and media handling problem, not a remote compromise problem. That distinction matters a lot during ransomware recovery.

I recently worked on a ransomware recovery where tape was not the fastest option, but it was the option that survived. The value was not performance. The value was having a copy outside the compromised ecosystem.

So I don’t think tape should be used as the main restore platform. I don’t think it replaces disk, object storage or dedupe appliances. And I definitely agree that for aggressive RTOs, tape alone is not enough.

But dead? I don’t think so.

Tape is slower, less flexible and more operationally demanding. But when it is properly designed, exported and protected, it gives something that is still very hard to replace: a truly offline recovery option.

Maybe the problem is not tape itself. Maybe the problem is using tape for the wrong job.

For fast recovery, use disk/object.
For resilience against the worst-case scenario, I still want something offline.

That is why I am still FOR tape and AGAINST the statement.

​@jos.maliepaard, I really like your point about backup verification, health check, malware scanning, SureBackup and Instant VM Recovery. I think this is one of the strongest arguments in favor of disk/object storage for operational recovery.

I just see the tape part a little differently.

For me, a lot of the validation happens before the data is written to tape, when VBR creates and processes the original backup file. If the backup was already scanned, health checked and validated before being copied to tape, then tape is storing a copy of a backup that already went through those controls.

Of course, tape will not magically fix bad data. If the original backup is corrupted or infected before being written to tape, the tape copy can carry the same problem. But I think this is also true for any secondary copy. If you copy bad data to another repository or object storage, you are still copying bad data.

I fully agree that tape is not as simple or flexible for validation after that. With disk or object storage, it is much easier to run SureBackup, additional scans and fast restore tests. With tape, the process is more manual and requires more planning.

But it is still possible to test it. You can bring the tape back to the library, catalog/import it if needed, restore the backup/files back to disk and validate the recovery. It is more work, yes, but it is not impossible.

So I agree that tape needs a strong operational process: proper labeling, good rotation, good storage conditions and regular restore tests.

I would not say that because a backup is written to tape, you never know if it is recoverable. I would say you only know it if you test it — and for me, that is true for every backup technology.

Backups are nice, but restores are what matter. Tape still has value, but only when it is part of a tested and well-managed recovery strategy.

As i came up with the  ̶r̶a̶g̶e̶b̶a̶i̶t̶  topic for calm discussion, I won’t argue for or against but I’m wondering if you can explain this part a bit more as not quite understanding.

Do you mean you see same data being written multiple times to tapes with different retention schemes or how do you mean? Just with Veeam, GFS policy by default always places data in the oldest eligible media set to avoid this scenario entirely (i.e., if a Weekly and a Yearly are same day, data goes to Yearly media set), but maybe I misunderstand

I was careful about how I worded my argument to explicitly *not* include how data is written or retrieved from Tape, just in case I was mistaken or off...for this very reason. hahaha 😂

​@matheusgiovanini - agree with your response. I am not against Tape, and for sure see its value, but from an operational standpoint...and from the perspective of the types of businesses I’ve worked in (customer SMBs my whole career), implmenting is just more work than the benefit of what it can provide; and for my environment...not much extra benefit. I enjoyed reading your viewpoints on it. 👍🏻

Thanks ​@coolsport00, I really appreciate your comment.

I understand your point about operational overhead, and I agree tape is not the best fit for every environment.

But for me, that does not make tape dead. It just means tape has a different role.

For daily restores, I want disk or object storage. For the worst-case scenario, I still want tape.

In the ransomware case I mentioned, the offline tapes were the layer that survived when the rest of the backup ecosystem was compromised.

Sometimes the most valuable backup is not the fastest one, it is the one the attacker could not touch.

2 additional points for tape is NOT dead could still debated. 😀

• It is more fun to watch tape libraries as the grippers move the tapes around.
• Air Gap > Immutability.   

Immutability is fantastic and should be used, but a true airgap (Exported Tape) is protected at the network level from someone deleting volumes at the SAN or server mgmt level, using SSH or something similar.

Yes, you can set cron jobs, but at some point, those jobs have to be enabled for the backup.  

Physical infrastructure can be compromised in both cases, and offsite copies can protect both of those.