Where there’s data, there’s disaster recovery planning, right? By now, many organisations (but by no means all) have understood the need to put disaster recovery solutions in place for mission critical apps and the data they use, crunch, or generate.
However, for big data – all those terabytes or petabytes of “stuff” from unstructured data banks, archives, images, videos, and so on – DRP is not quite so clear cut. Should you back it all up with the same diligence as for your CRM system and sales transaction SQL database? Should you back any of it up?
Perhaps before trying to answer such questions, we should understand what we really mean by big data.
Big data can be “stuff” your organisation has collected or created. It can be “stuff” your enterprise uses to gain insights into which types of products to promote in sales to its customers, or for detecting fraud in financial transactions.
These examples already give us some hints about how to set about plans for disaster recovery. If your big data comes from other sources, those other sources may be sufficiently trustworthy for you to rely on them to keep that data safe. Geographical and meteorological data are examples.
As a supermarket chain running big data analytics to determine what to ship to outlets as a function of local weather conditions, you may not even want to keep the data from one run of your analytics app to another, if only today’s weather forecasts are of interest to you.
But what if you use your big data to protect your enterprise or stakeholders? Banks running fraud detection programs are likely to be far more careful about their historical big data records, which will be used over and over to spot fraud patterns and act to nip criminal acts in the bud.
Disaster recovery plans will then probably be built using principles and elements already familiar to you: time to recovery, priority levels for different files and volumes, recovery points, and compliance, as required.
So tackle big data disaster recovery with same tried and trusted principles in the first place, namely, definition of your business objectives, criticality of data in meeting those objectives, and regulatory aspects. That will already be a big step forwards.