A backup is what you have restored, not what you have stored

At 10am on 24 March 2024, the systems of VNDIRECT were hit by a data-encryption attack. Trading at one of Vietnam's largest securities firms was paralysed for close to a week and only resumed on the morning of 1 April. Nine days later it was PVOIL's turn: the state oil corporation's IT systems went down, including electronic invoice issuance for sales.

The notable part is not that these two organisations lacked backups. A top-tier brokerage and a state petroleum corporation both had backup systems, procedures and documentation. The notable part is that they had backups and still lost eight days.

The distance between "we hold a copy of the data" and "we are operating again" is the part almost nobody measures before they need it. This article is about that distance: why it exists, why it is wider than people assume, and how to measure it.

The right metrics, measured along the wrong axis

The two standard metrics of resilience design are RTO (how long until we run again) and RPO (how much data can we afford to lose). Both are correct, and both come from a specific failure model: a failed disk, a dropped table, a fire in the server room, a flooded basement. In that model, the most recent copy is always the best copy. So the engineering effort goes into driving RPO down — more frequent backups, near-real-time replication, snapshots every fifteen minutes.

Modern ransomware breaks precisely that assumption. According to the National Cybersecurity Association's Vietnam Cybersecurity Report 2025, the prevailing tactic is now a two-stage one: after gaining access, attackers are in no hurry to encrypt. They stay quiet for a long period and exfiltrate valuable data to sell or trade; only once there is nothing left to take do they encrypt for extortion.

The consequence for backups is direct. If the attacker has been inside for ninety days before pressing the button, then every copy taken during those ninety days was made from an already-controlled system. The most recent one — the one the entire design optimises for — is the most deeply compromised.

So the real question is not "how recent is our newest copy" but "how far back can we go and still have something usable". That is a different axis entirely, and it needs a different design: retention long enough to clear the dwell window, old copies that still restore, and some way to identify the last clean one.

This second axis almost never appears in a service contract. SLAs typically commit to backup frequency and restore time; they rarely commit to "restorable to a point ninety days ago". If you read only one line in your backup contract, read the retention clause.

The backup repository is not a shelter — it is the first target

The second unspoken assumption is that the backup repository sits outside the fight. It does not.

A survey of 1,200 organisations that had suffered ransomware, published in the Veeam Ransomware Trends report and summarised here, found that backup repositories were targeted in 96% of attacks and successfully breached in 76%. On average only 57% of affected data was recovered — meaning 43% was never retrieved.

This is not a secondary technical detail. Sophos's analysis of the impact of compromised backups found median recovery costs of $3M for organisations whose backups were compromised — eight times the $375K median for those whose backups held. Median ransom paid was nearly double as well: $2M against $1.062M. The reason is easy to see: losing your backups means losing your entire negotiating position.

One more figure completes the picture. Sophos's State of Ransomware 2026 report, surveying 2,158 IT and security leaders whose organisations were hit in the previous twelve months, records compromised identity as a factor in 79% of cases, and the share of attacks that succeeded in encrypting data rising from 50% to 56%.

Identity is the link, and that is exactly where most backup architectures are exposed: the backup repository usually lives in the same identity domain as production. Same Active Directory, same cloud tenant, same admin group, same SSO. Convenient to operate, and it also means a single compromised administrator account takes down both at once.

Put another way: a backup repository that production can delete is not a backup — it is another copy of production.

Three properties that separate a backup from a copy

• Immutable for a window that cannot be shortened. Object lock, WORM, or a retention policy under legal hold — the essential property is that *not even the highest administrator can delete it early*. If some privilege can shorten that window, that privilege is what the attacker will go looking for.
• A separate identity domain. Its own credentials, its own MFA, not joined to the production domain, not sharing SSO. Backup infrastructure deserves to be treated as its own security zone, in the same way zones and conduits separate an industrial control zone from the office network.
• At least one copy that is not reachable online. Tape, removable media, or an account with a different provider that production has no path to. This is the copy that answers the question "what if our entire administrative domain is taken".

The familiar 3-2-1 rule — three copies, two media types, one offsite — remains correct but is no longer sufficient, because it only speaks to *disasters and hardware failure*. The version in wider use today is 3-2-1-1-0: add one immutable or offline copy, and zero errors in the most recent restore test. That final zero is the hardest part, and the most commonly skipped.

The real bottleneck in recovery is ordering, not volume

The 2026 numbers contain an apparent contradiction. The share of organisations recovering data from backups rose to 66%, twelve percentage points above the previous year — a genuine improvement. Yet average recovery cost still rose 11%, to $1.7M per incident.

