I’m back in a position where I’m having a lot of conversations with customers who are looking at infrastructure change.
What I’m finding remarkable in every single one of these conversations is the pervasiveness of Cloud considerations in data protection. I’m not just talking Spanning for your SaaS systems (though that gets people sitting up and taking notice every time), I’m talking about businesses that are looking towards Cloud to deal with something that has been a feature of datacentres for decades: tape.
I’ve mentioned CloudBoost before, and I personally think this is an exciting topic.
An absolute ‘classic’ model now with NetWorker is to have it coupled with Data Domain systems, with backups duplicated between the Data Domain systems and removing of tape – at least for that daily and weekly backup cycle. Data Domain Extended Retention is getting a lot of interest in companies, but without a doubt there’s still been some people who look at a transition to deduplication as a phased approach: start with short-term backups going to deduplication, and keep those legacy tape libraries around for handling tape-out for monthly backups.
That certainly has appeal for businesses that want to stretch their tape investment out for the longest possible time, especially if they have long-term backups already sitting on tape.
But every time I talk to a company about deploying Data Domain for their backups, before I get to talk about CloudBoost and other functions, I’m getting asked: hey, can we say, look towards moving our long term backups to Cloud instead of tape at a later date?
You certainly can – CloudBoost is here now, and whether you’re ready to start shifting longer-term compliance style backups out to Cloud now, or in a year or two years time, it’ll be there waiting for you.
Over time (as the surveys have shown), backup to disk has increased in NetWorker environments to over 90% use. The basic assumption for years had been disk will kill tape. People say it every year. What I’m now seeing is Cloud could very well be the enabler for that final death of tape. Many businesses are entirely killing tape already thanks to deduplication: I know of many who are literally pulling their tapes back from their offsite storage vendor and ingesting them back into their Data Domains – particularly those with Extended Retention. But some businesses don’t want to keep all those long-term backups on local disk, deduplicated or not – they want a different economic scale, and they see Cloud as delivering that economy of scale.
I find it fascinating that I’m being so regularly asked by people: can we ditch tape and go to Cloud? That to me is a seismic shift on the remaining users of tape.
[Side note: Sure, you’ll find related links from me below about tape. Just because I wrote something 1-3 years ago I can’t change my opinion 🙂 ]
Am I the only one who doesn’t think tape should die?
I have done a LOT of NetWorker deployments for a lot of different customers, and the ones still using tape are in a minority. The ones implementing tape in new systems are in an even smaller minority. Most of the systems I have designed and implemented over the last few years have had DD as the primary and only backup target. Usually there is cloning or replication to another DD, sometimes not. DDs are fabulous bits of kit, and I love them to death, however…
I’ve been around in IT and backups for a very long time now, and I don’t trust disks. I have seen hundreds of disks fail, and we know that they all fail eventually. Even with the benefit of RAID, it is possible to lose data if the wrong disks fail in quick succession. This is possible if you get a bad batch. Most businesses accept this risk.
However there is one further risk that most businesses forget, and that is the risk of finger trouble, or worse, malicious damage by a system admin. I was working at a customer almost 20 years ago who were implementing policies to try to control this risk by some severe limitations to UID 0 access. Their worry was that the same people who ran their systems would also run the backups, and someone with a grudge could potentially sabotage the backups before trashing the live data, and as a result they were trying to keep these two groups of people separate. This was when all the backups were tape based.
This level of concern is quite rare IME, and most companies have a team that run storage AND backup. Thus there is nearly always a team of people who have admin on some of the servers, the backend storage, and the backup targets. It would be easy to wipe out the contents of the DDs and the backup storage in a matter of minutes, either accidentally or maliciously. This could destroy a company, but is rarely considered as a risk.
By keeping some backups on tape, ideally off-site, even if it is just a monthly copy, it becomes much harder to destroy all that data and the backups at the same time. If I was an IT Director, I would certainly be wanting to keep some tape infrastructure around forever.
Actually, I used to agree with you. I don’t think it’s something that I could have entertained personally five years ago, but the risks are now becoming more acceptable – mainly because they’re being mitigated at so many levels.
Companies concerned with data loss implications of online long-term storage need to confirm they’re satisfied with the security models they have in place to either prevent it or at least audit the process. Ultimately there is a degree of trust required between IT staff and the business – a single rogue administrator (virtualisation, storage, backup, system or application) could do untold amounts of damage within an organisation. If this is a genuine concern for a business then I’d argue they have a much deeper problem than an IT one.
I’m now seeing huge businesses deciding to completely eliminate tape from their environment. Multi-petabyte businesses are deeming disk more than acceptable for long-term storage rather than dealing with the media handling challenges of tape. It’s no longer bleeding edge to move away from tape, it just requires an appropriate level of process maturity.