CLOUD RECOVERY / UNISUPER CASE
Replication is useful.
Independence matters too.
The UniSuper incident is a reason to test the recovery boundary, not simply count regions.
Two copies of a service can share the same failure mechanism. The UniSuper incident is a useful case study in why geographic redundancy, backup survival, and a demonstrated business recovery are separate questions.
Recoverability is the central issue. Google’s technical account also narrows what was deleted, which is important when drawing the lesson.
THE EXECUTIVE BRIEF
The decisions that matter.
- Read the incident as a defined private-cloud deletion, not the disappearance of every Google account or service.
- Check whether backup copies share the same administration and deletion controls.
- Rehearse the dependencies needed to rebuild a working service, not just retrieve data.
THE CASE / MAY 2024
What Google’s account says was affected.
The Ars Technica story described the UniSuper outage and pointed readers to Google’s explanation. In its 24 May 2024 incident review, Google said the impact was one customer’s GCVE Private Cloud in one region, across two zones. Other private clouds, the customer’s Google account structure, and Google Cloud Storage backups were not deleted.
Google attributed the event to a blank parameter in an internal provisioning tool. It caused an unknown fixed one-year term and automatic deletion at its end, without a customer-deletion notification. The company described corrective changes to the trigger and downstream behaviour.
The surviving Cloud Storage backups and third-party backup software assisted restoration. This is a more precise account than saying that all backups or the entire Google account vanished. It also shows why the scope of a deletion matters when assessing independence.
THE ASSURANCE QUESTION
Distance is not the only boundary that matters.
A BACKUP REVIEW SHEET
Different locations can still share control.
LOCATION
Where are the copies?
Identify the physical or regional failure that geographic separation is intended to address.
AUTHORITY
Who or what can delete them?
Examine shared administrators, credentials, lifecycle rules, and control-plane dependencies.
RECOVERY
What else is needed to restore?
Include identity, configuration, networking, software, keys, and people as well as the data itself.
CyberSolace assurance questions. This does not represent UniSuper’s actual architecture or imply every same-provider backup shares a deletion boundary.
Keep the distinctions explicit in board reporting. A second zone may protect against a local outage without protecting against the same administrative instruction. Another provider can reduce some common dependencies while introducing cost, compatibility, and recovery work of its own.
The sensible design depends on the service and loss scenarios. Assess the failure you need to survive before specifying that every workload must be duplicated across multiple providers.
REBUILD THE SERVICE
A restored file is not a restored pension service.
Disaster-recovery planning, retention, supplier concentration, and transparency become useful when expressed as testable questions.
- Can the recovery team authenticate and obtain the necessary authority if the normal environment is unavailable?
- Are configurations, dependencies, software, and required secrets recoverable through a controlled process?
- Can restored records be reconciled with recent transactions and checked for completeness?
- Who decides that the service is safe and usable enough to return to customers?
Use an authorised test to establish how much of that sequence has been demonstrated. Record exclusions honestly. A successful recovery of a sample dataset does not prove the entire customer journey can operate within the desired interruption limit.
RETENTION & CHANGE
Challenge defaults and exceptions that can outlive the project.
Ask suppliers how lifecycle rules, subscription changes, cancellation, and privileged deletion affect both active resources and backups. Establish which protections the customer can configure and which remain provider-controlled.
Exception processes deserve particular attention. A one-off provisioning decision can remain invisible until a later event. Keep the rationale, owner, review trigger, and expected end state visible rather than assuming a successful initial deployment closes the risk.
Use the published incident review as a prompt for your own arrangements. It is evidence of one reported event, not proof that every cloud service has the same failure or that no provider improvement is possible.
A PRACTICAL NEXT STEP
Choose a backup and test the boundary around it.
CyberSolace can help connect supplier assurance and recovery evidence to the business service that must return.
SOURCES & EDITORIAL REVIEW
Historical findings and incident accounts are dated in the text. Illustrative review prompts are CyberSolace commentary. Editorial review: 20 October 2026.