Backup types, schedules and retention

Why this matters

CompTIA's bullet is implementing strategies to ensure data integrity, and backup is the core of it. It is also the area where confident wrong answers are most common, because cloud platforms make backups so easy to enable that people stop thinking about what they actually have.

The three ideas that do the work: a snapshot is not a backup, a backup that has never been restored is an assumption, and a copy that shares a failure domain with the original is not a second copy. Everything else is detail hanging off those.

The next lesson covers restore testing, which is where the assumption becomes knowledge. This one covers what to take and how long to keep it.

The lesson

Full, incremental and differential, and the restore time each implies

Three classical backup types, and the exam expects the distinction precisely.

• Full. Everything, every time. Largest storage, longest backup window, fastest and simplest restore — one set of media.
• Incremental. Everything changed since the last backup of any kind. Smallest and fastest to take. Restore requires the last full plus every incremental since, in order, so restore time grows through the cycle and a single damaged increment breaks the chain.
• Differential. Everything changed since the last full backup. Larger than incremental and growing each day until the next full. Restore needs the full plus one differential — a middle ground, and a more robust one.

A typical schedule is a weekly full with daily incrementals or differentials. The choice is a trade between backup window and recovery time, and it should be made from the RTO in the next-but-one lesson rather than from habit.

Cloud storage complicates the vocabulary usefully. Most cloud snapshots are incremental in storage but full in behaviour: only changed blocks are stored, yet any snapshot can be restored on its own without needing its predecessors. That is genuinely better than classical incrementals — but it means snapshots are interdependent in storage, so deleting an old one may not free the space you expect, and the chain matters more than the console suggests.

Snapshots against backups: fast, same-platform, and not a backup on their own

This is the most important distinction in the objective and it was introduced in objective 1.2. Stated properly here:

A snapshot is a point-in-time copy of a volume, usually stored by the same provider, usually in the same region, and usually tied to the lifecycle of what it came from.

It is excellent at what it does:

• Taken in seconds, with little performance impact
• Restored quickly
• Ideal immediately before a risky change
• Cheap, because only changed blocks are stored

And it fails as a backup in specific ways:

• Same account. An account compromise, or a mistaken bulk deletion, can remove the snapshots along with the data. Ransomware operators target snapshots first for exactly this reason.
• Same region, usually. A regional failure takes both.
• Same provider, always. A billing dispute or account suspension takes everything.
• Lifecycle-coupled. Deleting the source resource may delete its automated snapshots — a dangerous default noted in objective 1.6.
• Usually crash-consistent, not application-consistent — see below.

So a snapshot protects against change; a backup protects against loss. A proper backup strategy uses snapshots for fast recovery and keeps copies in a separate account or subscription, ideally in another region, with restricted delete permissions and — where available — immutability or an object lock so that even an administrator cannot delete them before their retention expires. That last control is the specific answer to ransomware, and it is examinable.

Application-consistent versus crash-consistent, and the database that needs the former

A snapshot taken while a system is running captures whatever was on disk at that instant. What was in memory, or half-written, was not captured.

• Crash-consistent. Equivalent to pulling the power. Journaling filesystems usually recover; databases usually recover; sometimes they do not, and you find out at restore time.
• Application-consistent. The application is told to quiesce — flush buffers to disk, pause writes briefly, hold transactions — the snapshot is taken, and it resumes. The restored copy is guaranteed usable.

The mechanism is the platform's backup agent or a provider service invoking the application's own quiescing interface, which on Windows is the Volume Shadow Copy Service and on Linux is typically pre-freeze and post-thaw hooks or the database's own mechanism.

The rule to carry: transactional systems need application-consistent backups. For databases, the better answer is usually the database's own backup mechanism — a native dump or the managed service's automated backup with point-in-time recovery — rather than a volume snapshot, because it understands transactions and can restore to a moment rather than to a file state.

A scenario describing a database restored from a volume snapshot that comes up corrupted, or requiring a lengthy recovery, is describing the crash-consistent trap.

Retention schedules, grandfather-father-son, and the legal hold that overrides them

Retention answers "how far back can we go", and it is a business decision informed by regulation, not a technical preference.

Grandfather-father-son is the classical rotation and still the clearest way to express a schedule:

• Son — daily backups, kept for a week or two
• Father — weekly backups, kept for a month or two
• Grandfather — monthly backups, kept for a year or several

The point is tiering: high granularity recently, coarser further back, so storage stays bounded while the window stays long. Cloud lifecycle rules (objective 1.7) implement this directly, moving older backups into cheaper tiers as they age — with the caution that an archive tier's retrieval time becomes part of your recovery time.

Two things that override the schedule:

• Regulatory retention, which sets a minimum that the schedule must meet.
• A legal hold, which suspends deletion entirely for the data in scope, regardless of age or policy. Holds must be implementable — which means being able to find and preserve the relevant backups — and release must be deliberate.

The threat that shapes modern retention is ransomware, and it changes the question from "how far back might we want to go" to "how far back might we need to go". Encryption that happened weeks before it was noticed makes a 14-day window worthless. This is the argument for the grandfather tier and for immutable copies, and it is why the exam treats retention as a resilience control rather than an archiving convenience.

The 3-2-1 rule read honestly in a cloud where two copies live at one provider

3-2-1 says: three copies of the data, on two different media types, with one off-site.

Translated honestly into cloud terms, where "media type" is an awkward fit:

• Three copies — the production data plus at least two backups. Replication is not one of these, because replication copies corruption and deletion faithfully and instantly. Replication is availability; backup is recovery, and confusing them is a classic error.
• Two different media or platforms — in practice, different storage services or a different provider. A snapshot and an object-storage backup are more separate than two snapshots.
• One off-site — for a cloud, off-site means a different failure domain: another region at minimum, and ideally a different account, because the account is the boundary that ransomware and mistakes cross most easily.

Many people now extend it to 3-2-1-1-0: one copy immutable or offline, and zero errors on restore verification. Both additions exist because of the two failures this lesson keeps returning to — backups deleted along with the data, and backups that have never been proven to restore.

The practical shape of a sound cloud backup design:

1. Snapshots in-account for fast rollback.
2. Backups copied to a separate, locked-down account, with delete permissions that operational identities do not hold.
3. At least one copy in another region.
4. Immutability applied for the retention period where supported.
5. Restores tested on a schedule — the next lesson.

What to take into the exam

• Full = fastest restore. Incremental = smallest backup, slowest and most fragile restore. Differential = full plus one.
• Cloud snapshots are incremental in storage, full in behaviour — but chained, so deletions do not free what you expect.
• A snapshot is not a backup: same account, same region, same provider, lifecycle-coupled, and usually crash-consistent.
• Transactional systems need application-consistent backups, and a database's own backup mechanism beats a volume snapshot.
• GFS tiers granularity against storage. A legal hold overrides retention entirely.
• Replication is not backup — it copies corruption faithfully.
• 3-2-1, with off-site meaning a different failure domain, plus immutability and tested restores as the modern additions.