Rapid Data Recovery
Companies depend on data to drive business insights, reduce risk and gain competitive advantage. The recent intense acceleration of unstructured data has catapulted the overall importance of this data straight to the top of the food chain for modern companies. With a higher level of importance comes increased scrutiny of data security, and ensuring enterprises have sound data recovery strategies in place.
Once upon a time, companies focused on having a great “backup” strategy. But with the amount of both structured and unstructured business-critical data continually growing, companies have shifted focus from simply “a great back strategy” to the operational intricacies of recovery. In this blog, I will take a different approach when talking about data protection by focusing on structured data, and how Database Administrators (DBAs) protect their organization’s most mission critical systems, such as Oracle, Microsoft SQL or SAP, and how Qumulo is being used to support these strategies to meet key recovery objectives.
Protecting Mission Critical Applications
The most mission critical applications are often built on the foundation of structured data sets living within databases such as Oracle and Microsoft SQL. The DBAs managing these databases not only need to ensure that databases perform optimally to power the applications, but also have a robust data protection strategy to meet the company’s stated Service Level Agreement (SLA) for Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).
RTO vs RPO: What’s the difference?
Before going too deep, it is important to understand a few terms I will be using in this blog. While these have been around for some time, I feel it is important to restate what these terms mean and how they differ in order to build off this baseline in this blog. .
We often hear RTO/RPO anytime the topic of data protection arises, but what is it and why is it such an important article of discussion? Very simply speaking, these two items refer to your tolerance for loss. I know it sounds negative talking about loss, but the reality is that is the true origin of the Recovery Time Objective and Recovery Point Objective terms.
How much data can you tolerate to lose (RPO) and how long can you tolerate being down (RTO). This will be different for every customer, and if you do not have a documented RPO/RTO for your environment, I strongly recommend chatting with one of our system engineers or your reseller partner. Having this knowledge goes hand in hand with developing a solid recovery strategy and disaster recovery plan, which I will discuss in the next section.
Beyond the Application
We all understand how important the DBA is to any organization, from making sure the database and applications are running smoothly and all customers/users have access. But what often is not recognized is the level of effort DBAs invest to provide the uptime and availability of applications and its foundation, the database. While traditional IT is typically responsible for day-to-day management of storage solutions, virtual infrastructures, cloud environments, and functional operations, such as backup, and disaster recovery (DR) plans, most DBAs are quietly behind the scenes creating their own plans to support the health of the application ecosystems. It has been my experience that the DBAs are the last line of defense when it comes to data protection and application availability. Therefore, it makes sense that DBAs would create a solid recovery strategy and DR plan to support their independent efforts in the event of a business interruption. Incidentally, before I go on, let me define this term you have now seen twice in this blog, “business interruption”. It is the event that occurs when you experience an inability to access the systems and/or data to drive your business. It is only a business interruption, as long as you recover within the guidelines of your stated SLA and RTO/RPO. Beyond those objectives, a business interruption becomes a disaster. This is why it is important to know these critical data points for your own environment, and believe me, if you ask your DBA what their RTO/RPO is, they will know.
Looking Ahead to Part II
In this two part series we introduced Qumulo Rapid Recovery and why a “backup” strategy just isn’t enough anymore for most organizations. Rather, the focus has shifted to operational recovery or “business as usual” which really makes the discussion around RTO/RPO even more relevant.
However, we brought up a topic not many talk about and that is the unstructured data growth and the challenges facing DBAs today. According to IDC, data growth is projected to reach 180 ZB by 2025, further, 80% of the global data will be represented by unstructured data by 2025 with the balance presumably being structured and semi-structured data. Through our snapshot technology we are able to handle the tremendous growth and protection of unstructured data, but structured data or databases must be handled differently in order to meet the recovery objectives of most organizations. How are DBAs prepared to support this growth and create an operational recovery strategy to meet their company’s RTO/RPO? Be sure to check out Part II of this blog to get my opinion and how Qumulo is already helping customers achieve these objectives with Qumulo Rapid Recovery.
Protect Your File Data Storage from Ransomware with Holistic Security
Erasure Coding vs. RAID Explained: Methods for Data Protection
