Chapter 8 — Off-site / Offline / Isolated / Immutable

8.1 A Label Alone Cannot Tell You Whether Something Is Safe

In Chapter 7, we saw that holding multiple copies in multiple locations is useful but can sometimes not be enough on its own, and that separation of location and separation of administration are different problems.

This chapter makes that idea more concrete.

When talking about Backup or recovery copies, the following terms are often used:

• Off-site
• Offline
• Isolated
• Immutable

These are all important properties related to protection. However, carrying one of these labels does not necessarily mean the other properties are also satisfied. Satisfying a given property, and how safe something actually is, are two separate things that need to be confirmed independently.

This chapter looks, one at a time and concretely, at what each property does establish and what it does not.

8.2 Off-site — What Separation of Location Protects, and What It Doesn't

Off-site means that the copy, or the mechanism needed for recovery, is in a physical location different from production.

This helps avoid losing the copy at the same time when the production location itself is lost to a disaster or failure.

However, being Off-site does not automatically mean anything more than that. The location being separate does not, by itself, guarantee things such as:

• administrative authority being separate from production
• credentials being separate from production
• network paths being separate from production
• the management of cryptographic keys being separate from production

Copy A in the opening scenario is exactly this case. The location was separate, but the path through which it could be deleted was shared with production.

When you see an Off-site copy, ask yourself: "Besides the location being separate, what else is actually separated?"

8.3 Offline — The Question of Reachability

Offline means that the copy or mechanism is, under normal conditions, not connected or reachable over the network.

A constantly connected system can be affected by an attack or a mistaken operation through that connection path. Being Offline helps avoid that kind of impact through the normal path.

There is a point worth noting here. Within the range of evidence that could be confirmed for this book, no description was found that rigorously defines fine-grained distinctions such as "a state of complete physical disconnection" versus "a state where only the logical path is cut off," or "a state that is only temporarily disconnected." Therefore, this chapter does not equate Offline with a specific implementation approach such as a "physical air gap," and instead treats it, for now, as the general idea of "a state that is not reachable under normal conditions."

Also, being Offline does not prove things such as:

• that the copy is in its most current state
• that the copy has been verified
• that the copy is administratively protected

Beyond simply "it's fine because it's not normally connected," you also need to separately confirm "is this copy actually in a usable state?"

8.4 Isolated — Confirming What Is Actually Separated

Isolated means that some failure or control domain is separated from production.

What matters here is that you need to concretely confirm "what is actually separated." The word "isolated" by itself does not tell you which of the following is separated:

• network
• Identity (management of authentication principals or credentials)
• administrative authority
• the authorization path
• storage
• cryptographic keys
• location

For example, the network path may be separate from production, while still depending on the same administrator identity or the same key management. In that case, it would be separated from a network standpoint, but not separated from an administrative-authority or key standpoint.

For organizing this kind of perspective, this book can refer back to the multiple dimensions introduced in Chapter 7 (geographic, network, storage, Identity, administrative authority, authorization, cryptographic). This is only one example of how this book organizes ideas, and not a classification defined by an industry standard.

What matters is the habit of asking, whenever you see the word "Isolated," concretely which dimension it is separated on.

8.5 Immutable — Confirming What "Immutable" Actually Means

Compared with the three properties covered so far, Immutable is a property that needs particular care.

The label Immutable alone does not tell you how far it actually withstands change or deletion.

"Immutable = indestructible," "Immutable = protected forever," and "Immutable = protected from every administrator" are not correct understandings. Immutable is, at most, a property under which change or deletion is restricted "under certain conditions." Also, being Immutable does not mean being Offline or Isolated. There are cases where only Immutable protection is configured, while the system remains online.

When you see the label Immutable, you need to confirm at least the following six points:

1. Lock state / enforcement mode (the current state): what state is the protection currently in? Can the protection be weakened or removed from that state?
2. Override authority (who can override or remove it): who is able to disable or change the protection itself?
3. Irreversibility timing (when it becomes irreversible): does the protection become irreversible the moment it is set, or does it become irreversible only after a grace period or a state transition?
4. Retention-policy authority (who decides the retention period): beyond the retention period itself, it also matters who can set or change that period.
5. Protected scope (what is protected): which data or which resources are the protection's target?
6. Excluded backup types / resources (what is not covered): which backup types or resources fall outside the scope of protection?

