Tape is Alive? Inconceivable!

Stephen Manley

Stephen Manley

CTO, Data Protection and Availability Division
Over the past 15 years at both EMC and NetApp, I have traveled the world, helping solve backup and recovery challenges - one customer at a time (clearly, I need to optimize my travel arrangements!). My professional mission is to transform data protection so that it accelerates customers’ businesses. I have a passion for helping engineers pursue technical career path(without becoming managers), telling stories about life on the road and NDMP (yes, that’s NDMP).

To begin each year, Joe Tucci brings 400+ people together for the EMC Leadership Meeting. We spend a little time reflecting on the prior year, but most of it focusing on the future. After that, the Backup and Recovery Systems Division leadership spends another day planning our future. So, imagine my surprise when I saw, on the Backup and Recovery Professionals Group on LinkedIn, a thoughtful discussion about the role of tape in the backup environment. I’ve just spent a week discussing cloud, big data, and the evolution of data protection… and we’re still talking about tape? Inconceivable!

While I appreciate both the maturity of the discussion and the resiliency of tape, it’s a waste of time. Every moment spent talking about tape is a moment not spent discussing the future of data protection – deduplication, snapshots, versioned replication, cloud, ???. The opportunity cost of discussing tape frustrates me.

 Tape is not the answer of the future. It’s increasingly less useful in the present – unless you’re talking about data that you don’t ever intend to actually access again. Here’s the reasoning:

  • Full recovery from a complete server or storage array outage: As capacity increases, the only way to recover the data quickly enough to be useful is to have it online and spinning somewhere (e.g., replication). The issue here isn’t so much disk vs. tape as it is tape-centric backup architectures. If you need to wait until all of the data is restored to a new system (and writing data on the recovering system is usually the bottleneck), you’ve been down too long. Tape doesn’t hit the bar here.
  • Rollback from corruption: If most of the data is still good, but there’s been some corruption (user or system caused), the only way to recover quickly is some sort of changed block rollback (e.g., snapshot/clone rollback, changed block recovery for VMs, etc.). In general tape-centric backup architectures make rollbacks near-impossible.
  • Granular recovery: When it comes to granular recovery, it’s all about getting the right version of your data. In this case, recovery is all about backup – when you can do backup more frequently and store more copies (space-efficiently, of course), you’re more likely to get the version of the data you want. In general, disk-centric architectures that leverage some sort of data optimization (e.g., dedupe, snapshots, clones) enable you to keep more and more frequent backups.
  • Archival recovery: Traditionally, this has been where tape has made its arguments around relevance – long-term, cost-effective, low-power retention. But here’s the problem. In general, we’ve all agreed that backup is non-optimal for data archival. It’s rare that you can track the lifecycle of data (e.g., ‘I want to recover a file from server X, from 12 years ago. Does anybody remember what server the file was on 12 years ago?’), you’re unlikely to have the infrastructure to access it (e.g., ‘Does anybody have a DEC server with application X, version Y?’), and even less likely to manage the tape infrastructure lifecycle to enable the data recovery. As I’ve seen customers go tapeless at multiple companies (as I’ve worked at multiple vendors), they use the transition to disk to re-examine and reduce their retention periods, and deploy a true archival solution.

I think one customer put it best: “I’m legally required to store data for 30 years, but I’m not required by law or business to ever recover it. That data is perfect for tape.”

Do you think we need to spend more time talking about tape? Do you think tape has a bigger role to play today or in the future? If you had new money to spend, would you put it on tape? Am I being overly dismissive? Please weigh in here or on LinkedIn – Backup & Recovery Professionals Group.


Stephen Manley

Stephen Manley

CTO, Data Protection and Availability Division
Over the past 15 years at both EMC and NetApp, I have traveled the world, helping solve backup and recovery challenges - one customer at a time (clearly, I need to optimize my travel arrangements!). My professional mission is to transform data protection so that it accelerates customers’ businesses. I have a passion for helping engineers pursue technical career path(without becoming managers), telling stories about life on the road and NDMP (yes, that’s NDMP).

