{"id":5885,"date":"2016-05-24T05:16:10","date_gmt":"2016-05-23T19:16:10","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=5885"},"modified":"2018-12-11T10:55:02","modified_gmt":"2018-12-11T00:55:02","slug":"how-many-copies-do-i-need","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2016\/05\/24\/how-many-copies-do-i-need\/","title":{"rendered":"How many copies do I need?"},"content":{"rendered":"

So you’ve got your primary data stored on one array and it replicates to another array. How many backup copies do you need?<\/p>\n

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

There’s no doubt we’re spawning more and more copies and pseudo-copies of our data. So much so that EMC’s new Enterprise Copy Data Management (eCDM) product was announced at EMC World. (For details on that, check out Chad’s blog here<\/a>.)<\/p>\n

With many production data sets spawning anywhere between 4 and 10 copies, and sometimes a lot more, a question that gets asked from time to time is: why would I need to duplicate my backups?<\/em><\/p>\n

It seems a fair question if you’re using array to array replication, but let’s stop for a moment and think about the different types of data protection being applied in this scenario:<\/p>\n

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

Let’s say we’ve got two sites, production and disaster recovery, and for the sake of simplicity, a single SAN at each site. The two SANs replicate between one another. Backups are taken at one of the sites \u2013 in this example, the production site. There’s no duplication of the backups.<\/p>\n

Replication is definitely a form of data protection, but its primary purpose is to provide a degree of fault tolerance \u2013 not true fault tolerance of course (that requires more effort), but the idea is that if the primary array is destroyed, there’s a copy of the data on the secondary array and it can take over production functions. Replication can also factor into maintenance activities \u2013 if you need to repair, update or even replace the primary array, you can failover operations to the secondary array, work on the primary, then fail back when you’re ready.<\/p>\n

In the world of backups there’s an old saying however: nothing corrupts faster than a mirror. The same applies to replication…<\/p>\n

“Ahah!”, some interject at this point, “What if the replication is asynchronous? That means if corruption happens in the source array we can turn off replication between the arrays! Problem solved!”<\/p>\n

Over a decade ago I met an IT manager who felt the response to a virus infecting his network would be to have an operator run into the computer room and use an axe to quickly chop all the network connections away from the core switches. That might actually be more successful than relying on noticing<\/em> corruption ahead of asynchronous replication windows and disconnecting replication links.<\/p><\/blockquote>\n

So if there’s corruption in the primary array that infects the secondary array \u2013 that’s no cause for concern, right? After all there’s a backup copy sitting there waiting and ready to be used. The answer is simple \u2013 replication isn’t just for minor types of fault tolerance or being able to switch production during maintenance operations, it’s also for those really bad disasters, such as something taking out your datacentre.<\/p>\n

At this point it’s common to ‘solve’ the problem by moving the backups onto the secondary site (even if they run cross-site), creating a configuration like the following:<\/p>\n

\"Replication,<\/a><\/p>\n

The thinking goes like this: if there’s a disaster at the primary site, the disaster recovery site not only takes over, but all our backups are there waiting to be used. If there’s a disaster at the disaster recovery site instead, then no data has been lost because all the data is still sitting on the production array.<\/p>\n

Well, in only one very special circumstance: if you only need to keep backups for one day.<\/p>\n

Backups typically offer reasonably poor RPO and RTO compared to things like replication, continuous data protection, continuous availability, snapshots, etc. But they do<\/em> offer historical recoverability often essential to meet compliance requirements. Having to provide a modicum of recoverability for 7 years is practically the default these days \u2013 medical organisations typically have to retain data for the life of the patient, engineering companies for the lifespan of the construction, and so on. That’s not all<\/em> backups of course \u2013 depending on your industry you’ll likely generate your long term backups either from your monthlies<\/em> or your yearlies<\/em>.<\/p>\n

Aside: <\/strong>The use of backups to facilitate long term retention is a discussion that’s been running for the 20 years I’ve been working in data protection, and that will still be going in a decade or more. There are strong, valid arguments for using archive to achieve long term retention, but archive requires a data management policy, something many companies struggle with. Storage got cheap and the perceived cost of doing archive created a strong sense of apathy that we’re still dealing with today. Do I agree with that apathy? No, but I still have to deal with the reality of the situation.<\/p><\/blockquote>\n

So let’s revisit those failure scenarios again that can happen with off-site backups but no backup duplication:<\/p>\n