TechKnowSurge

VideoSecurityFree

What to Backup

Effective backup strategy requires deciding what data to protect and at what level of granularity, balancing recovery speed against storage costs and operational complexity. The right approach depends on defined recovery objectives and the relative criticality of databases, servers, files, and directory information.

⚑ Complete this video to capture a CTF flag worth 1 point.

About this video

A sound backup strategy begins with a clear answer to one fundamental question: what actually needs to be backed up? The answer is rarely everything and rarely just the bare minimum. Most organizations land somewhere in between, making deliberate decisions based on how dynamic the data is, how difficult it would be to recreate, and how quickly it needs to be restored after a failure. Those decisions directly shape storage requirements, backup windows, and recovery timelines. Databases almost always sit at the top of the priority list because they contain live, constantly changing information that cannot simply be reinstalled. Servers occupy the opposite end of the spectrum in many cases. If infrastructure can be redeployed through code or rebuilt from installation media, a full server backup may be unnecessary or at least less urgent. Where server backups do make sense, capturing just the system state rather than the entire machine can significantly reduce backup size while still preserving the configuration needed to restore a system to its previous state. Files, folders, and directory data including usernames and credentials represent additional layers that also need to be evaluated and assigned appropriate protection. Granularity introduces another dimension to these decisions. Backing up a full virtual machine guarantees the most complete restore but makes recovering a single file unnecessarily complex. Backing up only at the file level risks losing an entire system with no efficient path to rebuild it. A tiered approach resolves this by matching the backup scope to the asset's criticality and recovery requirements, so a high-turnover database server might receive daily backups while a relatively static web server warrants only weekly snapshots. Every backup decision should ultimately trace back to defined recovery objectives, specifically what the organization needs to restore, how completely, and how fast.

What you'll learn

Identify the key categories of backup targets — including databases, system state, files and folders, and full virtual machines — and describe the trade-offs associated with each backup scope
Explain how recovery time objectives and data criticality influence decisions about backup granularity and backup frequency

What's covered

Backup Considerations

What to Back Up
- Databases
  - Dynamic, hard to recreate
  - Daily backup frequency
- Servers
  - System state only
  - Weekly if more static
- Files and Folders
  - Customer or employee files
- Directory Information
  - Usernames and passwords
Backup Tiers
- Full Virtual Machine
  - Slower, larger backup
  - Required for single file restore
- File Level Backup
  - Faster, targeted
  - Whole system loss risk
- Everything In Between
Recovery Objectives
- Fast recovery needs
  - Back up full servers
- Backup frequency varies
  - Based on data change rate
- Infrastructure as Code
  - Redeploy servers via automation

Key terms

Recovery Time Objective: The maximum acceptable time to restore a system or service after a disruption.
Recovery Point Objective: The maximum acceptable amount of data loss measured in time, defining how far back data must be recoverable.
Virtual Machine: A software emulation of a physical computer that runs an operating system and applications.
Infrastructure as a Service: A cloud service model that provides virtualized computing infrastructure over the internet.
System State: A snapshot of a server's critical configuration data, including settings and registry information, used to restore a server to a previous operational state without requiring a full backup.
Backup Granularity: The level of detail at which data is backed up, ranging from individual files to full virtual machines, which affects both recovery speed and storage requirements.
Disaster Recovery: The process and procedures for recovering IT systems and data following a disruptive event.

Topics

Backup Strategy Data Backup Recovery Time Objective Backup Granularity Disaster Recovery Data Protection

Transcript

What are we going to back up?

One of the questions we need to ask ourselves is, what are we going to back up? We could back up everything, but that might not be realistic. Or we can back up just the core critical information, but that might be really painful if we have to do a full restore. So maybe we do something in between. There are some considerations to what we back up.

More often than not, we're probably going to be backing up our databases. This typically is more dynamic information and stuff that we can't really recreate, so it's probably something that we're going to want to back up.

Versus a server, which is on the other side of the spectrum. If there's anything that we're not going to back up, then the servers might be just that — these might be something that are not all that critical, or maybe they're critical but we can do a full restore by finding install files and just putting it out there. In fact, we could have infrastructure as code and we could push a button and it could deploy all of our servers up in the cloud, so it might not be as much of a concern to get a backup of those servers. Or maybe, if we want to have really fast recovery times, then maybe we do need to be backing those up.

But maybe we don't necessarily need all of the server. Maybe just a subset of the configurations. There's something called a system state on the servers. We could maybe just back up the system state and get a copy of that. Then if we need to do a restore, we roll out the servers again and then do the configuration and system state — we do a restore of those and get the servers back up and running where they were before.

Another thing that we could be backing up are files and folders — maybe our customers' files and folders, or maybe it's our employees' files and folders. And then also directory information, things like usernames and passwords. We probably want to back up our systems.

Levels and tiers

I also think of these as kind of levels or tiers. At the very far end on the left side, we back up a whole virtual machine, and that's obviously going to take longer. And then on the other side we have the file, and we're just backing up a file. And then we have everything in between.

Some of the disadvantages to capturing the whole machine is that if we want to recover a single file, we have to do a full restore of that machine before we can get to the file and do a restore on the file. And vice versa: if we just are backing up the file and we lose the whole system, now we have to recreate it all, and that could be problematic.

So there's kind of levels here, both with just machines and servers and also with databases, on what level are we backing things up to. And they don't all have to be the same. So here we have a database server, and maybe we're backing this up on a daily basis and we want to back those databases up on a daily basis. And then here we have some web servers that are a little more static, that we just update now and then, so maybe we update those or grab a copy of those on a weekly basis.

What we back up is just going to be based off of what we determine our objectives are. What are we trying to achieve?

Read the full transcript Show less

About TechKnowSurge

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 →