Ransomware-Resilient Backups — The 3-2-1 Rule, Storage That Cannot Be Overwritten, and Checking That You Can Restore

In ransomware attacks, there are many cases where an organization had backups but still could not restore. The most common cause is that the backups were encrypted along with everything else. This article covers how to build backups that withstand attacks, for the Windows PCs and file servers of small and medium-sized businesses.

There are three key points: keep one copy that an infected PC cannot overwrite, do not use “Previous Versions” in place of backups, and confirm that you can actually restore. The 3-2-1 rule determines how many copies you keep and where, but on its own it leaves gaps as a defense against ransomware.

The commands in this article are Windows-only, and their output was checked at an administrator command prompt on Windows Server 2022. Product settings screens and prices can change, so check each vendor’s latest documentation when you introduce them.

Many Organizations Had Backups but Could Not Restore

Japan’s National Police Agency asks organizations hit by ransomware about the state of their backups. In its report for the first half of 2025, 51 of the 53 organizations that answered had taken backups. However, of the 48 asked whether they could restore from backup to the level just before the attack, only 7 could and 41 could not¹.

Of the 35 that gave a reason for not being able to restore, 23 said “the backups were encrypted too”, 8 said “operational failures” and 4 said “other”¹. The same report says ransomware groups delete victims’ logs and backups to erase their traces and prevent recovery. It then asks organizations to keep backups in an offline environment².

flowchart TB
        accTitle: How you can have backups and still not restore
        accDescr: A diagram showing that even if you take backups, they are encrypted along with everything else when they are reachable from the infected PC, and that if the restore procedure has not been checked, operational failures prevent restoration.
        A["Backups are taken"] --> B{"Reachable from the infected PC?"}
        B -->|"Reachable"| C["Encrypted or deleted too"]
        B -->|"Not reachable"| D{"Restore procedure checked?"}
        D -->|"Not checked"| E["Cannot restore due to operational failures"]
        D -->|"Checked"| F["Can restore"]

Figure 1: Backups are usable when the infected PC cannot reach them and the restore procedure has been checked.

