System Rollback Is Not a Backup: Disaster Recovery on Windows, macOS, and Linux

Every modern desktop operating system now ships a built-in “restore” feature that can rewind the machine to an earlier state. They are genuinely useful — and they are routinely mistaken for backups.

This guide draws a hard line between two things that look similar and solve completely different problems.

Problem

Two very different disasters get lumped together under the word “recovery”:

• A bad change. A cumulative update breaks a driver, a config edit takes down the desktop, an app install corrupts a system component, or a new package breaks the boot. The hardware is fine; you just need to get the machine back to how it was yesterday.
• A lost device. The disk dies, the laptop is stolen, or ransomware encrypts everything in place. The data itself is gone from the machine — and any “restore point” that lived on that same disk is gone with it.

The native rollback tools are excellent at the first problem and useless against the second. Treating them as your backup strategy is one of the most common — and most expensive — mistakes in personal and small-business IT.

Why it happens

The confusion is understandable. The tools are built in, they are labelled with words like “restore” and “recovery,” and they quietly capture snapshots in the background. It feels like your data is safe.

But three details get lost:

1. Most snapshots live on the same disk they protect. A point-in-time snapshot is worthless when the sector it lives on has failed, or when ransomware has encrypted the whole volume. Protection against hardware loss requires a copy on different hardware.
2. The tools disagree about what “the system” even includes. Some snapshot your personal files along with the OS; others deliberately leave your documents out. If you do not know which, you can lose data during a restore.
3. A snapshot is not versioned off-site history. Backups are about keeping independent, restorable copies over time, ideally somewhere the live machine cannot reach. Rollback is about undoing a recent change on the same machine.

The clean way to think about it is two layers.

Solution: think in two layers

Layer 1 — system rollback. Recover from a bad update or a broken config. Fast, local, built in. This is what Windows Point-in-Time Restore, macOS Time Machine’s local snapshots, and Linux Timeshift are for.

Layer 2 — real off-device backup. Recover from disk failure, theft, or ransomware. A separate, versioned copy of your data on different hardware (or off-site). This is non-negotiable, and Layer 1 does not provide it.

The rest of this section walks each operating system’s Layer 1 tool, then states plainly what you still need for Layer 2. macOS is the interesting exception, because its Layer 1 tool is a Layer 2 backup.

Windows — Point-in-Time Restore (PITR)

Point-in-Time Restore is Windows 11’s built-in Layer 1 tool, and for IT pros it is the most significant of the three because it is new, on by default for a huge install base, and behaves differently from what came before.

It is generally available today. PITR shipped in the cumulative update KB5095093 on 23 June 2026. This is not a preview, an Insider feature, or something on a roadmap — on a patched Windows 11 machine it is a shipping feature right now.

How it works. PITR is built on the Volume Shadow Copy Service (VSS), the same shadow-copy plumbing Windows has used for years, wrapped in a new recovery experience. Restore points are created automatically and can be applied without reinstalling Windows.

What it captures — the important part. A PITR snapshot includes the OS, installed applications, and settings and your local user files. This is a deliberate design decision, and it is the opposite of what Linux’s Timeshift does (more on that below). It means a PITR restore rolls your documents back too — helpful for undoing damage, but something you must understand before you trigger one.

Default behaviour (unmanaged Home/Pro):

• Roughly one restore point every 24 hours.
• 72-hour retention — you can rewind within about the last three days, not three months.
• A disk-space cap of about 2% of the volume.
• On by default on unmanaged Home and Pro devices whose OS volume is 200 GB or larger.

On managed devices, PITR is off by default on enterprise-managed endpoints until Windows 11 26H2. If you administer a fleet, do not assume it is protecting your users yet — you will need to enable and configure it.

How you actually use it. Today PITR is triggered locally:

• From the Windows Recovery Environment (WinRE): Troubleshoot → Point-in-time restore.
• Configuration lives at Settings → System → Recovery → Point-in-time restore.

The admin limitation to know about. Remote / Intune-triggered restore is planned but not yet available. As of now PITR is a local-only tool: someone has to be at the machine, in WinRE, to restore it. That significantly limits its usefulness for fleet or help-desk recovery today — you cannot yet push a rollback to a remote device. It is worth tracking the Intune trajectory, because remote-trigger is what will make PITR genuinely useful at scale.

Known quirk. After a restore you may hit an Outlook .ost mismatch — the cached mailbox file no longer lines up with the restored state. It is recoverable (Outlook can rebuild the cache), but expect it and warn users.

