Chapter 2 — Backup and the Boundaries of Related Technologies

2.1 Why Similar Technologies Must Be Distinguished

In Chapter 1, we established that not just "whether you have a backup," but "whether you can restore when you need to" is what matters. This way of thinking applies just as directly to technologies other than Backup.

In practice, explanations such as:

• "we're replicating it"
• "we've made it redundant"
• "we're taking snapshots"
• "we're also storing it in another location"

are sometimes treated as "basically the same as backup." However, each of these technologies was built for a different purpose. A similar name and identical protection are two separate matters.

This chapter sorts out, one by one, from the perspective of how each differs from Backup:

• Replication
• Snapshot
• Archive
• Redundancy

We do not yet cover the concrete design details of each technology. The goal for now is to become able to distinguish what each one protects, and what it does not.

2.2 Replication — What It Protects, and What It Doesn't

Replication is a mechanism that copies a system's data or state to another location as well. It may be used to increase availability and resilience. One representative use is to allow the service to continue from the other side even when one becomes unavailable.

What needs attention here is what Replication is actually copying. Replication is a mechanism that also reflects, at the replication destination, changes made to the original data.

For that reason, if the original data is accidentally deleted or becomes corrupted, that change may also be reflected at the replication destination. Depending on the configuration, the change can reach the replication destination almost immediately, so it is possible that "the state before the deletion" does not remain at the destination either.

This is not a flaw in the Replication mechanism itself. That is because Replication is, by design, a technology aimed at "always keeping the latest state available in another location as well."

Therefore, Replication and Backup are not the same thing. Replication helps maintain availability, but that alone does not guarantee "being able to return to a past point-in-time state."

2.3 Snapshot — What It Preserves, and What It Doesn't Guarantee

Snapshot is a mechanism that records the state of a system or data at a given point in time. It is used with the idea that "if we take this, we can later check or restore the state from this point in time." So far, this looks similar to the idea of Backup.

However, the mere fact that something is called a Snapshot does not by itself establish that an independent Backup copy exists.

Some Snapshot configurations depend on the same underlying storage as the original data. In that case, if the underlying storage itself fails, the Snapshot may be affected together with the original data. Having a Snapshot and having an independent Backup copy are not the same thing.

This does not, of course, mean that Snapshot is not useful. Being able to quickly record a point-in-time state is useful in many situations.

However, whether it is protected in a location independent of the original system cannot be known from the name Snapshot alone. You need to check exactly where, and how, the mechanism actually stores it.

2.4 Organizing the Differences from Backup

Let's line up what we've covered so far against the idea of Backup we established in Chapter 1. In Chapter 1, we established that Backup is holding data or state for use in recovery.

Replication is a mechanism for maintaining availability, and it has the property of passing changes straight through. Snapshot is a mechanism that records a point-in-time state, but whether it constitutes independent protection cannot be known from the name alone. Both are effective technologies for their respective purposes.

However, viewed from the perspective of "whether you can return to the state you need when you need to," Replication or Snapshot alone may not be enough.

What matters is knowing what each technology exists for, and what it does not guarantee.

2.5 The Difference from Archive

Archive is a concept with a purpose that differs still further from Backup. Whereas Backup's purpose is "returning to the original state when needed," Archive's main purpose is retaining something for a long period so that it can be referenced and used when needed in the future.

There is one common misunderstanding here. It is calling "data that has been stored for a long time" an Archive without further thought.

However, just because something has been stored for a long time does not automatically make it an Archive. How it should be treated depends on whether the purpose of storing it is "for recovery" or "for future reference or record-keeping."

Backup and Archive can use the same storage technology or the same form of copy. For that reason, it can be hard to tell them apart by appearance alone. But if the purpose and the way it is managed differ, it needs to be treated as a different thing.

Also, the mere fact that a particular product has something named an "archive mode" or "archive storage" does not make that the general definition of Archive itself. A product-specific feature name and the concept of Archive itself need to be considered separately.

The relationship between Archive and long-term retention required by law or regulation is not covered in this chapter. It is taken up again in a later chapter.

2.6 Redundancy / Independent Copy

Redundancy is the idea of preparing multiple components that serve the same role, so that the service does not stop even if one of them becomes unavailable. Disk duplication and multi-server configurations are examples of this. Redundancy helps make the service harder to stop.

However, there is a point to note here as well. Having multiple copies of the current state, and being able to return to an earlier normal state, are not the same thing. If a problem state that occurs on one side of a redundant configuration is reflected as-is on the other side, it is possible that "the state before it broke" remains nowhere at all.

The technologies we have looked at so far each play a different role. However, none of them can be judged, from the name alone, as to whether they can achieve the Recovery required of an independent Backup copy.

Finally, let's also touch on the idea of an "independent copy." This is not a term that refers to a specific product name or a fixed technical method. It is a general way of thinking about a copy with enough independence that it is unlikely to be affected by a failure or an unintended change at the same time as the original data. It cannot simply be decided that a technology "is an independent copy if it satisfies this condition"; it depends on where, and how, it is actually stored.

2.7 Comparison Table — Backup / Replication / Snapshot / Archive / Redundancy

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

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

Note that, within Backup as well, there are differences by method, such as Full, Incremental, and Differential, and each requires different information at Restore time. This point is covered in the next chapter.

2.8 Summary — What to Examine to Distinguish Technologies

This chapter sorted out the technologies that resemble Backup. The important points are these:

• Replication and Backup are not the same thing. It is used to support availability, and depending on the configuration, changes and deletions are also reflected at the replication destination.
• The name Snapshot alone does not establish that an independent Backup copy exists.
• Archive has a different purpose from Backup, and simply having been stored for a long time does not automatically make something an Archive.
• Redundancy is a mechanism for holding multiple copies of the current state, and it does not guarantee that you can return to a past normal state.

Rather than judging which technology is in use by name alone, it is important to check what it protects, and what it does not.

In the next chapter, Chapter 3, we look at, within Backup, the differences among methods such as Full, Incremental, and Differential, and the dependencies that come up when performing a Restore.

Questions to Consider After Reading Chapter 2

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

• Can you explain, in your own words, the difference between Replication and Backup?
• Can you explain why having a Snapshot alone does not mean you have an independent Backup copy?
• Can you explain the difference in purpose between Archive and Backup?
• Can you distinguish between Redundancy and being able to return to a past state?
• Can you explain what you should check — rather than the name — to distinguish these technologies?

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.