Almost every company has backups. Very few have a proven ability to recover. The gap between those two statements is where most serious data-loss incidents actually happen.
The reason lies in the assumption traditional backup was designed around. Classic backup addresses accidental failure: a failed disk, a deleted file, an upgrade that corrupts a database. In those scenarios nobody is actively trying to disable the backup itself. Under deliberate attack that assumption no longer holds, and the backup system becomes the first target rather than the last resort.
Why an ordinary backup is not enough
A conventional backup system usually has the following characteristics, each of which is a weakness against a deliberate incident:
- Same authentication domain. The backup servers belong to the same identity system as production. Administrative control in one place leads to administrative control in the other.
- Deletion is permitted. Backup administration inherently includes removing old data to reclaim capacity. If the operation exists, it can be abused.
- Permanently connected. The repository is mounted continuously to serve automated schedules, which means it is reachable from the environment it protects.
- It faithfully copies bad state. Incremental backup replicates every change, including malicious ones, and if the retention window is short the clean versions roll out of the cycle.
- Shared credentials. The service account that runs backup jobs is often stored on the very system being backed up.
What immutability actually means
Immutable means that once data is written it cannot be modified or deleted until a defined retention period expires, and that this is enforced by the storage layer rather than by operational policy. The distinction matters: an internal rule stating that nobody may delete backups is policy. A storage system that refuses a delete request even from the highest-privileged administrator is a technical control.
Object lock
In cloud object storage, object lock applies a retention period to each object version. There are two modes with very different protective strength, and choosing the wrong one is the most common mistake in this area.
- Governance mode. Ordinary users cannot delete, but an identity with a specific privilege can shorten the retention or remove the lock. It is useful against mistakes but does not withstand a compromised administrative identity.
- Compliance mode. Nobody can shorten the period or delete the data early, including the platform root account. This is the mode that provides real protection, and it is also the one that demands operational discipline, because a misconfiguration locks both the data and its storage cost for the whole retention period.
WORM on storage appliances
Write once, read many predates the cloud and is implemented on dedicated storage appliances, tape systems and software-defined storage. On modern systems WORM is usually enforced by the appliance’s software layer, so the question to ask a vendor is precise: can an administrator of this appliance disable the mechanism, and through what path.
Retention lock
This is protection applied to the protection configuration itself. Without it, an intruder does not need to delete anything; they can reduce the retention period to its minimum and let the system clean up exactly as designed. Retention lock makes shortening impossible, usually together with a mandatory delay before any change takes effect.
Air-gapping
An air gap is a separation that a network connection cannot cross on its own. The absolute form is tape removed from the library and stored offline. In the cloud, the practical form is a copy held in a separate account with its own identity system, written under a push-only model where the source environment has no path back into the copy.
Comparing the mechanisms
| Mechanism | What it stops | Main weakness |
|---|---|---|
| Object lock, governance mode | Accidental deletion, loose process | A compromised admin identity can remove the lock |
| Object lock, compliance mode | Deliberate deletion at any privilege level | Mistakes cannot be undone; cost is locked in |
| Appliance WORM | Modification of written data | Depends on whether appliance administration is controlled |
| Retention lock | Shortening retention so data expires itself | Does not protect data written after compromise |
| Account or physical air gap | Spread via network paths and shared identity | Slower recovery, more operational complexity |
Failure modes immutability does not solve
Immutability is a strong control, but it is frequently presented as a complete answer. These are the failure modes to account for during design.
Compromise before the lock
Immutability protects data that has already been written and locked. If the environment was compromised earlier, backups created after that point may contain data in an unclean state, or contain the very mechanism that allows a return. Locking them only guarantees that you cannot delete an unusable backup. The practical consequence is that you need enough historical depth to reach a point before the incident began, and the ability to identify that point, which means logs stored somewhere separate.
Choosing an overridable mode
This is the most common failure in practice. An organisation enables object lock in governance mode because it is operationally safer and mistakes can be corrected, then records in its documentation that backups are immutable. Technically true, but true at the level of protecting against accidents rather than against intent. Verify which mode is actually in use, and which identities are able to remove the lock.
Retention shorter than attacker dwell time
If an incident unfolds quietly over a long period before discovery, and retention is only fourteen days, then every surviving backup belongs to the affected window. Immutability in that case protects precisely the data that cannot help. The answer is tiered retention: dense recovery points for recent time, plus longer weekly and monthly retention.
Deletion at the account or billing layer
This is the most overlooked gap. Object lock prevents object deletion, but it does not prevent closing the entire cloud account, does not prevent non-payment leading to resource reclamation, and does not prevent removal of the encryption keys the data depends on. If the immutable copy sits inside the same cloud organisation and the same billing relationship as production, there is a layer above where all of the protection can be undone at once. Countermeasures include placing backups in a separate account with its own administration, protecting the root account with hardware-based multi-factor authentication, alerting on organisation and billing-level changes, and managing encryption keys with a waiting period on key deletion.
Never testing an actual restore
A backup that has never been restored is a hypothesis. The problems that only surface during a real restore include missing decryption keys, a configuration component that was never in scope, undefined restore ordering between dependent systems, retrieval bandwidth far lower than estimated, and nobody on the on-call rota knowing the procedure because its author has left.
A restore exercise should include restoring into an isolated environment, validating that the data is correct rather than merely present, measuring the real elapsed time until service is usable again, and being performed at least once by someone who did not write the procedure.
A reasonable minimum design
For most companies, a sufficient design contains the following:
- A near copy for fast recovery, in the same region as production, optimised for speed.
- An immutable copy in a non-overridable mode, held in a separate account with its own identity system and written push-only.
- A copy in another region or offline, for the case where a whole region or account control is lost.
- Tiered retention, long enough to outlast the time an incident typically takes to surface.
- Alerting on every change to protection configuration, delivered to a channel the operations team watches daily.
- A fixed restore-exercise schedule, with results recorded and compared against the committed objectives.
How HiTechCloud can help
HiTechCloud is an AWS partner and a Google Premier Partner, and operates in-country infrastructure. We help organisations design layered backup with an immutable copy in a separate account, configure tiered retention, set up alerting on changes to protection configuration, and run restore exercises that confirm real recovery times. Contact us if you would like a review of your current backup position.