Layer 2 for Windows: PITR is not a replacement for an image or off-device backup. Its snapshots live on the machine and rewind only ~72 hours. For hardware failure, theft, or ransomware you still need a dedicated, versioned backup on separate storage — a disk-imaging tool and/or File History / a third-party backup to an external or network drive or cloud.

macOS — Time Machine (the odd one out)

macOS is the exception among the three, because its headline recovery tool already spans both layers.

Time Machine is a genuine versioned backup to a separate external or network drive. Because the copies live on other hardware, it covers hardware loss — disk failure and, if the drive is kept elsewhere, theft. That is real Layer 2 protection, which neither PITR nor Timeshift provides on its own.

It also does Layer 1. Time Machine keeps local snapshots on the internal disk between backups, so you get fast, on-device rollback for recent changes without reaching for the external drive — the same quick-undo role PITR and Timeshift play elsewhere.

Layer 2 for macOS: largely handled, provided the destination drive is genuinely separate and ideally rotated or kept off-site. Time Machine to a disk that never leaves the desk still falls to fire or theft, so treat off-site rotation (or an additional cloud backup) as the finishing touch rather than an optional extra.

Linux — Timeshift

Timeshift is the popular Layer 1 tool on Linux, and its design philosophy is the mirror image of Windows PITR.

It snapshots system state. Timeshift captures the operating system — system files and configuration — so you can roll back a bad update or a broken config change and get back to a working system.

It excludes /home by default — on purpose. Timeshift deliberately leaves your personal files (everything under /home) out of its snapshots. This is a core design choice: it is a system-restore tool, not a document time machine. That is the exact opposite of PITR, which deliberately includes user data.

Store it on a separate disk or partition. Timeshift can save its snapshots to a separate disk or partition, and this is strongly recommended: a snapshot on the same disk as the system disappears when that disk fails. Putting snapshots on separate storage means your rollback history survives a system-disk failure.

Layer 2 for Linux: Timeshift is explicitly not a data-backup tool. Because it excludes /home by design, your actual documents, photos, and projects are not in it at all. Pair Timeshift with a real, versioned backup tool for personal data — for example Back In Time, restic, or Déjà Dup — targeting separate or off-site storage.

The neat contrast: PITR includes user data, Timeshift excludes it

It is worth pausing on this, because it captures the whole “rollback vs backup” distinction in a single comparison. Two tools set out to solve the same problem — roll the machine back to an earlier state — and made opposite decisions about your personal files:

Neither choice is wrong — they reflect different philosophies. But it means you must know your tool’s behaviour before you restore. On Windows, a rollback also rewinds your documents. On Linux, a rollback leaves your documents untouched (and a misconfigured one can delete them). In both cases, the safety of your actual data depends on a separate Layer 2 backup — not on the rollback tool.

Extra tips

• Apply the 3-2-1 rule for Layer 2. Keep 3 copies of important data, on 2 different media, with 1 off-site. Rollback snapshots do not count toward this — they are not independent copies.
• Test your restores. A backup you have never restored from is a hypothesis, not a safety net. Periodically restore a file (and, occasionally, a whole machine) to confirm it works.
• Keep at least one backup offline or immutable. Ransomware encrypts everything it can reach, including mounted backup drives and some cloud sync folders. An offline drive or versioned/immutable cloud backup is what survives it.
• Put snapshots on separate storage where the tool allows it. Timeshift on a second disk, Time Machine on an external/network drive. Same-disk snapshots die with the disk.
• Mind retention windows. Windows PITR only reaches back ~72 hours by default; if you need to recover something from last month, only a real backup will have it. Check and, where possible, raise retention/disk caps to match your needs.
• Windows admins: track the Intune trajectory. PITR is local-only today. Until remote-triggered restore ships, plan on someone being physically at the device (in WinRE) to use it, and keep your existing imaging/backup process for remote recovery.
• After a Windows PITR restore, expect the Outlook .ost mismatch. Let Outlook rebuild its cached mailbox, or recreate the cached-mode profile, and warn users so it does not look like data loss.
• Verify PITR is actually on for your scenario. It is on by default only on unmanaged Home/Pro devices with a ≥200 GB OS volume; enterprise-managed devices have it off until 26H2. Check Settings → System → Recovery → Point-in-time restore.
• Don’t include /home in Timeshift — repeated here because it is the single most damaging Linux misconfiguration in this area.

Related

• Setting up a 3-2-1 backup that actually survives ransomware — (coming soon)
• Windows 11 Point-in-Time Restore: full admin configuration walkthrough — (coming soon)
• Choosing a Linux backup tool: Back In Time vs restic vs Déjà Dup — (coming soon)
• Verifying and test-restoring your backups — (coming soon)