Backup best practices: what Maersk, Travelex, and others teach Australian businesses

Most Australian business leaders know they should “have backups.” Fewer can say—with evidence—how long recovery would take, what data they would lose, or whether ransomware would encrypt those backups too. That gap is where real incidents turn into multi-week outages, ransom payments, or permanent data loss.

This guide explains backup and disaster recovery best practices in plain language, grounded in high-profile international cases that changed how the industry thinks about resilience. The lessons apply directly to Newcastle businesses, regional offices, and national teams running Microsoft 365, on-premises servers, or hybrid environments.

Quick answers

What is the 3-2-1 backup rule?

Keep at least three copies of important data, on two different types of storage, with one copy off-site or offline. It is a starting point—not a complete disaster recovery plan on its own.

Why did Maersk almost fail to recover despite having backups?

Maersk backed up file data, but nearly all Active Directory domain controllers were wiped in the 2017 NotPetya attack. Without identity infrastructure, recovery stalled until a single offline controller—in Ghana, kept offline by a power outage—provided a clean copy to rebuild the network.

Should Australian businesses pay a ransomware demand?

Australian government and law enforcement guidance generally advises against paying: it funds crime, does not guarantee decryption, and may not restore exfiltrated data. Focus on tested recovery paths and incident response instead.

How often should backup restores be tested?

Critical systems should be restore-tested at least quarterly; higher-risk or regulated environments often monthly. A backup that has never been restored is an untested assumption.

What is the difference between backups and disaster recovery?

Backups are copies of data. Disaster recovery is the rehearsed ability to restore services within agreed time and data-loss limits (RTO and RPO)—including applications, identity, networking, and runbooks—not just files on disk.

Backups are necessary—but not sufficient

A backup job that completes green on a dashboard is not the same as recovery under pressure. Incidents expose gaps: backups stored on the same network segment as production, identity systems never included in scope, Microsoft 365 assumed “already backed up” by Microsoft, or restore drills that never happen.

• Separate backups from production networks (immutable or offline where possible).
• Include identity (Active Directory / Entra ID), not only file shares and databases.
• Protect SaaS: Microsoft 365, Google Workspace, and line-of-business cloud apps need explicit retention and backup strategy.
• Document RTO (how long you can be down) and RPO (how much data you can afford to lose).
• Run restore tests and keep evidence for leadership, insurers, and auditors.

Case study: Maersk and NotPetya (2017)

In June 2017, NotPetya spread globally within minutes, encrypting systems at shipping giant A.P. Moller–Maersk and many other organisations. Maersk had followed conventional backup practice for file data, but the attack destroyed roughly 150 domain controllers—the Active Directory backbone that authenticates users and maps access across the fleet.

Recovery teams rebuilt thousands of servers and tens of thousands of PCs. Progress halted until staff found one domain controller that had been offline in Ghana during the attack (reported accounts also cite a Nigerian site affected by power loss). That single clean copy became the foundation to rebuild identity and automate operations again—a near-catastrophic dependence on luck.

Reported costs exceeded US$300 million; operations ran manually for days. The lesson for any business: identity and configuration are part of recoverability, not an afterthought.

Case study: Travelex (2019–2020)

On New Year’s Eve 2019, Travelex suffered a Sodinokibi/REvil ransomware attack that disrupted currency services worldwide. Attackers claimed they encrypted the network and deleted backups; sensitive data was allegedly exfiltrated. After weeks offline, reports indicated Travelex paid approximately US$2.3 million to recover operations—without resolving exposure of stolen data.

Travelex illustrates the lose-lose of weak recovery: pay ransom and still face regulatory and customer fallout, or refuse and rebuild from uncertain backups. For Australian financial and professional services firms, APRA, OAIC, and client contractual expectations make preparation cheaper than improvisation.

Case study: City of Baltimore (2019)

