CompTIA Cloud+ (CV0-004) Training Course

Backup is the operations topic with the sharpest consequences: a design flaw is invisible until the day it matters, and by then it is not fixable. CV0-004 tests both the mechanics and the judgment.

The three backup types

• A full backup copies everything. Backup takes the longest and consumes the most storage; restore is fastest and simplest because you need exactly one backup set.
• An incremental backup copies everything changed since the previous backup of any type. Backups are fastest and smallest. Restore is slowest, because you need the last full plus every incremental since, in order — and if any one of them is corrupt or missing, the chain breaks at that point.
• A differential backup copies everything changed since the last full backup. Each successive differential grows larger as the week progresses. Restore needs only the last full plus the most recent differential — two sets, so it is faster and more robust than incremental.

The distinction hinges on the archive bit or its modern equivalent: incremental backups clear it, differentials do not. That single behavioral difference is the reason the chains differ, and it is a favorite exam question. The trade-off summary worth memorizing: incremental optimizes the backup window, differential optimizes the restore, and full optimizes simplicity.

Two related variants: synthetic full backups construct a new full from an existing full plus incrementals on the backup system, giving the restore simplicity of a full without re-reading the source. Forever incremental takes one full and then only incrementals indefinitely, with the backup platform maintaining a synthesized recovery point.

Snapshots are not backups

A snapshot captures a volume's state at a point in time, typically using copy-on-write or redirect-on-write so it is nearly instant and initially consumes almost no space. Snapshots are excellent for a fast rollback before a risky change and as the source for cloning environments.

They are not backups, for three reasons the exam expects you to give:

• They frequently depend on the original volume or storage system, so losing it can lose them.
• They usually live in the same account and often the same region, so an account compromise or a regional event takes both.
• They can be deleted by the same credentials that manage the source, which is precisely what ransomware and a malicious insider will use.

Snapshots also accumulate cost and, on some platforms, degrade performance in long chains. Automate their expiry.

Application consistency

A crash-consistent backup captures the disk as it was, as though the power was pulled — usable for many systems, but a database may need recovery on start and may lose in-flight transactions. A file-system-consistent backup flushes the OS cache first. An application-consistent backup goes further, quiescing the application so buffers are flushed and the on-disk state is coherent, typically via a writer framework on Windows or pre- and post-scripts on Linux. Databases and transactional applications require application consistency; static file servers usually do not. Choosing crash-consistent for a database is a design error that only reveals itself during a restore.

The 3-2-1 rule and its modern extension

Keep three copies of the data, on two different media or storage types, with one copy off-site. In cloud terms, off-site usually means a different region and, for the strongest protection, a different account or provider. Many organizations now extend it to 3-2-1-1-0: one copy immutable or offline, and zero errors on verification.

The immutability point deserves emphasis. Ransomware operators specifically target backups, and an attacker with administrative credentials will delete every recovery point they can reach. Defend with object lock or write-once-read-many retention that even an administrator cannot shorten, backup copies in a separate account with separate credentials, and multi-person approval for deletion of retention policies.

Replication is not backup either

Replication protects against the loss of a system. It does not protect against a mistake, because it copies the deletion or the corruption to the replica at the speed of the link. Every environment needs both: replication for availability, point-in-time backups for recoverability.

Backup scope in the cloud

Back up more than the obvious volumes: managed database automated backups plus a periodic export you control, object storage protected with versioning and lifecycle rules, configuration and infrastructure code, secrets and key material, identity configuration, and the documentation and runbooks themselves. Under the shared responsibility model, providers protect the platform's durability, not your data's recoverability from your own mistakes — that boundary is examinable and frequently misunderstood.

Verification and restore testing

An unverified backup is a hypothesis. Verify at three levels: the job completed without errors, the backup's integrity checks pass, and — the one that counts — a real restore into an isolated environment produces a working system. Test on a schedule, test the systems you actually care about, and record the measured restore duration so you can compare it with the RTO you promised. Restores routinely take several times longer than expected because of retrieval from archive tiers, rehydration delays, and network transfer.

What to take into the exam

Given a backup window and a restore requirement, choose the type: incremental when the nightly window is tight, differential when restore speed matters more, full when simplicity wins. Be ready to state why a snapshot is not a backup, why replication does not protect against deletion, what application consistency requires, and what 3-2-1 means with the immutability extension.