Designing an effective backup strategy requires evaluating multiple factors, including data criticality, recoverability, cost, recovery objectives, backup windows, security, and how frequently data changes.
Backup Strategy Considerations
When designing our backup, there's several considerations that we have to think about. So let's start exploring what some of those considerations look like.
When we're choosing a backup strategy, there's going to be several considerations that we're going to have, such as: is it recreatable data? Is it critical? What's the criticality of it? What's the cost? What's the RPO, RTO? What time frames are we trying to achieve from a recovery standpoint? What type of disruption is it going to have? What do the backup windows look like? What does security look like? And how dynamic is the information that we are actually going to be backing up?
My employees made fun of me for coining the term nonrecreatable data. I've not heard anybody else say that before, but I think it makes complete sense to me when I say nonrecreatable data. What does that even mean? What does recreatable mean?
Essentially, we have maybe a server. If I'm setting up a server, there is data involved with installing the operating system, getting things set up. There is data and time that I use to set that all up. Now, for the most part, I really don't need to save that. I don't necessarily need a backup of that server. If I need to, I can go download those server install files again. I can put the licensing on again. I can install the software again. I can recreate that server and set it up and get it up and running back to where it was before. It might take some time to do that, but I still can do it. I can figure it out.
But there is some data that once we lose, it's gone. For instance, maybe it's some sort of customer statistics or customer data, or who's logged into your system, or maybe it's some sort of critical data that we have that we can't recreate, that once it's gone it no longer exists. We can't get it back. This is what I would classify as nonrecreatable data. This is the real critical stuff that we need to 100% make sure we got right. This is important too because there are certain time targets that we might have. This is the stuff that if we don't have a good copy of it, it could be devastating to the company or organization.
Now, there are times when that data could be recreatable but it's still very critical, or times when that data we can't recreate but it's not very critical. What are some examples of this? We might have customer identification information, and this is something that once we lose, we could lose it altogether. We could not have it again. Not only that, but it's really critical because we're selling to these customers, so the criticality of this information is really important. We could also have maybe some statistics that we're keeping that is not as important, that we really don't do much with, and so the criticality is really low. It's nonrecreatable, but the criticality of that information is pretty low on the spectrum.
Something to factor into this is cost. The cost is how much is it going to take to back this up? Maybe this is a large amount of data, for storing this data that's not very critical. That seems like a big waste if it's costing a lot to store it. What I found is that storage costs nowadays are pretty cheap and it's not a very big investment from that perspective. But there are other costs involved in this as well. I have to manage all of this data and I have to keep track of it, and so there's actually a cost to the management of that data as well. We've got to think about the cost of how much is it going to cost to back up this data.
We also have to take into account how much disruption our systems will have. That is for our end users. Are we going to start losing customers and money if our systems are down for a longer period of time? Same thing when it comes to our internal users: do we lose productivity with that? Here again, that really plays into that recovery point objective and the recovery time objective. How far back are we willing to lose, and how long until we actually recover and get those systems back up and running?
Another consideration is what do the backup windows look like? Can we just do it on the weekend, or can we do it on the weekdays? What does that look like? Because I've certainly had backup windows, backup times, that extend beyond just a single day if there's a lot of data that you're backing up, and that can be problematic. This is an important factor when you're deciding what you're going to back up and how you're going to back it up.
This also could be very sensitive data. If it's very sensitive data, what security concerns do we have over this? What security considerations should we consider when implementing backup?
Another thing also is how dynamic is this information? Is it like a server that you set up and really doesn't change over weeks or months or even years? Or is this a server that changes constantly, that's pulling in new data all the time? How dynamic this data is might depend on how often we back it up and what our backup solution looks like.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →