Chapter 3 — Backup Methods and Restore Dependencies

3.1 Different Backup Methods Change What Restore Needs

In Chapter 1, we confirmed that Backup existing does not, by itself, mean you can Recover when you need to.

This chapter takes that idea one step further. There are several representative methods for how a Backup is taken, and depending on the method, what is needed at Restore time also changes.

Here we look mainly at these three representative ideas:

• Full Backup
• Incremental Backup
• Differential Backup

In this chapter, we treat Full Backup, Incremental Backup, and Differential Backup as representative Backup methods. However, the model presented here is a representative organization of ideas; not every product or implementation necessarily works in exactly the same way.

This chapter organizes each method not only by "what it captures," but also from the perspective of "what it requires at Restore time."

3.2 Full Backup

Full Backup is the idea of capturing everything needed at that point in time, all together.

When performing a Restore, in a representative configuration, that Full Backup itself is used as the starting point for the Restore.

Viewed from the perspective of Restore dependency, Full Backup is relatively simple as a representative model. That is because, in a representative configuration, the elements needed for a Restore are essentially self-contained within that Full Backup itself.

However, this does not mean "a Full Backup is always safe" or "a Full Backup is the only right answer."

Depending on the scale of the target, a Full Backup can also carry a certain cost to capture and store. And if the Full Backup itself is corrupted or unavailable, the Restore still cannot succeed.

"Being a representative configuration that requires fewer elements at Restore time" and "being the best choice in every situation" are different matters. We revisit this point in 3.8.

3.3 Incremental Backup

Incremental Backup is the idea of capturing only the changes that have occurred since the previous Backup (a Full Backup, or the previous Incremental Backup).

What matters here is what happens at Restore time.

When trying to restore to a given point in time, a representative configuration requires both the base Full Backup and the subsequent series of Incremental Backups needed to reach that point (the Incremental chain).

For example, suppose three Incremental Backups were taken after a Full Backup, and you want to restore to the point in time of the third one. In a representative configuration, you need the Full Backup and all three of the first, second, and third Incremental Backups.

In other words, "what is saved at capture time" and "what is depended on at Restore time" need to be thought about separately. With Incremental Backup, in a representative configuration, Restore depends on multiple backup sets.

3.4 Differential Backup

Differential Backup is the idea of capturing, each time, all of the changes that have occurred since the base Full Backup.

The difference from Incremental Backup is that, instead of "the changes since the previous Backup," it captures "the changes since the base Full Backup," in full, every time.

In a representative configuration, Restore requires the base Full Backup and the one Differential Backup corresponding to the target point in time.

In a representative configuration, there is no need to chain together multiple Backups in sequence, unlike with Incremental Backup.

Here too, the detailed implementation and behavior can differ by product or configuration. This chapter treats this as a representative way of understanding Restore dependency.

3.5 Comparing Restore Dependencies

Let's organize what we've covered so far into a simple table.

This table is only a representative guide for organizing ideas. How well it applies varies depending on the actual configuration or product.

What matters is thinking about each method not only in terms of "what it captures," but also, separately, "what it requires at Restore time."

3.6 When a Chain Becomes Unusable Partway Through

As we saw in 3.3, when using Incremental Backup, Restore involves, in a representative configuration, a dependency on the Full Backup and the subsequent series of Incremental Backups.

What we want to consider here is the case where part of this series of Backups (the chain) is missing or unavailable.

Let's think about this using the following simplified diagram, intended purely for understanding.

Teaching Diagram (a simplified conceptual diagram, not a specification of any particular product)

Normal case:
[Full] → [Incremental 1] → [Incremental 2] → [Incremental 3]

When Incremental 2 is unavailable:
[Full] -> [Incremental 1] -> [Incremental 2] -> [Incremental 3]
                                  X

Up to [Full + Incremental 1]: OK
The point in time that needs [Incremental 2]: affected

When Incremental 2 is unavailable, in a representative configuration, a Restore to a point in time that needs to go through Incremental 2 (in this example, the points corresponding to Incremental 2 or Incremental 3) may not be able to proceed as expected.

The point to hold onto here is this:

When part of the dependency chain needed for a Restore is missing, the Restore that depends on it may not be able to proceed as expected.

