Top 10 Backup and Recovery Mistakes: What Goes Wrong Most Often and How to Fix It

Most organisations find out their backups do not work on the worst day possible: during a ransomware incident, when the backups have been deleted with the same administrator account that encrypted production, or when a restore that was never tested takes three weeks instead of three days. This list ranks the ten backup and recovery mistakes that most often turn an incident into a business-ending outage, with how to spot each one, how to fix it, and the incidents that show the cost. Fixes draw on the NCSC's principles for ransomware-resistant cloud backups, CISA's #StopRansomware Guide and NIST guidance. It is written for infrastructure and cloud platform owners, backup administrators, security teams and continuity leads. The Backup Security and Immutable Backup Guide explains the architecture in depth; this page is the short list of what goes wrong most often.

The Top 10 at a glance

The ranking is our judgement of how directly each mistake leads to failed recovery. Items 1 and 2 come first because ransomware operators target backups deliberately: MITRE ATT&CK T1490 Inhibit System Recovery describes adversaries deleting recovery features and even disabling recovery notifications before corrupting backups.

1. Backups reachable with production admin credentials

The mistake: the backup server is joined to the production domain, backup administrators use their normal domain admin accounts, and backup service accounts hold broad rights with passwords that never change.

Why it matters: an attacker who reaches domain or cloud administrator rights reaches the backups in the same step. The NCSC principles ask that destructive requests from customer user and machine identities be forbidden except where authorised out of band, and that access not depend on a single account.

How to check: list every account that can delete backups, change retention or disable jobs, and ask whether any of them also administers production or sits in the production directory.

How to fix: run backup administration from dedicated accounts outside the production directory, with phishing-resistant MFA; scope and rotate backup service accounts; and place at least one copy in a separate cloud account, subscription or tenant. See the Backup Identity Isolation Guide.

2. No immutable or offline copy

The mistake: every backup copy sits on storage that an administrator can delete or overwrite, often because immutability was never switched from test to enforced mode.

Why it matters: CISA's #StopRansomware Guide recommends maintaining offline, encrypted backups of critical data because ransomware targets accessible backups. The NCSC's first principle is that backups should be resilient to destructive actions: block deletion or alteration once created, with retention periods set in advance.

How to check: for each Tier 1 system, name the copy that cannot be deleted by your most privileged administrator during its retention period. If you cannot, there is none.

How to fix: use write-once storage (object lock, vault lock, immutable vaults) or offline media for at least one copy. In Azure, for example, Microsoft describes an immutable vault that can be locked to make the setting irreversible, and multi-user authorisation with a Resource Guard in a separate subscription or tenant. Soft delete with a delay and an alert, as the NCSC recommends, catches what slips through. See the Backup Platform Hardening Guide.

3. Restores never tested end to end

The mistake: "backup job succeeded" is treated as proof of recovery; restore tests, if any, recover a single file.

Why it matters: a full recovery depends on bandwidth, rebuild order, licences, DNS, identity and people who know the steps. None of those is tested by a file restore. CISA's guide asks organisations to test the availability and integrity of backups in a disaster recovery scenario.

How to check: find the date and measured duration of the last full restore of each Tier 1 service, and compare it with its recovery time objective.

How to fix: schedule timed full restores to an isolated environment for Tier 1 services at least quarterly, including a restore from the immutable copy without production credentials. Record restore time against RTO as a metric. The NCSC asks providers to offer non-destructive restore testing run regularly to detect corrupted backups. See the Backup and Recovery Policy Template for test frequencies.

4. Retention by count or too short

The mistake: backup sets keep "the last 14 versions" or a short daily window, so a burst of corrupted or encrypted backups pushes good versions out, or the intrusion started before the oldest copy.

Why it matters: the NCSC's third principle says retention should be for a fixed time period rather than a fixed number of backups, so rapid corrupt overwrites cannot push out good copies, with version history and flexible schedules such as daily backups for a month and monthly for a year.

