Chapter 1 — What Backup Is For

1.1 Why Take a Backup

Backup is a mechanism for holding data or a system's state in a separate form so that it can be used when needed.

However, creating a Backup is not, by itself, the ultimate goal.

In practice, you often hear explanations such as:

• "the backup process is succeeding"
• "the backup file exists"
• "we keep 30 days' worth"
• "we also copy it to another storage location"

These are all important.

But by themselves, they do not mean

"we can recover when we need to."

For example, even if a backup file exists, if it has never actually been Restored, you cannot know whether it can really be used. If the recovery procedure exists only in the responsible person's head, recovery may not be possible while that person is unavailable. Even if the data can be Restored, if other elements needed for operation — application settings, credentials, and so on — have been lost, the system may not come back to a state users can actually use.

In other words,

"a Backup existing" and "being able to Recover" are separate problems.

In this book, we treat Backup as a means of enabling Recovery.

Backup is meant to be used by being Restored, so Backup and Restore should not be thought of separately.

Designing Backup alone, without thinking about Restore, can be thought of as something close to "building an emergency exit but never checking whether the door actually opens."

That said, one more point needs attention here. Just because a Restore succeeded does not necessarily mean Recovery is complete. We look at this difference in detail in the next section.

The Idea of Backup Is Not Unique to This Book

Everything explained so far is not simply "the author's own private definition of Backup." NIST (the National Institute of Standards and Technology) publishes many technical documents on the security and operation of information systems. One of them, NIST SP 800-34 Rev. 1, which addresses contingency planning for information systems, also treats Backup as one of the activities that supports Recovery.

What matters here is not the name NIST or the document number, but the idea itself. Standards and guidelines are used as grounds for confirming that idea and for reviewing your design.

1.2 Backup, Restore, and Recovery Are Not the Same

Backup, Restore, Recovery. In practice, these three words are sometimes used loosely, without a clear distinction. But when you are designing, it becomes easier to understand if you consider them separately.

Backup is holding data or state for use in recovery.

Restore is the operation of using that Backup (or similar) to bring data or state back.

Recovery is actually bringing the necessary data or functionality to a state you can use.

Put simply, it looks like this:

Backup
  ↓
Choose which recovery point to use
  ↓
Restore
  ↓
Check the restored data/system
  ↓
Bring it to a usable state
  ↓
Recovery

This diagram is a simplification created for this book, to make the difference between Backup, Restore, and Recovery easier to understand.

What matters is that Restore success = Recovery success is not true.

Restore Succeeded. But Recovery Was Not Finished.

For example, suppose a database failure occurred in some business system. The backup files remained. The person in charge followed the procedure and performed a Restore, and the database itself returned to normal. Up to this point, Restore succeeded.

However, what had been restored at this point was the database; this did not mean that the business system as a whole had been restored to a usable state.

But then, when they tried to start the application, it did not run. Investigation revealed remaining problems such as:

• required configuration was missing
• certificates were unavailable
• the credentials the service used were unknown

The database has come back. But users cannot use the business system. In this case, Restore has succeeded. But Recovery is not yet complete.

When people are new, they tend to think:

The data came back
= it has been recovered

But a real system does not run on data alone. The application, configuration, authentication, network, name resolution, keys and certificates, and various other elements all work together to make it run. Chapter 1 does not cover all of these in detail. For now, it is enough to understand that restoring and recovering are not the same thing.

1.3 What to Protect, and What to Prepare For

The statement "we have backups, so we're fine" is a somewhat dangerous one in practice. That is because what you are trying to protect changes what preparation is needed. And on top of that, the reasons something might be lost also change what preparation is needed.

The first thing to consider is what you need to protect.

For example, there are many possible targets to protect, such as:

• files
• databases
• system configuration
• virtual machines
• business systems

However, later in this book we will consider an even broader view. At this stage, rather than assuming "it's enough to protect just the data," what matters is holding onto the question: what does this system need in order to recover?

The next thing to consider is what you are preparing for.

Even when protecting the same file, the necessary preparation is not always the same for:

• storage failing
• a user accidentally deleting it
• data gradually becoming corrupted
• it undergoing a malicious change
• the site itself becoming unavailable