There are cases where restoration worked. The 4th edition of IPA’s “Information Security Guidelines for SMEs” includes the case of a construction company whose file servers and other systems were encrypted after an intrusion through a VPN appliance. Partly because the company held restore drills twice a year, it brought its core systems back from backups five days after discovering the attack. Even so, it took 41 days to resume each internal system and four months to resume remote access, and the company lost more than 20 percent of its internal files³. Being able to restore from backups does not make the damage go away.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (13 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

Attackers Delete the Backups They Can Reach

The #StopRansomware Guide published by CISA and other US agencies says that many ransomware variants try to find and delete or encrypt accessible backups, so that the victim cannot recover without paying the ransom. It therefore says it is important to keep backups offline⁴.

Microsoft also writes that attackers focus on disabling backup software and OS features such as volume shadow copies⁵. Backups an infected PC can reach include the following.

• External drives that are always connected to the PC
• NAS or file server shares mapped to a drive letter
• Cloud sync folders that the everyday account can write to
• Shadow copies (Previous Versions) on the same volume

Even the commands built into the OS can delete shadow copies and backup catalogs. MITRE ATT&CK classifies this technique as “Inhibit System Recovery” (T1490). It gives examples such as deleting all shadow copies with vssadmin.exe delete shadows /all /quiet and deleting the Windows backup catalog with wbadmin.exe delete catalog -quiet⁶. The CISA guide also asks organizations to watch for suspicious use of vssadmin.exe, wbadmin.exe, wmic.exe (shadowcopy) and similar tools⁴.

flowchart TB
        accTitle: Backups an infected PC can and cannot reach
        accDescr: A diagram showing that an infected PC can write to always-connected external drives, mapped shares, sync folders and shadow copies, but cannot write to disconnected media or storage that cannot be overwritten.
        P["Infected PC"] --> R["Places it can write to"]
        P -.-x N["Disconnected media, storage that cannot be overwritten"]
        R --> A["Always-connected external drive"]
        R --> B["Mapped shared folder"]
        R --> C["Cloud sync folder"]
        R --> D["Shadow copies"]

Figure 2: Backups kept where an infected PC can write become targets of the attack.

You also need to watch for attacks that take time. Microsoft writes that ransomware sometimes encrypts gradually while leaving the key on the system. Users can keep using the data as usual during that time, so backups of encrypted data keep accumulating without anyone noticing. Once everything is encrypted and the key is deleted, even recent backups cannot be read⁵. If you keep only the most recent generation, there is nothing to go back to in this case.

“Previous Versions” Do Not Replace Backups

Windows “Previous Versions” and Shadow Copies of Shared Folders use the Volume Shadow Copy Service (VSS). The VSS system provider that comes with Windows uses a copy-on-write method that saves a block’s contents to a diff area before the block is overwritten, and so reproduces the volume as of a point in time⁷.

In its VSS documentation, Microsoft explains the difference between shadow copies and backups as follows. When data is copied from a shadow copy to removable media such as tape, the contents of that media become the backup. After the copy, the shadow copy itself may be deleted⁷. The documentation also says that when the diff area runs short, older shadow copies are deleted first⁷.

flowchart TB
        accTitle: The difference between shadow copies and backups
        accDescr: A diagram showing that a shadow copy is a set of differences from the original volume and is deleted when space runs short or by an attacker, whereas a backup copied to separate media survives even if the original volume is lost.
        V["Original volume"] --> S["Shadow copy (differences)"]
        S --> L["Deleted oldest first when space runs short"]
        S --> K["Deleted by an attacker with vssadmin"]
        S -->|"Copy to separate media"| B["Backup"]
        B --> R["Survives even if the original volume is lost"]

Figure 3: Shadow copies depend on the data of the original volume; what you copy to separate media becomes the backup.

Shadow copies are handy for letting users restore files they overwrote by mistake on their own. However, as described in the previous section, attackers sometimes delete them. The mechanism and operation are explained in detail in “Volume Shadow Copy (VSS): The Mechanism and the Practice”.

To list which shadow copies remain, run vssadmin list shadows at an administrator command prompt. This subcommand is available on both clients and servers⁸.

vssadmin list shadows

Version history and the recycle bin in OneDrive and SharePoint are also ways for users to get files back. Microsoft recommends teaching users how to restore their entire OneDrive to an earlier point in time. It also says to have users restore only once you are confident the attacker has been evicted, and to prepare for the case where users also restore the malware⁵.

The 3-2-1 Rule Decides How Many Copies and Where

The 3-2-1 rule is a rule of thumb for how to keep backup copies. “Data Backup Options”, written for US-CERT in 2012, explains it as follows⁹.

• 3: Keep three copies of important files, the original plus two backups.
• 2: Store them on two different types of media to guard against different kinds of disaster.
• 1: Keep one copy outside the home or business.

As its source, the document cites “The DAM Book”, a book on managing digital photographs by the photographer Peter Krogh⁹. Microsoft also cites this rule in its documentation on backups for ransomware protection, and describes the “1” as “offsite or cold copy”⁵.

What the 3-2-1 rule asks for is keeping a copy off site. It does not require the off-site copy to be offline or immutable. So if the off-site copy is in a cloud that an infected PC can always write to, it may be encrypted together with the local copies. The CISA guide and Microsoft’s documentation list offline storage as a ransomware defense. Microsoft also lists storage that cannot be overwritten⁴⁵.

flowchart TB
        accTitle: The 3-2-1 rule and ransomware protection
        accDescr: A diagram showing adding one offline or immutable copy to the 3-2-1 rule of three copies, two kinds of media and one off site, and then confirming that you can restore.
        A["Three copies"] --> B["Two kinds of media"]
        B --> C["One off site"]
        C --> D["One offline or immutable"]
        D --> E["Confirm that you can restore"]

Figure 4: To the 3-2-1 rule, add a copy that an infected PC cannot overwrite and a check that you can restore.

The backup vendor Veeam promotes this as the “3-2-1-1-0 rule”. In Veeam’s documentation, the additional “1” means keeping one copy that is offline, air-gapped or immutable, and the “0” means zero errors in regular restore verification¹⁰. This is a name from a vendor’s documentation, not an official standard. Still, the two additional items overlap with what CISA and IPA ask for.

Keep One Copy That an Infected PC Cannot Overwrite

There are two broad ways to make a copy that cannot be overwritten: disconnect the media from the PC and store it, or use cloud storage in which data cannot be overwritten or deleted for a set period. Whichever you choose, separate the permissions for managing backups from everyday work.

Disconnect the Media from the PC and Store It

As an example measure in its self-assessment, the IPA guidelines say to connect the devices and media used for backups to the PC only while taking a backup. They also list deciding how backups are taken, storing them in a safe place and regularly confirming that they can be restored¹¹.

For organizations taking it further, the guidelines list “physical isolation”. This means keeping backups in a place physically separate from the original system, storing external storage or backup tapes as far away as possible. Examples of storage locations include a bank safe-deposit box, or a trusted business partner or affiliated company¹².

A backup stored disconnected from the production systems like this is called an offline backup. An infected PC cannot write to disconnected media. On the other hand, people have to reconnect and carry the media, so backups get missed or the media is not taken off site. Decide who connects the media, disconnects it and takes it to the storage location, and when.

Use Cloud Storage That Cannot Be Overwritten

Cloud storage has features that prevent data from being overwritten or deleted for a set period. They store data in a state called WORM (Write Once, Read Many).

In Azure Blob Storage immutable storage, once you set a time-based retention policy, data can be created and read during that period but not modified or deleted¹³. A policy is first created in an unlocked state, and you lock it after testing. A locked policy cannot be deleted, and its retention period can be extended but not shortened¹³. Microsoft explains that even users with account administrator permissions cannot modify or delete the data¹³.

Amazon S3 Object Lock has two modes. In compliance mode, no one, including the AWS account’s root user, can overwrite or delete an object version during the retention period. In governance mode, only users with special permissions can change or remove the retention settings¹⁴. Object Lock can be used only in buckets with S3 Versioning enabled¹⁴.

flowchart TB
        accTitle: Two examples of storage that cannot be overwritten
        accDescr: A diagram showing that in Azure Blob Storage immutable storage a locked policy cannot be deleted and its retention period cannot be shortened, and that with S3 Object Lock even the root user cannot delete in compliance mode while special permissions allow changes in governance mode.
        W["Storage that cannot be overwritten"] --> AZ["Azure Blob Storage immutable storage"]
        W --> S3["S3 Object Lock"]
        AZ --> AZ1["Retention cannot be shortened after locking"]
        S3 --> C["Compliance mode"]
        S3 --> G["Governance mode"]
        C --> C1["Even the root user cannot delete"]
        G --> G1["Special permissions allow changes"]

Figure 5: Both kinds of storage refuse overwriting and deletion for a set period; how strictly depends on the settings.

In Azure, even if you notice a configuration mistake after locking a policy, you cannot shorten the retention period¹³. The CISA guide notes that some cloud providers offer storage that cannot be overwritten, and warns that misconfiguration can lead to significant costs. It also mentions that such storage may not meet the requirements of certain regulations⁴. If you set a long retention period and lock it, you cannot delete the data during that period, and storage charges keep accruing. Start with an unlocked state or a short period, confirm that you can restore, and then apply the production settings.

Separate the Permissions for Managing Backups

Even when you use storage that cannot be overwritten, if the backup settings and policies can be changed with the everyday administrator account, an attacker may change them. Microsoft recommends requiring an additional step, such as multifactor authentication or a security PIN, before online backups can be modified or deleted. It also lists limiting backup and restore operations to users in designated roles, and reducing the number of file shares where many users can write and delete⁵.

Even if the same person manages both the PCs and the backups, do not use the account for managing the backup destination for everyday PC sign-in, and protect it with multifactor authentication.

Keep Multiple Generations

The IPA guidelines list “generation management”, which means keeping backups from multiple points in time. It lets you go back to a specific point in time when data is damaged or lost¹². As described in an earlier section, if it takes time to notice the encryption, the most recent backups will contain data that is already encrypted. Decide how many generations to keep from how long it could take to notice the encryption and from the cost of storage.

flowchart TB
        accTitle: Three measures for keeping a copy that cannot be overwritten
        accDescr: A diagram showing storing disconnected media or using storage that cannot be overwritten, separating the permissions for managing backups from everyday accounts, and keeping multiple generations.
        A["A copy that cannot be overwritten"] --> B["Store disconnected media"]
        A --> C["Storage that cannot be overwritten"]
        B --> D["Separate management permissions"]
        C --> D
        D --> E["Keep multiple generations"]

Figure 6: After deciding where to keep it, separate the management permissions and keep generations so you can go back even if you notice late.

Confirm That You Can Restore

In the National Police Agency report, the second most common reason for not being able to restore was “operational failures”¹. You cannot know whether a backup can actually be restored until you try. The work of actually restoring from backup to confirm this is called a restore test.

The IPA guidelines divide backup operations into three parts: taking, storing and restoring. For restoring, they ask you to make a recovery plan and confirm that you can restore correctly³. For business-critical systems, they ask you to arrange how backups are taken and the procedures to match the recovery time objective (RTO) and recovery point objective (RPO), and to verify effectiveness through drills. RTO is the time it takes to restore to the target level, and RPO is the point in time you restore to, that is, the time of the most recent backup¹⁵. The CISA guide also asks organizations to regularly check that backups are usable and intact, with disaster recovery in mind⁴.

flowchart TB
        accTitle: How to run a restore test
        accDescr: A diagram showing the flow of deciding the restore order, restoring to a separate environment, comparing the time taken and the restored point with the RTO and RPO, and revising the runbook.
        A["Decide the restore order"] --> B["Restore to a separate environment"]
        B --> C["Compare the time taken with the RTO"]
        B --> D["Compare the restored point with the RPO"]
        C --> E["Revise the runbook"]
        D --> E
        E -.->|"Next check"| A

Figure 7: Try restoring, check whether the time and the point meet the targets, and feed the results back into the runbook.

What to Check

Based on the IPA and Microsoft documentation, what to check can be organized as follows.

Microsoft recommends first identifying the systems that are critical to the business and backing them up regularly. The resulting prioritized list of backups becomes the restore order as it is. As a high priority, it lists first the authentication systems, such as Active Directory, needed to get into every other system⁵. It also recommends regular drills of bringing the business back up from a state where every system is down. In those drills, assume that email and chat are unavailable too⁵.

Microsoft writes that attackers deliberately target restore runbooks and network diagrams. It recommends protecting them or keeping printed copies at hand⁵. If the runbook exists only on the file server, you cannot read it when that file server is encrypted.

Cautions When Restoring After an Attack

After an actual attack, remove the ransomware itself from the environment before restoring⁵. Microsoft lists choosing a backup from a point in time known to be uninfected, and scanning the backup for malware before restoring⁵. The National Police Agency report says ransomware groups sometimes install remotely controllable software as a backdoor so they can get back in even after the entry point is closed². Before restoring, you need to investigate the intrusion path and anything the attackers left behind.

flowchart TB
        accTitle: The order for restoring from backup after an attack
        accDescr: A diagram showing removing the ransomware itself and the intrusion path, choosing a backup from an uninfected point in time, scanning it for malware, and then restoring the highest-priority systems first.
        A["Remove the ransomware itself"] --> B["Investigate the intrusion path and leftovers"]
        B --> C["Choose an uninfected point in time"]
        C --> D["Scan the backup"]
        D --> E["Restore the highest priority first"]

Figure 8: After an attack, remove what the attackers left behind and confirm an uninfected point in time before restoring.

How Often to Check

Both the IPA guidelines and the CISA guide ask you to confirm “regularly” that you can restore, but they give no number¹¹⁴. The company in the IPA case introduced earlier held restore drills twice a year³. Decide how long your business can be down and how old the restored point may be, and check at a frequency that lets you confirm you are meeting them.

What to Decide First

The content so far can be summarized as what an SME should decide first.

flowchart TB
        accTitle: The order for deciding on ransomware-resilient backups
        accDescr: A diagram showing the order of deciding the scope, deciding where to keep copies and the copy that cannot be overwritten, deciding permissions and generations, deciding the RTO and RPO, and confirming that you can restore.
        A["Decide the scope"] --> B["Decide where to keep copies"]
        B --> C["Decide the copy that cannot be overwritten"]
        C --> D["Decide permissions and generations"]
        D --> E["Decide the RTO and RPO"]
        E --> F["Confirm that you can restore"]

Figure 9: Decide everything in one sequence, from the scope through to the final check that you can restore.

In the 4th edition of the IPA guidelines, “Take backups!” was added to the “5 Information Security Rules” that organizations start with, making them 6 rules¹⁶. How to work through the guidelines as a whole is summarized in “Where Should SMEs Start on Security?”. If you plan to replace servers, also see “Preparing for Windows Server 2016 End of Support”.

Related Articles

• Where Should SMEs Start on Security? — A Walkthrough of IPA’s ‘Information Security Guidelines for SMEs,’ 4th Edition
• Volume Shadow Copy (VSS): The Mechanism and the Practice — Why Backup Software Can Copy Files That Are Still in Use
• Preparing for Windows Server 2016 End of Support

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These are topic pages close to this theme. Starting from the article, you can go on to related services and other articles.

Services Connected to This Topic

This article leads to the following service pages. Start from the entry point closest to your situation.

Frequently Asked Questions

Questions commonly asked at the time of consultation about the topic of this article.

If I take backups, can I restore everything after a ransomware infection?

Often, just taking backups is not enough to restore. In the damage compiled by Japan's National Police Agency for the first half of 2025, 41 of the 48 organizations that took backups and answered could not restore to the level just before the attack. The most common reason was that the backups had been encrypted too. You need a copy that an infected PC cannot overwrite, and you need to confirm that you can restore from it.

If Windows has Previous Versions, do I still need backups?

Yes. Previous Versions are volume shadow copies, which are differences kept on the original volume. Microsoft treats data copied from a shadow copy to media such as tape as the backup. Ransomware sometimes deletes shadow copies with tools such as vssadmin, so combine them with backups on separate media.

Is following the 3-2-1 rule enough to protect against ransomware?

Sometimes it is not. The 3-2-1 rule asks for three copies, two kinds of media and one copy kept off site, but it does not require the off-site copy to be offline or immutable. A cloud copy that an infected PC can always write to may be encrypted in the same way. Add one copy on offline media or in storage that cannot be overwritten.

How often should I check that I can restore from backups?

Both the IPA guidelines and the CISA guide say "regularly" and give no number. The IPA guidelines include a case in which a company that held restore drills twice a year brought its core systems back five days after discovering the attack. Decide how long your business can be down and how old the restored point may be, and check at a frequency that lets you confirm you can meet them.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and bug investigation, with particular strength in projects where existing assets remain and in investigating failures whose cause is hard to see.