Appreciate your data before it's gone

We all know that data is important. That it's valuable. But it's a lot like breathing - we know we need it and that it is valuable, but 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. The nature of data in any of our given systems, applications, services, devices, etc. is that it has three main life phases: create, update, and read. Why not delete? Because it is a death phase - deletion is the end of the existence of that data.

We are all faced with a myriad of systems, applications, and tools that produce and consume data. If your application isn't providing the ability to create, update, and read data, then what exactly is it good for? We also need to imagine how good or valuable those systems and tools will be if the data is once there then unexpectedly removed.

When good data gets removed from an application, the value gets instantly diminished. Enter the old-world rigor of backup and restore. While backup is a copy function and generally easy in any system or tool, the ability to perform a restore presents a multidimensional set of challenges like the ability to impersonate as a system user, etc. So how do we get good data back when it disappears?

Largely, we have one of two choices: we can buy an existing auxiliary application, or we can design and build one from scratch. Either choice exemplifies the importance and need to have a backup strategy that includes the ability to restore our data. And, of course, before restoring, we need a fast and easy method to find the right data to work with. Spoiler alert, it's NOT Excel anymore!

Working here at OwnBackup the past couple years, I have been lucky to see the maturity of backup and recovery requirements from many thousands of customers across nearly a decade of active usage in the product. 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 Controlled dark hours 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 Headless design: 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 & maintain: Nobody wants to add complexity to an already overly complex world. The KISS methodology applies here and should be prioritized.

# 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 Tabel level backups: As databases get larger and larger, backups naturally will take longer and longer. Making sure you can back up just your key tables (maybe with 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 good 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 when 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 times, the "smoking gun" could potentially be in one of several different backups, so every possible one would need to be restored in order to search for the needed data. A more robust solution would be to allow an easy search mechanism for one or more backups without having to do 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 else, we find ourselves stitching data relationships back together manually which almost always runs into human error in 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 Salesforce, Dynamics365, or ServiceNow, feel free to contact my company for information on our product that offers these features for those customers. Otherwise, happy backing up and recovering!