For: anyone in solo or small-team work who keeps "some kind of backup" but wonders "is this actually enough?" No attack steps here — just how to build a backup you can reliably restore from.
This site's view: 'cloud sync' is not a backup
A common assumption is "I sync to OneDrive/Google Drive, so I'm backed up." Not so. Sync replicates the current state, so a file you delete by mistake, or one ransomware encrypts, gets copied to the other side in that state.
A backup needs the ability to go back to an earlier state: versioning that restores an older copy, and an immutable copy that can't be overwritten later. Sync is convenient, but on its own, when one side breaks, both break. Treat it as a different role from backup entirely.
Why "I have a backup" isn't enough
You need backups because the causes of data loss are many — and they arrive together. Hardware failure, deletion by mistake, theft and disaster, and ransomware. One line of defense misses the accidents coming from another direction.
Ransomware in particular searches for the backups themselves and encrypts them. A backup kept in the same place as the data is damaged in the same incident. This is the most basic form of "keep a restorable state" from vulnerability response (→ the practice of vulnerability response).
The basic shape: 3-2-1 (+ offline/immutable)
3 — three copies
original plus two. One fails, the other two still restore.
2 — two media types
e.g. internal drive + external SSD, or NAS + cloud. Don't pool them in one box.
1 — one offsite
another location (cloud / separate site). Fire, theft, flood won't wipe it all.
+ one offline/immutable
not always connected, or non-overwritable. Always keep one copy ransomware can't encrypt.
How to build it (fill it in order)
First, inventory 'what would hurt to lose'
Lay it out as 3-2-1
Make at least one offline/immutable
Automate it (manual won't last)
Restore-test on a schedule
Ransomware targets backups too
Modern ransomware encrypts not just the main data but any connected backup target it can find (NAS, external drives, mounted cloud). So if all you have is an always-connected backup, it gets encrypted along with everything else.
The most effective defense is keeping at least one copy that's offline (physically disconnected) or immutable (overwrite/delete forbidden for a period). Whether you have that copy is what separates paying the ransom from not.
Cloud sync only
- deletions and encryption are synced as-is
- can't roll back to an older version
- always connected = encrypted by ransomware too
- you've never checked whether it restores
3-2-1 + immutable + restore test
- versioning restores a clean older copy
- an offline/immutable copy isolated from ransomware
- redundancy across place and media means no total loss
- periodic tests confirm it really restores
By environment: what's built in, and what to add
For each common environment: the built-in mechanism, whether it can roll back to older versions, and what to add for ransomware.
| Environment | Built-in mechanism | Can you roll back to older versions? | What to add |
|---|---|---|---|
| Windows | File History (saves to an external drive or a network location) | Yes ("Restore previous versions" in File Explorer) | Unplug the target drive when the backup is done. Put a second copy somewhere else |
| Windows (Windows Backup app) | Syncs folders such as Desktop and Documents to OneDrive | Depends on OneDrive's features | It is sync underneath, so keep File History or an external copy as well |
| Mac | Time Machine | Yes (hourly for the past 24 hours, daily for the past month, weekly before that) | Keep a second backup disk in another place and swap them now and then |
| iPhone | iCloud Backup (automatic while on power, on Wi-Fi, and locked) | Built to restore the whole device | Also keep important photos and documents on a computer or external drive |
| OneDrive | Sync | Microsoft 365 subscribers can use "Restore your OneDrive" to go back to a point within the last 30 days | One offline copy, separate from sync |
| Google Drive | Sync | Non-Google files can be rolled back via "Manage versions"; older versions may be deleted after 30 days or once there are 100 newer versions | Use "Keep forever" on versions you need, plus one offline copy |
| Server / VPS | A backup tool (restic, etc.) and a separate destination | Yes, from the tool's snapshots | Make the destination impossible to delete from the production server (S3 Object Lock, etc.) |
| Shared web hosting | The provider's automatic backups | Only within the provider's retention period | Regularly copy your data out of the provider too (to your machine or a cloud) |
The "What to add" column is the work of filling in the rest of 3-2-1. Almost no environment gets you 3-2-1 plus an offline copy with the built-in mechanism alone.
How to check your own setup
To get rid of "I think it's backing up," check the following in order. Each step only looks at settings on your own devices and accounts.
See when the last backup succeeded
- Windows: open "File History" in Control Panel and check that it's on, which drive it uses, and when files were last copied.
- Mac: check the latest backup time under System Settings → General → Time Machine. In Terminal,
tmutil latestbackupshows the latest backup andtmutil destinationinfoshows the destination (on some setups Terminal needs Full Disk Access). - iPhone: Settings → your name → iCloud → iCloud Backup shows the date and time of the last backup.
- Server: with restic,
restic snapshotslists snapshots with their dates.
If the date stopped days ago, that is the first thing to fix.
Check that the destination isn't always connected
Check whether your external drive or NAS stays plugged in and visible as a drive all the time. On a server, check in the permission settings that the credentials stored on the production server can't also delete the backups. With S3, also check whether Object Lock is enabled on the destination bucket.
Check that the cloud can roll back
For OneDrive, see whether "Restore your OneDrive" appears under Settings → Options (for Microsoft 365 subscribers). For Google Drive, right-click a file and see whether "Manage versions" lists older versions. Both have retention limits, so you need another way to go back further.
Actually restore one thing (the restore test)
Pick one important file and restore it to a different location, then open it. On Windows, right-click the folder and choose "Restore previous versions"; on a Mac, restore from Time Machine. On a server, restore into a different directory and inspect it; with restic, something like restic check --read-data-subset=5% reads back part of the stored data to verify it. For a database, restore into a separate database and confirm it starts.
Record the result and how long it took
Note the date, what you restored, and how long it took. It tells you roughly how many hours a full restore would take, and you'll notice changes at the next test.
Common mistakes and how to fix them
- Leaving the external drive plugged in: to ransomware, a connected drive is just another place to encrypt. Unplug it after each backup, or rotate two drives so one is always disconnected.
- Treating sync as backup: the Windows Backup app's folder backup is OneDrive sync underneath. Keep a separate backup that holds older versions.
- Using the same password for the backup console as for production: if production is taken over, the backups get deleted too. Use a different password and turn on multi-factor authentication.
- Not watching for failure alerts: a stopped backup goes unnoticed. Turn on failure notifications and check the last backup time once a month.
- Keeping what you need to restore only inside the backup: store the encryption password and recovery keys somewhere separate from the backup (→ choosing a password manager).
- Making an offline copy once and never again: you can only restore to the point when that copy was made. Refresh it on a fixed schedule, such as monthly.
A public case: what survived was an old disconnected copy
The expert panel report (published June 2022) on the ransomware attack that hit Tsurugi Town Handa Hospital in October 2021 says the following about backups:
- The backup server was on the list of servers confirmed to be encrypted
- Backup data that had been kept offline up to 2018 was not affected and could be used for recovery
- Normal outpatient care resumed on January 4, 2022, about two months after the attack
The connected backup was hit along with production; the disconnected copy survived. But that copy was several years old. An offline copy only helps fully if you refresh it regularly, so the point you can restore to stays recent.
What this site does itself
This site takes its data and documents automatically, to a separate location, across multiple generations, and pairs that with a "rebuildable by design where possible" approach. Data that can be regenerated mechanically (ingested feeds, indexes), for instance, is held on the assumption it can be rebuilt rather than relying on backups — a way of "reducing the backup burden in the first place." On top of that, the irreplaceable things (article bodies, configuration) are kept redundantly, and keeping a restorable state at all times is a premise of operations.
When swapping out end-of-support hardware (→ the Windows 10 end-of-support piece), the reason you can migrate with confidence is that a restorable backup exists. Think of backup not only as something for when every other control has failed, but as a precondition for incident response.
Read next
- Basics: the security baseline checklist (Tier 3 = detection, recovery)
- In practice: the practice of vulnerability response (keep a restorable state)
- Related: Windows 10 end-of-support risks and migration
- Storage: storing passwords and secrets safely
- Case: the KADOKAWA / Niconico ransomware (2024) (months of downtime — the business-continuity lesson)
- Case: the Osaka Metropolitan University ransomware attack (2026) (a virtualization platform outage, with backups reported encrypted)
- Case: Rank Math PRO 3.0.123 shipped with malware (2026) (restoring a backup from before the affected window was the recommended recovery)
- When the provider is breached: what to do when your web host is compromised (why the only backup must not live inside that provider)
Sources
- CISA et al., "#StopRansomware Guide" (keep offline, encrypted backups and test restores regularly): cisa.gov
- Tsurugi Town Handa Hospital, expert panel investigation report on the computer virus incident (June 2022, Japanese): handa-hospital.jp
- Microsoft Support, "Backup and restore with File History": support.microsoft.com
- Microsoft Support, "Back up your folders with OneDrive": support.microsoft.com
- Microsoft Support, "Restore your OneDrive": support.microsoft.com
- Google Drive Help, "Check activity & file versions": support.google.com
- Apple Support, "Back up your Mac with Time Machine": support.apple.com
- Apple Support, "How to back up your iPhone with iCloud": support.apple.com
- AWS documentation, "Locking objects with Object Lock": docs.aws.amazon.com
- restic documentation, "Working with repositories" (snapshots / check): restic.readthedocs.io