11 thoughts on “Tape is Alive? Inconceivable!

  1. If the data wont dedup tape is far cheaper. As a data domain user it is a good fit for 90% of data but it isn’t the case of one solution fits all. Until dedup works on 100% of data tape will have its use.

  2. Tape is still cheaper even if the data does dedupe at 20:1. Deduped disk is far superior to tape for day-to-day backup and recovery operations, but rarely do I see it cost less that storing that data on tape.

    And yes, if one has data that doesn’t dedupe, then disk isn’t even in the cost race. It’s orders of magnitude more expensive.

  3. In Europe we do see that long term retention and ‘archive’ is the last real frontier for tape. I think EMC is best positioned to lead here (in the spirit of kickoff focusing on leadership…)We can turn from disk to tape to an *effective* archival strategy – one that is online, indexed and searchable to actually *find* content. And one that can be properly managed to actually get rid of content when it’s time is up. Boxes of tapes in a cupboard might meet regulator requirements at the moment but even they are going to figure out that a box of tapes is irretrievable clutter.

  4. @Pierre -

    Sorry that I can’t reply inline (apparently, they don’t trust me with the password for the system)… To the actual response.

    I often get the question about data that doesn’t dedupe.

    First preface. When I advocate for disk backups, it isn’t code for “just send a tarball to Data Domain”. There are a variety of disk-backup approaches, and I find that one of them can usually deliver the RPO/RTO with the reliability and cost you need … or something that’s a close to what you need as anything else.

    Second preface. I prefer approaches where the protection solution focuses first on adding value within a cost envelope, as opposed to focusing first on driving down cost on diminishing value (e.g. one way to get more “dedupe” is to leverage the same disk copy for backup + DR + more, instead of having multiple separate copies). I fear that backup groups that don’t focus on extending their data management value proposition to IT will find themselves marginalized in their company.

    OK, preambles done. There are four “non-dedupe” cases I hear about: 1.) Low-retention, non-repeating data (e.g., database logs); 2.) High churn environments (e.g., test data); 3.) Environments in which you don’t run multiple full backups and have little cross-backup de-dupe (e.g., images, web objects and training videos) and 4.) Environments in which the application behavior compromises dedupe (e.g., compressing data that you modify). I believe there are disk-based answers for all of these.

    But… to dig into the answers, that’s a whole separate post you’ve inspired me to write. I don’t want to leave you hanging, but I want to cover it in detail. Stay tuned next week for more detail, and let me know if my answers make sense. Or if I’ve missed a use case or possible solution.

    Thanks for the feedback and stay tuned,

  5. @Curtis –

    I’ll stipulate that I don’t spend my days comparing physical media costs between tape and deduplicated disk.

    But we have thousands of customers who realize a tremendous ROI on the TCO of our disk backup solutions. So, I suspect that their end-to-end view of the costs leads to a dramatically different conclusion than your approach.

    Furthermore, as I noted in my response to Pierre – I encourage backup teams to focus on expanding the services and value that they add to their company (within a cost window, of course), rather than reducing costs at the expense of services (which, as data and user expectations increase – simply staying still is perceived as reducing services).

    With disk, I think the backup team can expand the value that they offer to their users – and go even further on the end-to-end ROI in their TCO calculations. You’ll see me talk more of that in the future.

  6. A backup solution is based on business requirements. Depending on your needs, tape can still be part of a concept. Sure, you can find many reasons why tape can’t be used in this or that situation. But at the end life isn’t black or white. Most of the time it’s grey. ;) And this is the main cause why tape isn’t dead.

  7. @Curtis – You are right. If your comparison is based on storing data then dollar for dollar tape is cheaper than disk. But that in itself is I am afraid to say a one dimensional comparison. The problem with tape was never (initially) about storing data (although considering data remains idle it does promote false hope :) ). The problem has been about getting the data to tape in the first place. Disclaimer, I work for EMC BRS now but was once an employee for StorageTek back when tape was the predominant landing place for backups. When we look at all the moving parts required to get data onto tape and the effort required to ensure the data is there when we need it (insert “media verification + referential integrity”) this is where the hard and soft costs associated with a tape versus disk centric architecture start to converge. I am confident I don’t need to give you the history lesson of how we got to this point but I will for others reading this comment. Over the last decade or so there has been a gradual shift from tape to disk centric architectures. The industry started off with D2T (anything before this era and I was still in the womb :) ). Tape drives are and have been inherently unreliable (for many reasons). When you couple unreliability, explosive data growth and basic backup software capabilities it was inevitable that the tape interface could no longer sustain an acceptable backup window. To address this challenge a better interface was required and so began the rise of D2D2T architectures. These architectures utilised disk transports coupled with regular file systems over (at the time slower) GigE networks (versus FC) as a reliable staging area in order to address the reliability requirements of the backup window but still leverage tape as the final resting place for backups. What the industry soon realised is that slapping together commodity disk with commodity file systems and commodity servers did not lead to a particularly fast system. It was reliable but it wasn’t fast at sequential access, which is what was required to drive backup windows, and it would degrade over time, because regular file systems were not designed for sustaining a high performance sequential IO pattern in light of high data churn. Similarly, these systems were accessible from IP networks and back in the day FC was king when it came to storage networking performance. And so the industry then decided they needed a more “specific design” and chose to emulate tape over FC with a disk transport buffer and tape at the back-end. This would allow the solution to address the IP network bottleneck by leveraging existing investments in FC SANs and also try and address the issue of file system throughput and fragmentation. However, even then to obtain the maximum bandwidth possible we still had to expose tape interfaces to application hosts, which everyone wanted to get away from due to interoperability issues with SAN’s (“back in the day”) which meant reboots and outages when things went wrong or changes were required. Some years passed and the SCSI and FC drivers in operating systems had matured but the horse had already bolted. IP was given a new lease on life with the introduction of 10 Gbe networks which meant we could now build an IP disk centric device that would sit behind a backup server and isolate the host from the target. We would be able to do this en-mass and use the lessons learnt during our VTL experience to solve the file system and disk bottleneck issues. This brought the rise of the purpose-built deduplication disk appliance. What it allowed us to do is abstract the device from the host (which everyone wanted as it eliminates service disruption and makes scaling much easier), solved the economies of disk for backup at scale problem, solved the process of getting backups offsite (deduplicated replication), solved the problem of operating under false pretences (“false hope”) and finally solved the disk bottleneck for backup and restore which meant if we wanted to store all backups on disk, we could. Since then the ecosystem has evolved to deduplicate at the edge (hybrid deduplication) and make more efficient use of networks. Similarly, the basic backup software we were reliant on has grown up and become more intelligent with the data sources and the processes required to produce backups (and restores in some cases). And so this is where we find ourselves today. There are new challenges on the horizon. Let’s see what the next 3 years brings. All the best.

  8. @Peter. I have no problem getting my data onto tape day after day. I have no problem getting my data off of tape day after day when I need to.


    Well google thinks it has a future

    and so do a number of other “cloud storage” providers.

    I firmly believe tape has a future as with a substantial amount of data > 80TB it is invariably cheaper than an all disk solution for archive ( and I have costed it regularly over the past 5 years for my use case)

    I use snapshots, replication, dedeupe etc. but I still think tape has a place in backup as the end resting place for backup data.

    So, yes, I disagree with you. Sure I know a number of orgs that have gone to all disk solutions but also know a few (especially with the advent of big data) have added tape again when faced with rising costs.

  9. @Jie. Thanks for the comment; you’ve piqued my curiosity with multiple statements! I’d love to understand more about your archive/long term backup retention. How long do you keep the backup data around and what is the expected use case for recovery? In general, I’m skeptical of traditional backups for long-term archival – regardless of the media on which they’re stored – so I’m interested in hearing how you approach that challenge. I’d also love to better understand your point about “big data” changing the game for tape. In my experience at both EMC and prior, I’ve seen big data push customers toward replication, eliminating traditional backups (and any hope of tape), entirely. Traditional approaches couldn’t come close to their RPO/RTO expectations and crushed the disks/flash on their clusters with massive amounts of non-cached IOPs. So, they just decided they were better off without backup. I’d love to hear more about your approach here, as well. Thanks! Sm

  10. How long do we keep backups – varies 4 weeks to 10 years or longer.
    Use cases – all the usual ones file corruption, user error, DR and compliance etc. For recovery beyond 6 months then usually compliance or business analysis reasons.
    Obviously we go to disk (snapshots etc) for very recent recovery but the older all comes back from tape usually within 4 hours -”really” old stuff longer – had to pull something from 8 years ago and that took 2 days elapsed (but not very much of my actual time ) but I had a week before it was required (that tape sat on a shelf for 8 years – no problem with recovery) why would I have that on disk ?

    I totally agree with you backup should not be used as archive but most businesses do and that’s a situation I inherited. I am gradually moving to an active archive (using a combination of disk and tape – the latter again for cost reasons ) which eliminates the “where was that file 5 years ago” and enables a significant reduction in my primary storage footprint and therefore my growth.

    Re. Big data -well if you need all your data on-line to do your analysis then possibly the architecture you describe is the only option. I am going to take Big Data as simply a flood of data from new or enhanced sources which significantly exceeds the current storage footprint. For us we break down the raw data into subsets for analysis where we keep the summarised data on disk and continuously dump the raw data to tape and clear down the disk. We can bring the raw data back in if we want to re-analyse it. Maybe that doesn’t meet your criteria for Big Data. ..

    Could my organization afford to put all this data on “cheap” disk – possibly – but all budgets have limits and I’d rather spend the money on SSDs etc .

  11. @Jie – I think your approach to the big data is still pretty common. I confess that I don’t think of those as backups, though. The most common case I’ve seen is – “Oil company extracts massive amount of information from the earth to tape. Oil company helicopters tapes to compute center. Compute center loads data from tape to disk for processing. As data moves upstream, the original ‘from earth’ data is flushed from disk for the next set of raw data and the original tapes are stored somewhere. The upstream data may or may not be backed up, depending on the cost/benefit analysis of recovery vs. recomputing. Anyway, the original tapes are stored for a long time, since you may want to re-analyze them in 10 years, when extraction techniques are more advanced.” I don’t think of the data on the tapes as backups because tape is really the authoritative primary copy and the disk is just a temporary performance cache. That may be semantics caused by being in a big company with a broad portfolio (since I’d recommend an Isilon for that data, not a backup appliance). But that is one of the “tape as a storage device” use cases that I get. And if I were in the tape industry, I’d suspect that I’d be looking to grow those. After all, the limitations that tape puts on a backup architecture may not be so painful in certain other storage workflows. (Having said that, Isilon and Atmos are also doing tremendous business in addressing some of those other use cases, too). Thanks for the details. And, trust me, there isn’t a company, organization, or government agency that I meet with that isn’t trying to reduce their storage and infrastructure costs (capex and opex). I have great respect for everybody continuing to make IT do more with less. It’s my mission to enable backup teams to deliver even more value, so they can be a business driver, rather than a cost center. So, thank you for taking the time to share.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>