It's no secret: IT pros absolutely love to hate tape. I've remarked on that fact in this column several times over the past few years, and it's no less true now than it was any of the other times I've mentioned it. But that's all changing! What local disk backup couldn't solve on its own, cloud storage providers with their hyperredundant and constantly maintained fleets of disk can certainly fix! Finally, we can put a stake in the heart of tape and it will simply become a ghost story that the old timers tell IT newbs. Right?
Maybe, but not so fast. Although the cloud absolutely can replace some of the use cases for tape, it can't satisfy them for everyone all the time. The very same reasons why tape was still alive and kicking when I wrote about it nearly four years ago are still largely true today.
However, you need not fret if you're itching to get rid of tape and make backup someone else's problem by moving it to the cloud. Things are definitely looking up -- especially if you're working with relatively small amounts of data, can deal with long restoration times, or have ridiculous amounts of bandwidth to spare.
To understand what the cloud is and isn't good for, as it relates to tape or any other kind of on-premises backup, let's dig into some of the basics. I'll show you two examples to illustrate that the issues -- and thus the decision -- are not as simple as you might think or hope.
Comparing two backup scenarios using tape
Company A is a small accounting firm. It has a couple virtualized servers, and a full backup works out to about 500GB (with incrementals running about 50GB). It now uses an older-generation LTO-4 drive for backup. The Internet connection is a 5Mbps copper-based circuit, but given the company's location in the heart of a city, it has just about any connectivity option you can imagine available.
Company B is a manufacturing firm. It has about 35 virtualized servers, and a full backup works out to about 8TB (with incrementals running around 800GB). It now uses a combination of disk-to-disk backups and a current-generation LTO-6 autoloader to get its data backed up. The Internet connection is a copper-based 20Mbps circuit, an option that represents the best it can hope to get in its rural location.
To make things simple, both companies use a virtual backup software such as Veeam Backup and Replication that dumps precompressed and deduplicated images of the production machines to local disks, where it can then be backed up. (Both the cost of this software and the local disk it spools onto is not included in my comparison because it is required for both on-premises and cloud approaches to backup.)
Both firms also have a hard business requirement to maintain offsite backups of their data for at least a year. In the case of the accounting firm, the IRS requires such offline backup. In the case of the manufacturing firm, it handles defense contracts for a Fortune 100 company that requires them.
Cost. Company A spent about $1,600 on its LTO-4 drive and another $30 on each of the 30 tapes that make up its yearly grandfather-father-son (GFS) media rotation. The office manager spends about two hours a week making sure that the tapes are changed, for a cost of about $15 per hour, and every month or so something goes wrong (usually when he forgets to change the tape) and an outsourced IT gal has to remote in and fix it to the tune of about $90. All in all, this approach costs about $4,000 per year -- the bulk of which is tied up in labor costs.
Company B spent about $4,000 on a 16-slot LTO-6 autoloader and another $105 on each of 90 media that make up its GFS rotation. The dedicated server admin spends four hours a week maintaining the backups at a cost of about $30 per hour, and she rarely needs outside help to keep things rolling. Assuming the autoloader lasts three years before it needs to be replaced, this approach costs about $17,000 a year. This time, the bulk of the cost is hardware (specifically media), but labor still accounts for more than a third of the cost.
Redundancy. Strictly speaking, neither Company A nor Company B has much in the way of redundancy. It's true that backups are written to disk before they are copied to tape, so at least two copies of every backup are made, but there's not much beyond that. Should a particular archival tape suffer damage after the local disk-based copy has been overwritten (generally not longer than a week), there wouldn't be a backup to the backup. For people who distrust tape, this risk is scary enough to require duplication of tape media, which can substantially drive up the costs.
Backup speed. It appears that both Company A and Company B are limited by the performance of their respective generations of LTO drives. However, the reality is that the source storage is usually the limiting factor, not the tape drive. If there is one thing that tape drives are exceptionally good at, it's ingesting large quantities of sequential data at full rate (120MBps for LTO-4, 160MBps for LTO-6). Where they will suffer is when the source isn't fast enough to keep up with the drive -- sometimes causing inefficient buffer underruns and reseeking to pick up where it left off when the buffers are repopulated.
For comparison's sake, both companies' throughput is substantially more than the real-world throughput of a single 1Gbps Ethernet link (about 110MBps) and more than the sustained read performance of a small array of 7,200rpm disks, which are typically used as an intermediate storage target for backups (perhaps running at 70MBps to 100MBps).
If you assume this intermediate disk target is really the choke point for Company A, a full backup might take about two hours. Given the much larger storage requirements for Company B, you can assume it would deploy better intermediate storage that can drive the tape drive at full rate, and so its full backup could take about 15 hours (perhaps longer with media changes).
Restoration speed. Restores can be almost immediate, assuming you have your local intermediate disk backup copy available and the data you want is actually contained in that copy. However, if your local copy has been destroyed (perhaps due to a site-wide disaster) or if the data you need is older than might be contained in the local copy, you'll have to go back to tape.
Going back to tape involves actually getting the tape back from its offsite vault and, when the site has been physically affected, finding a tape drive that can read the media. Depending on the circumstances, this could be anything from a couple of hours to a few days plus the actual time of restoration, which typically resembles the backup times.
Assuming that tapes are stored in a safe offsite somewhere and can be accessed in two hours, full restores would start at about five or six hours for Company A and nearly a day for Company B.
Comparing the two backup scenarios in the cloud
Now let's compare the two companies' backup realities if they backed up to the cloud.
Cost. Company A has opted to shuffle its backups to Amazon.com's popular S3 cloud storage platform for primary backups and to use Amazon's low-cost Glacier for its archival backup. Now, instead of figuring out how expensive the drive and media might be, the company needs to figure out how much storage it'll consume and how it'll get the data into the cloud in the first place.
Although the tape model doesn't precisely translate to the cloud, one way to go about it is to push a full backup to the cloud every week followed by daily incrementals. Then, each month an archival copy of that backup is made to Glacier, without a separate backup needing to take place.
The company would need about 800GB of storage to store a week's full backup plus six days of incrementals. That would cost about $76 per month ($912 per year) for the 800GB of active backups in S3 and about $96 per month ($1,152 per year) for 9.38TB copied to Glacier by the end of the year. Assuming the software just works and nobody has to maintain it, that's about half the cost of the tape solution. Cool!
But wait -- it's not just storage that needs to be considered. The company also has to think about how the data will get there. With exclusive, unfettered access to a 5Mbps Internet connection, pushing a full 500GB backup up to the cloud would take nearly nine days. That obviously won't work. A 100Mbps connection could do it in a bit more than 11 hours, but at a cost: The 5Mbps connection likely runs less than $200 per month, whereas as a 100Mbps fiber connection hits about $1,000 per month. That alone raises the bottom line by $9,000 per year, bringing the total cost to about $11,000 per year. In a tape environment, that $15-per-hour office manager could spend 11 working weeks just on backups and still not close that cost differential.
Things are even worse for Company B. Its storage costs would be nearly $150,000 per year for 12.69TB in S3 and 152.25TB in Glacier. And its costs for transferring that data to the cloud backup? Zero, because it can't be done. Pushing the weekly 8TB full backup over a 20Mbps connection would take substantially more than a month. And 20Mbps is all Company B has available to it due to its rural location.
How to think about cloud backup
Am I saying that cloud storage can play absolutely no role for either of these example companies? Of course not. The issue is that traditional on-premises backup and cloud backup are fundamentally different things, so translating a traditional backup approach to a cloud approach raised three issues.
One issue is that your apparent media cost goes up substantially in the cloud. An LTO-6 cartridge costs about 4 cents per gigabyte, and it will store that data for many, many months without costing a cent more. That compares extremely poorly with S3 at 9.5 cents per gigabyte per month ($1.14 per gigabyte per year), though Glacier gets within striking distance at 1 cent per gigabyte per month (12 cents per gigabyte per year). If you also consider that you'll often short-stroke (not fill) your LTO media when you back up to them and paying for just actual usage at Amazon, the cost difference is in fact even lower, though still pricier in the cloud.
The second issue is that the means currently available to copy on-premises data into the cloud is nowhere near optimal. For example, when Company A backs up to tape, it's copying 500GB for the weeklies and 300GB for the six dailies for a total of 800GB per week, or more than 40TB per year. Obviously, nearly all that data is almost completely identical and doesn't need to be copied. The reason that companies do it that way with tape is so that they have a limited number of media to retrieve if they want to do a restore.
With the cloud, you shouldn't have to do it that way. Instead, you should be able to do a full backup, then use each incremental backup you make to replace portions of the previous full -- creating something called a "reverse incremental" (where the displaced portions of the previous full backup are copied into an incremental that goes back in time from the full backup, not forward in time from the full backup). However, today's cloud storage APIs make doing that very hard; in fact, I'm not sure anyone has successfully pulled it off using general-purpose block I/O and a popularly available backup package.
The third and most critical issue is that it's extremely unlikely that either of these example companies needs to maintain these kinds of archival backup rules on all their data. In Company B's 8TB of backups, there's probably a very small subset for which its customers are really concerned with maintaining rock-solid archival backups. Winnowing the backup set down to that specific data and backing it up on a file level is easy.
Where does this leave the question of whether you can replace tape backup with cloud backup? The satisfying answer: It depends. It depends on whether you have lots of data that changes, which increases the amount of data that must be transmitted each time, perhaps to the point of unaffordability or impossibility for your available Internet connections. And that depends on what you're backing up how you manage it.
If you want to use cloud backup, you'll first need to work through all these issues to see if it's even possible, then if it's affordable. You may discover that tape is the better option after all.
This article, "The hidden challenges of using cloud backup to replace tape," originally appeared at InfoWorld.com. Read more of Matt Prigge's Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.