For example, the problem of "a disk failed" and the problem of "a user deleted an important file three days ago" call for restoring to different states. Furthermore, if "data had been gradually corrupting since ten days ago," then simply restoring the most recent data will not solve the problem. Therefore, what to protect × what to prepare for together determine how you need to think about protection.

In this book, we organize this kind of question — "in what form might it be lost?" — as a Loss Scenario where needed. You do not need to memorize this term right away.

For now, just hold onto these two questions:

What are you protecting?
What would be a problem if it happened?

Questions to Ask First

This table is not a lookup table saying "for this kind of failure, always use this product." Chapter 1 does not go as far as explaining concrete Recovery methods for specific failures. We cover concrete methods in later chapters.

1.4 "How Many Generations to Keep" Is Not Enough

When discussing backup design, the question "how many generations are you keeping?" comes up often.

For example, answers like:

• 7 generations
• 14 generations
• 30 generations

Of course, the number of generations matters. However, how many generations you keep, by itself, does not tell you whether you can get back to the state you need.

For example, suppose you take a backup once a day and keep 7 generations. Naively, that would let you retain roughly a week's worth of state.

But suppose data corruption is discovered today. On investigation, the corruption turns out to have started 10 days ago. In that case, all of the most recent 7 generations may already contain the corrupted state.

In other words, having 7 backups and being able to get back to the required normal state are not the same thing.

What becomes important here is the idea of how far back into the past you can actually go.

In this book, we sometimes use the term Recovery Window when thinking about this kind of recoverable time range. That said, what matters more than memorizing the term is the underlying idea.

Past                                           Present

Normal ───── Problem occurs ───── Backups continue ───── Discovered
 ↑
State you want to restore to

What matters in this diagram is that the time the problem occurred and the time the problem was discovered are different.

A failure does not necessarily begin at the moment it is discovered. For example, situations like the following can occur:

• data had been gradually corrupting
• an incorrect configuration had been introduced several days earlier
• no one had noticed that a user had deleted something
• a compromised state went undetected for a while

For that reason, when thinking about Retention, you need to consider separately:

• how many copies to keep
• how far back in time you can go
• how much time it might take before the problem is even noticed

Is 30 Generations Enough?

At this point, you might think, "then wouldn't 30 generations be safe?" But it is not that simple.

Depending on the system, the following differ:

• how much the data changes
• how often backups are taken
• how long it takes to discover a failure
• the point in time you would need to restore to

30 generations of once-a-day backups, and 30 generations of once-an-hour backups, give you completely different amounts of recoverable time range.

Likewise, the necessary approach to retention differs between a system where a failure is discovered quickly and one where a problem is only understood weeks later.

Therefore, "the correct number of generations" is not a figure that can be fixed uniformly. What matters is the question of how far back in the past you need to be able to reach the required state, and how much time it might take to discover the problem. This chapter does not treat any single figure as a fixed rule common to every system.

1.5 Restoring the Newest Backup Is Not Always the Right Choice

When multiple backups remain, it is natural to think "we should just restore the newest one."

Indeed, for a straightforward hardware failure, restoring to the most recent state is often exactly what you want.

However, the newest backup is not always the most suitable recovery point.

For example, suppose a user deleted important data. If a backup was made after that deletion, the newest backup already has the deleted state saved in it.

The same applies to logical corruption.

If the corrupted state was what got backed up, then Restoring the newest backup brings back the corrupted state. Similar problems can also occur with malicious changes or a compromise. For that reason, you need to think about not only which backup is newest, but also which point in time actually held the state you need. NIST's published technical guidance on recovering from cyberattacks also addresses the need to select the correct backup version, or a known-good state.

So Which Point in Time Can You Trust?

Reading this far, a natural question arises: "then how do you judge which backup is actually clean?" Particularly with cyberattacks or corruption that went unnoticed for a long time, it can happen that you do not even know when the state stopped being trustworthy. This problem is not resolved by Chapter 1 alone. The question of which Recovery Point to trust, and how to judge which state is normal, is taken up again in a later chapter. For now, just remember this: do not assume something is correct simply because it is the newest.

1.6 Backup Success and Recovery Success Are Different

Suppose a backup product's screen shows:

Backup completed successfully

This is important information. If backup processing were failing, you would of course need to investigate the cause. However, a "Success" message being shown and being able to Recover are not the same thing. What that message mainly confirms is that the backup process completed under its defined conditions.

On the other hand, things such as:

