Data Backup and Restoration

Data backup and restoration. This is the most common, and most preventable, resilience failure there is, and the whole lesson turns on a single word: restoration.

The scene. The backups had been running green every night for two years. The reports said success, every time. Then a server was lost and the team went to restore, and found the backups were of the wrong volume, missing the database that mattered, and the last usable copy was months old. Two years of successful backup jobs, and nothing to recover. Nobody had ever tried to restore one.

Here is the core point. A backup job completing successfully tells you one thing: it ran. It does not tell you the data is complete, that it is uncorrupted, that it captured the right systems, or that it can actually rebuild a working environment.

Those are only proven by doing the thing you are keeping the backup for: a test restoration. This is the central point of the lesson, and a favourite of the exam. Restoration testing is the control that proves recoverability. Backups that have never been restored fail with dispiriting regularity, wrong scope, silent corruption, missing dependencies, expired media, and the failure is discovered at the worst possible moment.

So the question an auditor asks is never do the backups run. It is: when did you last successfully restore one? A green backup report is a hope. A successful test restore is evidence. That difference is the lesson.

Second point: where you keep them. A backup exists to survive whatever destroys the original, so storing it next to the system it protects defeats the purpose. A fire, flood, power event or site loss takes out both the system and its only backup at once. Backups are therefore stored offsite, or in a geographically separate location, far enough that a disaster at the primary site cannot reach them. Convenience of access argues the other way, and convenience is not the goal; survivability is.

It is the same principle as keeping the old system as a fallback in Domain three: the safety net must not share the fate of the thing it is protecting. A backup that dies with the system it protects is no backup at all.

Now the three backup types, which trade backup size against restore effort. A full backup copies everything: simplest to restore, one copy, but the largest and slowest to take.

An incremental backup copies only what changed since the last backup of any kind. Smallest and fastest each day, but a restore needs the last full plus every incremental since, in order.

And a differential backup copies everything changed since the last full backup. It grows each day, but a restore needs only the last full plus the latest differential. The exam tests it directly: incremental is since the last backup, differential is since the last full.

And how often do you back up. Frequency comes from the R-P-O in the previous lesson: the less data you can afford to lose, the more often you back up. An R-P-O of a day means nightly; an R-P-O of an hour means hourly or continuous.

So carry this away. A successful backup report proves the job ran, nothing more; only a test restoration proves you can actually recover, which is why untested backups are treated as unproven. And backups are stored offsite, where the disaster that destroys the system cannot also destroy them.