Baltimore’s RobbinHood ransomware attack in May 2019 shut down municipal email, payments, and property transactions. Attackers demanded roughly US$76,000 in Bitcoin. City leadership, advised by federal agencies, refused to pay. RobbinHood, like many modern strains, targets backup repositories and shadow copies to prevent easy recovery.

Recovery required new hardware, consultants, and months of manual workarounds. Widely reported total costs approached US$18 million—far beyond the ransom—plus lost revenue from delayed services. Baltimore also highlighted weak disaster recovery planning at the leadership level. Refusing ransom was principled; lacking tested recovery was costly.

Case study: UVM Health Network (2020)—backups helped, pain remained

The University of Vermont Health Network ransomware attack encrypted roughly 1,300 servers and 5,000 computers. The organisation did not pay ransom; leadership stated that secure backups allowed recovery of most data. Even with viable backups, clinical and administrative disruption lasted months, with reported losses exceeding US$63 million and hundreds of staff unable to work normally.

UVM proves backups matter—but also that recovery time, malware removal, and operational continuity determine real-world impact. Australian healthcare and professional firms face similar Notifiable Data Breaches (NDB) obligations when personal information is accessed or systems fail in ways that expose data.

What Australian businesses should do differently

Australian organisations operate under the Privacy Act 1988 (including the Australian Privacy Principles), the Notifiable Data Breaches scheme when eligible data breaches occur, and increasing insurer scrutiny after high-profile local ransomware campaigns. “We have a NAS that backs up nightly” rarely satisfies any of those audiences after an incident.

Define RTO and RPO in business terms

Email down for four hours may be painful; ERP or practice management down for four hours may stop revenue. Set recovery targets per workload, not one generic number for the whole business.

Treat Microsoft 365 as your responsibility

Microsoft provides robust availability for its platform—not unlimited point-in-time recovery of your tenant data. Retention policies, litigation hold, and third-party M365 backup each play a role. Layer 3 maps what you have versus what you need before an incident.

Assume ransomware will target backups

Immutable storage, offline rotation, and access controls on backup consoles are standard in modern BCDR design. If attackers can delete backups with the same credentials they used for everything else, you do not have defence in depth.

Rehearse—not just backup

Quarterly restore tests for critical systems, documented runbooks, and named decision-makers during incidents turn plans into capability. Maersk rebuilt heroically; smaller businesses rarely survive that level of disruption without preparation.

Related: Managed IT services include backup verification and ongoing monitoring for many clients.

FAQ

Are cloud sync tools like OneDrive the same as backup?

Sync mirrors current files—it does not replace versioned, isolated backup. Ransomware or malicious deletion can propagate through sync clients. Use sync for productivity and separate backup/retention for recovery.

What RTO and RPO should a small business target?

There is no universal number. Many SMBs target four to eight hours RTO for email and same-day RPO for critical files, with tighter targets for line-of-business apps. Document assumptions and test whether backups actually meet them.

Do we need separate backup for Microsoft 365 email and SharePoint?

If you rely on M365 for operations, yes—through a combination of native retention, legal hold where appropriate, and third-party backup for granular restore and long retention. Assess gaps before you need a mailbox from six months ago.

What role does immutable storage play against ransomware?

Immutable backups cannot be altered or deleted for a defined period—even by admin accounts compromised during an attack. That window gives you a clean recovery point when production and ordinary backups are encrypted.

How does the Notifiable Data Breaches scheme relate to backup failures?

If a cyber incident involves unauthorised access, loss, or disclosure of personal information likely to cause serious harm, eligible organisations must assess and may need to notify OAIC and affected individuals. Reliable logging, backup integrity, and incident response support that assessment. This is general information, not legal advice.

What should be in a disaster recovery runbook?

Contact tree, severity definitions, steps to isolate vs recover, restore order by system priority, vendor contacts, communication templates, and evidence collection for insurers and regulators. Runbooks should be tested, not shelfware.

Questions about your environment? Contact Layer 3 for a practical recovery review.