An Azure Backup Example

For example, in Azure Backup, immutability has an "enabled" state and a "locked" state, and the two differ in whether they can be reversed. This is one implementation example illustrating the importance of checking the "current state" described above as point 1.

An AWS Backup Example

AWS Backup Vault Lock has distinct governance mode and compliance mode, and the conditions under which protection can be overridden or removed differ between them. Also, protection under compliance mode can depend on the state of a grace period. This is an implementation example relevant to checking items 2 and 3 above.

These are only bounded implementation examples for specific products. Not every Immutable Backup product necessarily has the same mechanism. Do not treat Azure's or AWS's terminology as if it were the definition of the property of being Immutable itself.

8.6 Soft Delete Alone May Not Be Enough

A mechanism that appears in a context close to Immutable is Soft Delete.

Soft Delete is a mechanism that keeps data recoverable for a fixed period even after a delete operation is performed.

However, having Soft Delete does not necessarily guarantee recoverability.

Consider this: even if the data remains recoverable for a fixed period after deletion, if no one notices the deletion, or notices it but the notification does not reach anyone, or the notification arrives but the response does not happen in time, recovery ultimately becomes impossible after all.

In other words, actually connecting this to successful recovery requires thinking through a chain of operations such as the following:

Soft Delete
  +
Detection
  +
Alert Delivery
  +
Response within Retention Window

This chain is an educational organization used by this book, not a classification defined by an industry standard. Even so, you need to hold onto the idea that "having a deletion-protection mechanism" and "actually being able to recover in time" are separate problems.

8.7 When Data Remains but Cannot Be Recovered

There is one more commonly overlooked perspective.

Even if the backup data itself has not been deleted, if the cryptographic keys or other cryptographic material needed to decrypt that data are lost, changed, or become unavailable, you may in practice be unable to use that data for recovery.

This shows that, separately from protecting the data itself, key management also needs to be considered as an independent recovery-related dependency.

The concrete mechanisms or design of key management are not covered in this chapter. For now, hold onto the point that "data remaining" and "actually being able to use that data" can be separate problems.

8.8 Being Protected and Being the Correct Recovery Point Are Separate Problems

Finally, let's confirm one more important perspective.

In Chapter 1, we saw that when deletion, logical corruption, or a malicious change occurs, recovery may need to go to an older, known-good state rather than the newest one.

The properties covered in this chapter — Off-site, Offline, Isolated, and Immutable — all relate to whether a copy is "protected." However, a copy being sufficiently protected, and that copy actually being the correct point-in-time state to use for recovery, are separate problems.

Even a protected copy is not necessarily the correct recovery point. The judgment of which point-in-time state to trust and use for recovery is covered again in a later chapter.

8.9 Summary

This chapter organized four properties: Off-site, Offline, Isolated, and Immutable.

The important points are these:

• Off-site, Offline, Isolated, and Immutable are each different properties; satisfying one does not necessarily mean the others are satisfied.
• Off-site indicates separation of location, but does not imply separation of administrative authority, network, or keys.
• Offline is a property about reachability under normal conditions; it does not prove currency or having been verified.
• When told something is Isolated, you need to concretely confirm what is actually separated.
• The label Immutable alone cannot tell you whether something is safe; you need to check lock state, override authority, irreversibility timing, retention-policy authority, protected scope, and excluded resources.
• Soft Delete needs to be considered together with detection, notification, and response within the retention window.
• Even if data remains, if the cryptographic keys are lost, it may in practice be unusable for recovery.
• Being protected and being the correct recovery point are separate problems.

In the next chapter, we look at how to protect the Backup Infrastructure itself — that is, the administrative authority, credentials, keys, logs, and tools that support Backup.

Questions to Consider After Reading Chapter 8

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

• What does being Off-site guarantee, and what does it not guarantee?
• When you see the label Immutable, what specifically should you check?
• Can you explain why Soft Delete alone is not enough?
• Why can data remain and still be unusable for recovery?
• Can you explain why a protected copy is not necessarily the correct recovery point?

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.