If read throughput from backup were the bottleneck, those two numbers would have to move in opposite directions. They do not, because the bottleneck is somewhere else: the order of restoration.

Backup inventories at most organisations are assembled against a perfectly sensible criterion — which systems hold important data. But when you have to rebuild from an empty environment, the things that must come up first are precisely those that hold no business data at all:

• Internal DNS and address allocation, because without them no component can find any other component.
• The identity directory (AD, LDAP, IdP), because without it nobody can sign in anywhere.
• The secrets store and internal CA, because without them services cannot authenticate to each other.
• The image registry, internal package repository and licence servers, because without them nothing can be redeployed.
• And the backup system itself — its orchestration software, its catalogue, the encryption keys for the repository.

Omitting this group produces a very characteristic class of deadlock, and every organisation hits at least one of them in its first real exercise: the password needed to restore lives in the password manager, the password manager authenticates through SSO, and SSO runs on a server that has not been restored yet. Or: the recovery runbook lives on the internal wiki, and the internal wiki was encrypted too.

This is also why a "let's test-restore a database" exercise tells you almost nothing. It tests the part that already worked — reading data back out of a copy — and skips the entire portion that actually consumes the clock during a real incident.

The one-afternoon test

No project required, nothing to buy. Four steps, each producing either a number or a list.

• Restore a real system into an empty environment and time it. Pick a system with real users. Rebuild it somewhere with nothing already in place. Measure from start until a real user signs in and completes one end-to-end task. That is your actual RTO.
• Establish who can delete backups. List every account that can delete copies, change retention, or shorten an immutability window. If that list intersects your production administrator list, you have just found your largest single risk.
• Draw the cold-start dependency graph. What must be alive before the first business system can start. Compare it against what is actually being backed up. The gap between the two lists is the cheapest thing to fix and the thing most often left unfixed for years.
• Restore from a ninety-day-old copy. Not the newest one. Three things fail silently here: an obsolete backup format the current software cannot read, an encryption key that has since been rotated, and an old schema the current application refuses to run against. All three surface only when tested.

Three numbers are worth recording after each run: how long it took, how many people it took, and how many steps had to be improvised outside the runbook. The third is the best available indicator of whether the documented procedure matches reality.

The Vietnamese context

The National Cybersecurity Association's 2025 figures contain a striking pair. Total attacks against information systems in Vietnam fell 19.38%, to roughly 552,000 incidents; yet the proportion of organisations recording damage rose from 46.15% to 52.30%. Fewer incidents, each more expensive — consistent with the shift from broad, opportunistic attacks toward selective ones that dwell for a long time and exfiltrate before encrypting.

On the positive side, around 51.45% of organisations ran cybersecurity exercises. The follow-up question is what those exercises actually rehearse: intrusion detection, or recovery from a cold start. The two build different capabilities, and only the second answers the question "eight days or eight hours".

On the regulatory side, Decree 85/2016/NĐ-CP on information system security by classification level already sets backup and recovery requirements scaled to each level. As with every compliance framework, the dossier describes the system as it was when the dossier was written; resilience is decided at the moment the incident happens.

There is one practical tension worth calling out on its own, because it falls in the gap between two departments. Ransomware strategy pushes toward long retention that cannot be deleted, while the Personal Data Protection Law pushes toward deletion once the purpose ends or the data subject asks. A backup containing personal data is still personal data, but an immutable backup is by definition not selectively erasable.

The common resolution is not to pick a side but to separate the two modes: define backup retention explicitly, record that erasure requests are executed immediately against live systems and against copies as they age out on schedule, and never restore deleted data back into production when recovering from an older copy. That last point requires a list of erased records held outside the backup scope — a small detail, but without it every restore quietly resurrects data that was supposed to be gone.

Conclusion

VNDIRECT had backups. PVOIL had backups. Most of the organisations knocked over by ransomware in the past two years had backups. Backup was never the answer to this question — it is only the precondition.

The three things that actually decide the outcome sit elsewhere, and all three can be measured before they are needed: whether the backup repository is out of reach of a compromised identity, whether retention reaches back past the attacker's dwell time, and whether the restart order has ever been run from a cold start.

The day you discover an incident is the worst possible day to learn the answers for the first time. One afternoon of rehearsal gives you three real numbers, and three real numbers are worth more than a very well-written recovery dossier.

If you want to know the real RTO of a specific system — not the one in the document — get in touch to run a restore test, or see KonexForge's Server & Database capability.