When considering whether to backup or replicate to protect your data, there’s a lot to consider.
Your business creates and uses a lot of data. If you were to experience any form of disruption that impacts your data or access to it, you need to know where to focus your resources to enable you to resume operations as swiftly as possible. Your main options are backup or replication. So which do you choose, and why?
Paul Timson our Product Manager for business continuity, shares his top tips and advice on how to get this right…
Firstly, it’s important to classify your data, applications and their dependencies so that you can apply the most appropriate level of protection to all of your data. This will help you to focus on recovering what’s most important when recovery is required, so that you don’t prioritise less important data at the expense of something more critical.
Working out recovery time and recovery point objectives
Customer facing systems need to be recovered quickly if there’s an incident. It’s important to set a recovery time objective (RTO) that you can plan for, so that you have a strategy for recovering your data before productivity, customer service and even your reputation, are impacted by downtime. (Your RTO is your maximum acceptable period of downtime.) There will be data that’s not just important, it’s business-critical and the impact of its loss can be measured by the second – you not only need to think about availability and downtime, you also need to meet your required recovery point objective (RPO) so that you can make adequate provision to keep critical data loss to an absolute minimum. (Your RPO is your maximum acceptable amount of data loss, measured in time.) Once you consider your data loss tolerance, imagine a situation where your data gets stolen (exfiltrated) from your company and held to ransom.
Encrypting your commercially sensitive data or crown jewels, is essential to ensure that even if your data is stolen, it’s unreadable. Immutability is important because it makes your backup copies read-only and no-one can delete them. These are the basics you need to get right before you begin to look at the wider attack threats from cybercrime which we’ll look at another time.
Some initial data protection considerations
Before making any decisions about backup and replication, it’s important to remember that how you protect your data will impact your recovery options. Knowing what systems interact with other systems and even external supply chain systems will impact your recovery plans.
6 key data protection questions to help inform your strategy…
Important questions that you need to think about, across your data sets and workloads:
- Do you know where your data is stored? Is it on your premises and encrypted or stored elsewhere like public cloud? Is it immutable and in another location when it’s backed up? You must ensure you have an encrypted, immutable air-gapped copy of your data as your reliable go to source for recovery.
- Do you know if your data is all protected and how many different tools and teams you operate to keep it safe? In an ideal world one product to backup everything would be perfect, and it can be done. However, usually backup tools have grown organically to protect this or that, and there are different silos of data and teams to manage them, all with different capabilities. This can be a big overhead so it’s well worth looking at an overhaul of your backups to see if one tool can do all of it – it’s likely to pay for itself with saving in management overheads. The other big benefit of a single tool is that it can help you in managing your dependency mapping, so recovery from any incident becomes easier.
- How often do you test that you can fully recover - and how long does it take, with how many people involved? On-demand and automated rehearsals are now becoming a standard requirement of data protection and recovery because an annual DR test no longer cuts the mustard. Regular weekly/monthly testing can prove your recovery plans and timescales whilst also flagging up any issues before you really need to rely on them. If you’re only testing once or twice a year, consider adopting an automated on-demand approach as these are often easy to do and don’t involve lots of resource from your company or provider and the benefits are huge. Not least of which is, if you perform an automated recovery on what you believe is a dependent group of servers or applications (a subset of your entire estate) and then find there’s a change that’s been made or a new application installed which means this now also needs to be included. Better to find out before you need to rely on it!
- How much data can you tolerate losing? Zero data loss is the aim, but we all know reality just doesn’t match that unless you have very deep pockets and endless resources. Losing an hours’ worth of data or 15 minutes can be costly but this is where valuing your data and its dependencies is key. The value of the data will then help you protect it accordingly and give your business the ability to determine the loss vs cost decision-making. Focussing on what we call your ‘critical viable business’ - what’s the minimum IT setup that will keep you in business and what workloads, apps and networking will be needed to provide it? This is a great place to start and will help prioritise your recovery.
- Do you know the relative importance and dependencies of your different types of data? Similar to other points we’ve discussed already, the value of data and its dependencies runs right through every aspect of data protection and recovery. Knowing how data moves between systems, understanding where it is at risk - does it pass over networks outside your organisation? Knowing your systems and the data they work on will drive your decisions on protection and will impact recovery. This feeds into your recovery strategy as often, inter-dependent systems need to be recovered together.
- If one application is compromised and needs recovering, will other dependent systems also need to be rewound to the same point to maintain consistency? Today’s IT very rarely sits in isolation, particularly with the advent of containers where developers can build small interacting components into an application. Recovering only part of that group of interworking parts may result in others failing because they are less or more up to date than those recovered. This is most starkly demonstrated with point-of-sale applications where customers may interact with an application and choose a product to purchase, which then passes information to a stock system and then a billing system and finally logistics to get it delivered. If the stock system has an issue and is recovered to, say, last night, but the other systems are up to date as of now, the stock system may not report correct stock levels or refuse to work as it cannot work with the now out of sync billing system. So, it pays to know what each component talks to and relies on when recovering partial systems.
So what does this all mean? Should you backup or replicate or both?
I recommend that you always backup, this can be as frequent as every 15 minutes, if need be, and replicate only as required for selected key workloads.
Replication is brilliant for what we refer to as ‘traditional IT disasters’, such as user error, upgrades gone wrong, malicious insider, fire, server failure…the list is endless.
Replication is not so good when a cyber incident occurs and here’s my reasoning, whether you agree with me or not:
- Backups can be achieved every 15 minutes compared to seconds for replication, which means that for replication to be better than frequent backup, your cyber incident needs to be cleaned up within 15 minutes, which is unlikely.
- Replication is intended to be able to failover immediately an incident occurs. In a cyber incident you cannot failover because you will failover to a duplicate problem. You will have called in your cyber incident responders from Wavenet or another provider, who will spend hours and often days forensically investigating the infiltration, the damage and the steps to remediate so you don’t get a repeat break in.
- Once you have passed the seconds/minutes elapsed time that replication gives you, recovering from a backup becomes more attractive. It is possible for replication tools to keep a journal for up to 30 days, so it may be possible after the cyber teams have finished and give you a safe restore window, replication can still be of use. However, booting directly from a clean backup offers the same options at a lower cost than recovery from replication. The dwell time that an infiltration has been in progress is on average longer than 30 days, rendering replication obsolete.
- However your cyber incident management team supports you, there will be the need for a cleanroom or isolated recovery environment in which to restore your data to be checked as clean by forensics before you restore to the required recovery location, whether that be public cloud or our range of recovery options. Each workload and its dependencies and the recovery order and point in time need to be considered as we have mentioned in the earlier points.
Benefit from an experienced business continuity and cyber resilience provider
Both backup and replication have their place, but no incident is the same for any business so it’s important to seek advice from a provider with industry and recovery experience. Traditional data protection and recovery will protect you well when it is done correctly and looked after, but please do not rely on this when cyber comes calling – specialist responses are required here and it’s important to have the right protection in place.
About the author
Paul Timson is the Product Manager in business continuity at Wavenet. He has worked in the business continuity field for almost his entire career, and with Wavenet for over 35 years. Starting out helping DEC VAX and AXP customers, through to delivering our comprehensive business continuity, disaster recovery and cyber resilience services as a technical engineer, to now planning and looking to the future to ensure we’re able to protect our customers, come what may.