How to check: confirm retention is time-based and that the oldest immutable copy predates the dwell time your incident response team assumes.

How to fix: move to time-based retention with daily, weekly and monthly tiers, and set immutable retention at least as long as your expected detection time.

5. Identity and rebuild assets not backed up

The mistake: application data is backed up, but Active Directory, the identity provider's configuration, DNS, firewall rules, infrastructure-as-code templates and system images are not, or are stored only inside the environment they rebuild.

Why it matters: without identity, no one can sign in to restore anything. CISA's guide recommends maintaining and regularly updating golden images of critical systems and keeping backups of infrastructure-as-code template files offline.

How to check: walk through rebuilding your identity provider and one Tier 1 service from nothing, listing every configuration item needed and where its backup lives.

How to fix: back up directory and IdP configuration, IaC, golden images and the recovery runbook itself, with an offline copy. CISA also advises keeping a hard copy and an offline version of the incident response plan. See IdP configuration backup and restore for Entra ID and Okta.

6. SaaS and cloud data assumed safe

The mistake: Microsoft 365, Google Workspace, CRM and source code platforms are assumed to be "backed up by the provider", and cloud object storage relies on replication rather than independent copies.

Why it matters: provider resilience protects against the provider's failures, not against a compromised administrator, a malicious integration or a ransomware actor using your own keys. In the Codefinger S3 ransomware campaign, attackers used stolen long-term AWS keys to re-encrypt objects with SSE-C keys only they held and set lifecycle rules to delete the files within seven days.

How to check: for each SaaS platform and critical bucket, name the copy that is outside the tenant or account and outside the reach of its administrators.

How to fix: back up SaaS data to storage you control, enable versioning and object lock on critical buckets, and replicate to a separate account with its own credentials. CISA suggests backing up often, offline or with cloud-to-cloud backups. See the Microsoft 365 Backup guide and the SaaS Backup Buyer's Guide.

7. Encryption keys stored or lost with the backups

The mistake: backup encryption keys stored in the same storage or account as the backups, or held only in a key service that would be lost in the same incident.

Why it matters: in the GoTo breach, encrypted backups for five products were stolen from a shared cloud storage provider together with an encryption key for part of them. The reverse failure is just as bad: a deleted or unreachable key makes good backups useless.

How to check: trace where each backup key lives, who can read or delete it, and how you would recover it if your key service or identity provider were down.

How to fix: hold keys apart from the backups they protect, under separate administrators, with deletion protection. The NCSC's fourth principle asks for an out-of-band key backup, such as a printed master key or QR code kept in a secure location.

8. Backup alerts missing or unwatched

The mistake: job failure emails go to a shared mailbox nobody reads, and deletion, retention changes or disabled jobs raise no alert at all.

Why it matters: attackers disable notifications before corrupting backups (T1490). The NCSC's fifth principle asks for alerts on mass deletions, backups stopping, retention or encryption changes and administrator account changes, whether or not they succeed, delivered through multiple mechanisms so they arrive even if your infrastructure is compromised, and backed by an incident process.

How to check: delete a test restore point in a non-production vault and time how long until a person acts on the alert.

How to fix: forward backup platform logs to the SIEM, alert on the events in the detection table below, and route the critical ones to a channel outside corporate email.

9. Restoring the attacker along with the data

The mistake: under pressure, the team restores the most recent backup, which contains the attacker's persistence: web shells, scheduled tasks, rogue accounts or backdoored images.

Why it matters: reinfection after recovery doubles the outage. NIST CSF 2.0 outcome RC.RP-03 asks that the integrity of backups and other restoration assets be verified before using them for restoration.

How to check: confirm your recovery runbook includes a step to choose a restore point from before the intrusion and to scan restored systems before reconnecting them.

How to fix: restore to an isolated network, scan with current indicators of compromise, reset credentials (especially service accounts and keys) before reconnecting, and keep the forensic copy separate. See Recovering IAM and PAM After Ransomware or Domain Compromise.

10. Backup vendors and tools trusted without limits