However, this does not mean "if even one element is missing, every Restore necessarily becomes impossible." The extent of the impact can vary depending on which point in time the missing element relates to, which method is used, and what the implementation is like. For example, if the Full Backup itself and Incremental 1 are intact, a Restore up to the point in time corresponding to Incremental 1 may not be affected.

With Differential Backup, in a representative configuration, the elements depended on are limited to the Full Backup and one Differential Backup, so it is said to be less prone to the kind of dependency chain with many linked elements seen with Incremental Backup. That said, if the Full Backup or Differential Backup itself is unavailable, the Restore naturally cannot succeed.

What can be said in common across every method is this: whether you can Restore to the point in time you need is determined not simply by "whether backup files remain," but by "whether the dependencies that the method requires actually hold."

3.7 Recovery Window and Restore Dependency

In Chapter 1, we saw that Retention needs to be thought about not merely as "how many generations are kept," but through the idea of Recovery Window — how far back in the past you need to be able to go.

From this chapter's perspective, actually making a Recovery Window work requires also confirming Restore dependency.

To Restore to a given point in time, it is not enough for a backup close to that point in time to merely remain. The full set of backups the method requires for the Restore (the Full Backup, any needed Incrementals, the corresponding Differential, and so on) must actually all be retained and in a usable state.

In other words, when designing a Recovery Window, you need to consider not only "does a backup for that point in time remain," but also "is the whole set of dependencies needed to Restore to that point in time retained."

As one example, Oracle Database's official documentation documents two retention policy approaches for RMAN (Recovery Manager) — one based on redundancy (a number to keep) and one based on Recovery Window — and shows that you can configure either one. This is a design example for a specific product, not a universal rule common to every Backup product, but it is one example showing that "how many generations to keep" and "how far a period, together with all the necessary dependencies, you can go back" can be separate perspectives.

3.8 There Is No Simple Ranking Among Methods

So far, we have looked at the representative differences in Restore dependency for each of Full, Incremental, and Differential.

What we want to note here is that there is no simple "best method" among Full, Incremental, and Differential that holds in every situation.

For example, the following elements differ by method:

• the complexity of the dependencies needed at Restore time
• how frequently Backups are taken in operation
• how long Retention needs to be kept for
• the specifications of the actual product or implementation in use

The importance of these varies depending on the requirements of the system and its operation. Therefore, this chapter does not make a uniform ranking such as "Differential is always better" or "Full is always the safest."

The position of this chapter is that choosing a method requires weighing these multiple perspectives. The concrete method of selection itself is beyond the scope of this chapter.

3.9 Summary

This chapter organized how the dependencies needed at Restore time differ depending on the method used to capture a Backup.

The important points are these:

• In a representative configuration, Full Backup requires relatively simple elements for Restore, but that alone does not mean it is always the best choice.
• In a representative configuration, Incremental Backup creates a dependency on the base Full Backup and the subsequent Incremental chain.
• In a representative configuration, Differential Backup creates a dependency on the base Full Backup and the one corresponding Differential.
• When part of the dependency is missing or unavailable, the Restore that depends on it may not be able to proceed as expected.
• "Multiple backups remaining" and "the necessary Restore chain actually holding" are not the same thing.
• When thinking about a Recovery Window, you need to consider not only whether a backup for the target point in time remains, but also whether the full set of dependencies needed to Restore to that point in time is retained.
• There is no simple ranking among methods; the choice needs to weigh multiple perspectives.

We take up, in a later chapter on Recovery Test / Exercise, how to actually confirm whether a Restore will reliably succeed.

In the next chapter, Chapter 4, before getting into technical Backup design, we look at BIA (Business Impact Analysis) — approaching the question of what needs to be protected in the first place from the perspective of business impact.

Questions to Consider After Reading Chapter 3

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

• Can you explain the difference between Full, Incremental, and Differential?
• Can you explain why, when restoring an Incremental, multiple backup sets can be involved?
• Can you explain the difference in Restore dependency between Differential and Incremental?
• Can you explain why a Restore may not be possible even when multiple backup files remain?
• Can you explain why a method cannot be chosen by a simple ranking alone?

You do not need to be able to answer all of them.

Rather, if there is a point where you get stuck, that is exactly the point this chapter is meant to help you check.