Tony CantaveMy CompTIA Cloud+ Notes on Backups, Snapshots and Recovery Objectives

When I studied for CompTIA Cloud+, the backup and recovery material looked easy at first. Everyone knows you should back things up. The exam does not ask whether you should. It asks how much data you can afford to lose, how long you can afford to be down, and which type of copy gets you there. These are the notes I kept, rewritten so they make sense outside of a study guide.

Start with two numbers: RPO and RTO

Recovery point objective (RPO) is how much data, measured in time, you can afford to lose. If your RPO is four hours, a backup that runs once a day is not good enough, because a failure at the wrong moment could cost you almost a full day of work.

Recovery time objective (RTO) is how long a system can be down before the outage becomes unacceptable. An RTO of one hour rules out any plan that depends on someone downloading a large archive over a slow connection and rebuilding a server by hand.

I learned to write these two numbers down before choosing any technology. The numbers decide the design, not the other way around. A small personal project might accept an RPO of a day and an RTO of a weekend. A system that takes orders for a business might need an RPO measured in minutes.

Full, incremental and differential

Cloud+ expects you to know the three classic backup types and the tradeoff each one makes.

A full backup copies everything. It is the simplest to restore, because one set holds all the data, but it takes the most time and storage.

An incremental backup copies only what changed since the last backup of any kind. Each run is small and fast. The cost shows up at restore time: you need the last full backup plus every incremental after it, in order. Lose one link in that chain and the restore stops there.

A differential backup copies everything that changed since the last full backup. Each differential grows as the week goes on, but a restore needs only two pieces: the full and the most recent differential.

My memory trick: incremental is cheap to make and expensive to restore, full is expensive to make and cheap to restore, and differential sits in the middle.

Snapshots are not backups

This was the point I got wrong on my first practice test. A snapshot captures the state of a virtual machine or a storage volume at a moment in time. It is fast and very useful before a risky change, like an update or a configuration edit. If the change goes badly, you roll back in minutes.

But a snapshot usually lives on the same storage system as the original. If that storage fails, or the account is compromised, the snapshot can disappear along with the data it was protecting. Snapshots can also slow storage down when they pile up, so they should be short lived. A real backup is a separate copy, stored somewhere that does not share the same point of failure.

The three two one rule

The guideline that ties it together: keep three copies of your data, on two different types of storage, with one copy offsite. In cloud terms, offsite often means a different region or a different provider. Many guides now add one more idea: keep at least one copy that cannot be changed or deleted for a set period, so a mistake or an attacker cannot wipe out every version at once.

A backup you never restore is a guess

The Cloud+ material stresses testing restores, and this is the lesson that carried over most into my own work. A backup job that reports success only tells you the job ran. It does not tell you the files are complete, readable or recent.

On my own projects I run a small Python check that answers the simplest questions: does a backup exist, is it recent, and is it a reasonable size?

from datetime import datetime, timedelta
from pathlib import Path

BACKUP_DIR = Path("backups")
MAX_AGE = timedelta(hours=26)
MIN_SIZE_BYTES = 1_000_000

def newest_backup(folder):
    files = list(folder.glob("*.tar.gz"))
    return max(files, key=lambda p: p.stat().st_mtime) if files else None

def check_backup():
    latest = newest_backup(BACKUP_DIR)
    if latest is None:
        return "FAIL: no backup files found"
    info = latest.stat()
    modified = datetime.fromtimestamp(info.st_mtime)
    if modified + MAX_AGE < datetime.now():
        return f"FAIL: newest backup {latest.name} is older than {MAX_AGE}"
    if info.st_size < MIN_SIZE_BYTES:
        return f"FAIL: {latest.name} is only {info.st_size} bytes"
    return f"OK: {latest.name}, {info.st_size} bytes, {modified:%Y/%m/%d %H:%M}"

if __name__ == "__main__":
    print(check_backup())

The 26 hour limit gives a daily job a little slack so a slow night does not trigger a false alarm. The size floor catches the classic failure where a job runs, finds nothing to copy, and writes an empty archive that still counts as a success.

This does not replace a real restore test. On a regular schedule I restore the newest archive into a scratch folder and open a few files to confirm they are what I expect. But the daily check catches the most common problem, a job that quietly stopped running, within a day instead of whenever someone finally needs the data.

Why these notes stuck

Years of running delivery routes and production schedules taught me that a backup plan only matters if it has been tried before the bad day. A spare truck nobody has started in months is not really a spare. Backups work the same way.

If you are studying for Cloud+, learn RPO and RTO first. Most backup and disaster recovery questions get easier once you ask which of those two numbers the scenario is really about, and then pick the type of copy that meets it.