We all know that data is important and valuable. It's a lot like breathing, though - while we know we need it, we don't appreciate it enough while we have it. Now hold your breath and read the rest of this article if you can - you'll appreciate those breaths more by the end.
Data is the same way. Data has three main life phases within any of our given systems, applications, services, and devices: create, update, and read. Why not delete? Because deletion is the end of life of that data.
We are all faced with a myriad of systems, applications, and tools that produce and consume data. If your application can't create, update, and read data, what exactly is it good for? You also need to consider how valuable those systems and tools are if the data is unexpectedly removed.
When good data is removed from an application, its value is instantly diminished. Enter the old-world rigor of backup and restore. While backup is a copy function that is generally easy in any system or tool, the ability to perform a restore presents several challenges, like impersonating a system user, etc. So how do you get good data back when it disappears?
Essentially, you have one of two choices: buying an existing auxiliary application or designing and building one from scratch. Either choice exemplifies the importance and need for a backup strategy that can restore our data. And, of course, you need a fast and easy method to find the right data to work with before restoring. Spoiler alert, it's NOT Excel anymore!
Working at Own for the past couple of years, I have been lucky to see the maturity of backup and recovery requirements from thousands of customers across nearly a decade of active product usage. What I've gleaned from it are ten key requirements that a good backup and recovery solution should satisfy. In true Letterman style, I'll do these in reverse order!
10) Planned downtime for execution
This will allow you to plan your backups around your other processes, end-user access times, integrations, and so on to mitigate or prevent resource conflicts.
9) Independent of production
This is to ensure the backup and recovery solution is not dependent on the system where the data is being stored. If the source system goes down, then so does the backup which defeats the purpose entirely!
8) Low effort to deploy and maintain
Nobody wants to add complexity to an already overly complex world. When it comes to your data backup and recovery solution, implementation is especially important since it affects how quickly you can begin protecting your data.
7) Should not consume storage used by the application
When backup systems store on the same infrastructure as an application, it then competes with the availability of resources, so it's always best to store the data elsewhere.
6) Controllable backup retention
With compliance requirements growing across all industries, it is more imperative now than ever to have the ability to set your own backup retention policies.
5) Table-level backups
As databases get larger, backups will naturally take longer. Making sure you can back up just your key tables (maybe with a higher frequency even than the full backup) is a must-have in today's application environments.
4) Intelligent alerting on backup contents
It's no longer enough to just know when a backup succeeded or failed. In today's world, the best practice is to know what is happening inside each backup compared to the last known good backup. An ideal backup and recovery solution will offer the ability to configure alerts based on the content changes of backups.
3) Ability to search backups without restoring
One of the big challenges with data recovery is knowing where to find the data to restore. Often, the affected data could be in one of several different backups, so every possible backup would need to be restored to search for the needed data. A more robust solution would be to allow an easy search mechanism for one or more backups without doing multiple restores first.
2) Ability to view and easily compare backups without restoring
The second-largest time-consumer in an RTO (Recovery Time Objective) is waiting for systems to restore before querying to find the right data to restore (which is the largest time-consumer). Eliminate both of these with a backup and recovery solution that allows for in-place comparisons and transparent visibility into what is stored in the backup.
and for the top spot...
1) Ability to restore datasets, table-level, row-level, field-level with relationships
Backing up is relatively easy, but restoring gets more difficult. To that point, restoring at multiple granular levels is key. Also, being able to dynamically rebuild relationship hierarchies is critical. Without it, you’ll find yourself stitching data relationships back together manually which almost always introduces human error into the process.
So there you have it - and yes, you can exhale now - the best ways to plan for a backup and recovery strategy for your modern applications. If you operate on Dynamics 365, reach out to Own for information on our Recover product. Otherwise, happy backing up and recovering!