The mistake: backup software and SaaS backup services are granted tenant-wide read and write rights, with their credentials, console access and vendor support channels outside your monitoring.

Why it matters: the backup tool can read everything it protects. In the ConnectWise Cloud Backup breach, an attacker used the backup application's own credential to sign in to Microsoft 365 customer tenants, where it already held tenant-wide access to mail, files and Teams chats, and MFA played no part.

How to check: list the permissions granted to each backup application and service account, who at the vendor can use them, and whether their sign-ins reach your SIEM.

How to fix: grant the narrowest permissions the product supports, monitor backup application sign-ins, include "disable the backup app" in your incident playbooks, and patch backup servers as internet-facing systems. See the Veeam Backup and Replication Hardening Guide for one platform's specifics.

Detection: what to alert on

Measure progress with five numbers: percentage of Tier 1 systems with a current immutable or offline copy; measured restore time against RTO for each Tier 1 service; backup accounts that also hold production admin rights (target zero); SaaS platforms with an independent backup; and median time from a backup deletion alert to human response.

Common failure patterns

• Immutability left in test mode: governance or unlocked modes can be reversed by an administrator; the dashboard says immutable, the attacker disagrees.
• The recovery runbook lives on the encrypted file share: keep an offline and printed copy, as CISA recommends.
• Break-glass access that depends on corporate SSO: the NCSC asks for an out-of-band route to backups that works when corporate IT is down.
• Restore tests that skip the hard part: testing a VM restore but not the identity provider it needs to start.
• Backup scope frozen at deployment: new SaaS platforms, databases and cloud accounts are never added; review scope against the asset inventory quarterly.

Mapping to NIST, CIS and ATT&CK

CIS Controls v8.1 Control 11 Data Recovery and ISO/IEC 27001:2022 Annex A 8.13 Information backup cover the whole list.

Where to start

1. Week one: list who can delete backups (item 1) and which Tier 1 systems have an immutable or offline copy (item 2). These two answers decide whether ransomware is survivable.
2. Week one: turn on deletion and retention-change alerts routed outside corporate email (item 8).
3. Weeks two to four: separate backup administration from production identities and enable immutability in test mode on one Tier 1 workload, confirm restore behaviour, then enforce it.
4. Month two: back up identity and rebuild assets and SaaS data (items 5 and 6); move keys apart from backups with an out-of-band copy (item 7).
5. Month three: run a timed full restore of one Tier 1 service from the immutable copy, without production credentials, including the clean restore-point check (items 3 and 9).
6. Roll back safely: keep existing jobs running until new jobs pass two restore tests; confirm retention values before enforcing locks, because locked retention generally cannot be shortened.

Practitioner checklist

• No account that administers production can delete or alter backups.
• Every Tier 1 system has an immutable or offline copy in a separate security domain.
• Timed full restores run for Tier 1 services, with results recorded against RTO.
• Retention is time-based and the oldest immutable copy predates assumed dwell time.
• Directory, IdP configuration, IaC, golden images and the recovery runbook are backed up, with offline copies.
• SaaS platforms and critical buckets have independent backups outside their tenant or account.
• Backup keys are held separately, deletion-protected, with an out-of-band copy.
• Deletion, retention, job and key changes alert through more than one channel.
• The recovery runbook includes choosing a clean restore point and scanning before reconnecting.
• Backup application permissions are minimal and their sign-ins monitored.

Standards and references

• NCSC: Principles for ransomware-resistant cloud backups
• CISA: #StopRansomware Guide
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• MITRE ATT&CK: Inhibit System Recovery
• Microsoft Learn: Immutable vault for Azure Backup
• Microsoft Learn: Multi-user authorization using Resource Guard

Related NHI Mgmt Group resources: Backup Security and Immutable Backup Guide · Backup and Recovery Policy Template · Backup Identity Isolation Guide · Cloud Native Backup and Ransomware Resilience Guide · Backup and Cyber Recovery Buyer's Guide