{"id":5551,"date":"2015-05-13T19:47:02","date_gmt":"2015-05-13T09:47:02","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=5551"},"modified":"2018-12-11T12:58:06","modified_gmt":"2018-12-11T02:58:06","slug":"one-target-to-rule-them-all","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2015\/05\/13\/one-target-to-rule-them-all\/","title":{"rendered":"One target to rule them all"},"content":{"rendered":"

Introduction\"Data<\/a><\/h3>\n

It’s true there are some data types that broadly aren’t suitable to sending to Data Domain \u2013 any more than they’re suitable for sending to any other deduplication appliance or system within any environment. Large imaging data and video files will yield minimal deduplication except over successive backups (assuming static data), and compressed and\/or encrypted data aren’t all suited either.<\/p>\n

But the majority of data within most organisations is<\/em> suited for writing to Data Domain systems.<\/p>\n

Years ago when EMC purchased Data Domain, I don’t think anyone anticipated just what they had in mind for the appliance. I certainly didn’t \u2013 and I’d been involved in the backup industry for probably 15 years at that point. Deduplication had been kicking around for several years, but it hadn’t been mainstreamed to the degree EMC has achieved.<\/p>\n

The numbers practically speak for themselves. Data Domain represents an overwhelming lions share of the deduplication appliance space \u2013 but I’m not going to quote numbers here. I’m going to talk about the architectural vision of Data Domain.<\/p>\n

As a target-only appliance, Data Domain represents considerable advantage to any business that deploys it, but that’s just the tip of the iceberg. The real magic<\/em> happens when we start to consider the simple fact that a Data Domain is not<\/em> a dumb appliance. EMC have chosen to harness the platform to deliver maximum bang for buck for any company that walks down that path.<\/p>\n

May the source be with you<\/h3>\n

Target based deduplication works brilliantly for drastically reducing the total amount of data stored, but it still results in that data being sent<\/em>. Avamar demonstrates this overwhelmingly \u2013 its source based deduplication backup process is unbelievably efficient and powerful and is a powerfully attractive choice for many businesses, particularly those in the x<\/em><\/span>aaS industry.<\/p>\n

Data Domain’s Boost functionality extends its deduplication technology up to the origin of the data. For products like NetWorker, Avamar and VDP\/VDPA, this goes right to the source. (For third party products such as NetBackup, it covers the media servers.)<\/p>\n

If Boost had stopped at NetWorker and Avamar integration, it would have been a remarkably powerful efficiency hook for many businesses, but there’s more power to be had. The extension of Data Domain Boost to include support for enterprise applications such as Oracle, SQL Server, SAP, etc., provides unparalleled extensibility in the backup space to organisations. It also means that businesses who have deployed other backup technologies but leverage the power of Data Domain deduplication in their data protection strategy can get direct client deduplication performance for what is often their most mission critical systems and applications.<\/p>\n

I’m the first to admit that I’ve spent years trying to convince DBAs to hand over control of their application backups to NetWorker administrators. It’s a discussion I’ve won as much as I’ve lost, but the Data Domain plugins for databases have proven one key lesson: when I’ve ‘lost’ that discussion it’s not been through lack of conviction, but through lack of process<\/em>. DBAs are all for efficiencies in the backup process, but given the enterprise criticality of databases in so many organisations, much of the push back on backup centralisation has been from a lack of control<\/em> of the process.<\/p>\n

The Boost application plugins get past that by allowing a business to make the decision to integrate their application backups into centralised backup storage while allowing for highly granular control of the backup process through the agreed and trusted scheduling methods that offer considerably more granular and flexible controls. Backup products offer scheduling, of course, but they’re not meant to be the bees knees of scheduling that you’ll find in products devoted solely<\/em> to that purpose. That’s<\/em> what DBAs have mostly resisted. (This, for what it’s worth, is the difference between app-centric<\/em> aspects to backup and recovery and a decentralised<\/em> backup ‘system’.)<\/p>\n

Here’s where we’re at with Data Domain \u2013 it now sits at a nexus in the Data Centre for data protection and nearline archival storage:<\/p>\n

\"May<\/a><\/p>\n

(Yes, it’s even very well suited for archival workloads.)<\/p>\n

NetWorker, Avamar, VDP\/VDPA, Client Direct, Enterprise Apps \u2013 I could go on \u2013 Data Domain sits at the centre ready to receive the data you want to send to it.<\/p>\n

But that diagram isn’t quite<\/em> complete. To truly get the maximised efficiency out of Data Domain, the picture really should look more like this:<\/p>\n

\"Protecting<\/a><\/p>\n

That’s right \u2013 logically, a Data Domain solution will have at least two<\/em> Data Domains in it, so that whatever you’re protecting via the Data Domain will itself be protected. Now, by itself, Data Domain offers excellent protection for the data you’re storing, but unlike what most people think of on this front, RAID-6 storage protection is just the tip of the iceberg. RAID-6 is nice \u2013 it protects you from two drive failures at any point. On top of that though, you have the Data Invulnerability Architecture that you’ll hear EMC folks talk about quite regularly \u2013 that’s the magic sauce. The Data Domain doesn’t just sit there storing your data: it stores it, it checks it, it reads it again, and it checks it as part of regular verification. (If you want to compare it to tape, imagine having a tape library big enough to store every tape you keep for retention and constantly sits there loading all the tapes and confirming all the data can be read back.)<\/p>\n

But we all know in the data protection world that you still need that added<\/em> protection of keeping a second copy of that data, regardless of whether that’s for compliance or for true disaster protection. In terms of absolute efficiency, the absolute best<\/em> way you’ll get a secondary copy of that data is via the global deduplicated replication offered between two Data Domains. (For what it’s worth, that’s where some companies make the mistake of deploying tape as their secondary copy from an original backup target of Data Domain: what’s the point of deploying efficient deduplication if the first thing you’re going to do is rehydrate<\/em> all the content again?)<\/p>\n

Aside: Coming back to encryption and compression<\/h4>\n

Earlier I said that compressed and encrypted workloads aren’t necessarily suited to Data Domain. That’s true, but<\/em> that usually reflects an opportunity to revisit the process and thinking behind those workloads.<\/p>\n

Compression is typically used in a data streaming activity for data protection because of a requirement to minimise the amount of data going across the network. Boost eliminates that need by doing something better than compression at the client side \u2013 deduplication. Deduplication doesn’t just compress the original data, but it substantially reduces the original data by not even bothering to send data that already exists at the target. For instance, if I turn my attention to Oracle, the two most common reasons why DBAs will create compressed Oracle backups are:<\/p>\n

(a) They’re writing them to primary storage and trying to minimise the footprint, or<\/p>\n

(b) They’re writing them to NAS or some other form of network storage, and want to minimise the amount of data sent over busy links.<\/p>\n

Both of those are squarely addressed by Data Domain:<\/p>\n