• whether you can actually retrieve the necessary data
• whether you can restore to the point in time you need
• whether the system is usable after recovery
• whether the surrounding elements needed for recovery are all in place

cannot be determined from the backup process's success message alone. These are matters that need to be confirmed separately from backup-process success.

For example, suppose a backup job succeeded every day for 30 days. Even so, if it has never once been Restored, you have confirmed that "backup processing succeeded for 30 days," but you have not confirmed that "you can actually restore from that backup."

"It Was Taken" and "It Can Be Restored" Are Different Things to Confirm

In backup operations, you need to think separately about confirming that it was taken and confirming that it can be restored. To check "was it taken," you would look at the backup job's result, the state of the storage destination, and so on. But to confirm "can it be restored," you need to actually think through Restore and Recovery. Therefore, in backup design, you consider not only "was it taken," but also "have we confirmed that it can be restored?"

Specifically, matters such as:

• how far to test
• what counts as success
• how often to check

— Recovery Tests and Exercises — are covered in detail later, in Chapters 15–16.

For Chapter 1, it is enough to understand that Backup Success ≠ Recovery Success. This is an important idea that comes back again and again as you read this book.

1.7 What This Book Will Cover From Here

So far, we have laid out the basics for thinking about Backup. The important points are these six:

1. Backup, Restore, and Recovery are not the same.
2. Backup is treated as a means of enabling Recovery.
3. What protection is needed changes depending on what you are protecting and what you are preparing for.
4. Retention should not be considered as simply a number of generations.
5. The newest Backup is not necessarily the best Recovery Point.
6. A successful Backup process does not by itself prove Recovery success.

In the next chapter, Chapter 2, we start by sorting out the easily confused Backup / Replication / Snapshot / Archive.

This book's focus is not on how to operate any specific backup product. Starting from Backup, we move on to Restore, then to Recovery.

In this book, we treat Backup mainly as a copy of data or system state used for Restore and Recovery. Broader recovery resources — replacement equipment, alternate facilities, alternate sites, and the like — can also matter in actual Recovery, but planning for the whole of those is not the main subject of this book. Being out of scope does not mean they are unimportant.

Within Recovery, we further consider recovery when systems or data have lost trustworthiness due to a cyberattack, and recovery aimed at resuming the business operations an organization needs. We also cover Archive and Retention as separate purposes and requirements from Recovery.

Roughly, the scope this book covers looks like this:

Backup
   ↓
Restore
   ↓
Recovery

Within Recovery, further considerations
├─ Cyber Recovery
└─ Business Recovery

As separate purposes/requirements
├─ Archive
└─ Retention

This diagram does not show a single formal, linear procedure. It is a map meant to make this book's scope easier to grasp at the outset.

The Purpose of This Book

The purpose of this book is not to decide "which backup product should you use."

Nor is it to give you a single number for "how many generations is safe."

Nor is it a product manual saying "operate this product this way and you can recover."

What this book works through are questions such as:

What do you need to protect?

What would cause you to lose it?

What state do you need to restore to?

What do you need to retain in order to do that?

How do you protect the things Recovery itself depends on?

And how do you confirm that you can really restore?

The goal is not simply to create "a state where backups exist."

The goal is to design so that, when an assumed loss occurs, you can get back to the state you need.

Backup is one of the important means needed for that. But thinking about Backup alone does not complete a Recovery design.

Recovery involves not only Backup data, but also the configuration and procedures needed for recovery, and the personnel who can carry out the recovery work.

In the chapters that follow, going one step beyond the technique of taking backups, we will work through, in order, what an organization needs to think about, design, and confirm in order to get back to the state it needs. Chapter 1 is the first foundation for that.

Questions to Consider After Reading Chapter 1

Thinking about the systems you are responsible for, can you answer the following questions?

• What are you backing up?
• What is that Backup meant to protect?
• What situation is it meant to be used for?
• How far back in time can you go?
• Can you judge which Recovery Point to choose?
• Have you actually performed a Restore?
• Have you confirmed, after a Restore, that the system is actually usable?
• If the Backup becomes unavailable, do you have another means of Recovery?

You do not need to be able to answer all of them. Rather, noticing that "we are taking backups, but I cannot answer this question" is itself one of the purposes of Chapter 1. We will take that question apart, piece by piece, in the chapters ahead.