I’m going to state the obvious: <a href=”/resources/big-data-disaster-recovery/”>big data</a> is a complex animal… and it’s <a href=”https://www.linkedin.com/pulse/20140925030713-64875646-big-data-the-eye-opening-facts-everyone-should-know”>getting hairier by the minute</a>. But unfortunately, too many organizations add to that complexity by managing their big data environments with APIs, scripts and duct tape.
As NoSQL data stores become a larger component of “big data,” preparing for backup and disaster recovery has never been more important. The common method of managing and executing partial backup and recovery by using scripts that require lots of resources (time, money, and staff orchestration) are taking their toll on IT pros. A better but still not complete remedy to this problem is active-active replication of NoSQL workloads in other data centers (known as “disaster avoidance”).
According to <a href=”http://www.emc.com/about/news/press/2014/20141202-01.htm”>a new EMC study</a>, 71% of IT pros are not fully confident in their ability to recover information following an incident. Additionally, the study revealed that 51% of organizations lack a disaster recovery plan for emerging workloads.
The big questions to ask: What if there’s replicated data corruption? Or, when your NoSQL backup and disaster recovery strategy is comprised of writing scripts, and pushing them to on-premise storage products from EMC, Dell, HP, Hitachi, IBM, etc. or to the cloud via services like AWS (Amazon Web Services), what if the script fails? What if recovery fails? And if either fail, does the script alert you? Is the script continually backing up the entire NoSQL environment – creating bloat – versus backing up deltas from different points in time? What if your public cloud service fails?
Ok, so that’s a lot of questions. But they’re important ones if you’re serious about coupling disaster avoidance with a backup and disaster recovery strategy for NoSQL deployments. You’re going to need speed, flexibility and assurances when disaster strikes. If your NoSQL backup plan is still built on scripts and replicating copies to a local storage or a public cloud, remember that these scenarios can take hours or days to repair when lost minutes mean lost revenue. Would you drive a car, own a home or manage your health without insurance? Is it time you thought about your <a href=”http://whatis.techtarget.com/definition/recovery-time-objective-RTO”>recovery time objectives (RTOs)</a> and <a href=”http://whatis.techtarget.com/definition/recovery-point-objective-RPO”>recovery point objectives (RPOs)</a>?
Trilio offers a better way.
Trilio takes policy-based point-in-time snapshots of the NoSQL container that consists of the compute resources, network configurations, and storage data as a whole. The benefits are faster and more reliable recovery, easier migration of YOUR environment and simplified virtual cloning of the workload in its entirety.
With Trilio, recovery no longer requires having to wake up networking and database teams in the middle of night to rebuild and orchestrate entire workloads. Trilio’s self-service solution helps simplify a complex environment and one person is all it takes to manage backups.
For more information on a better path to NoSQL backup and disaster recovery, contact us (<a href=”mailto:firstname.lastname@example.org”>email@example.com</a>) about our upcoming webinar series or ask for a demo today!