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

TL;DR

Your computer’s built-in “restore” feature (Windows Point-in-Time Restore, macOS Time Machine’s local snapshots, Linux Timeshift) can rewind a bad update or a broken setting. That is genuinely useful, but a rollback on its own is not a backup. If the drive dies, the laptop is stolen, or ransomware locks your files, a rewind cannot save you, because the safety copy lived on the same machine. Time Machine is the one that spans both, and the bullets below explain why.

• Think in two layers: a quick “undo” (rollback) for bad changes, and a real backup (a separate copy of your data) for when the whole device is lost.
• They are not the same thing. Do not treat the restore feature as your backup.
• Keep a genuine backup on a different drive or the cloud (aim for the 3-2-1 rule: 3 copies, 2 types of media, 1 off-site).
• On a Mac, Time Machine already does both jobs if the backup drive is kept separate. On Windows and Linux you still need to add a proper backup tool.

Now for the more technical explanation

Every modern desktop operating system has a “restore” feature that can rewind the machine to an earlier state: it is built into Windows and macOS, and a quick install away on Linux. They are genuinely useful, and they are also 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 right there (built into Windows and macOS, a quick install on Linux), 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 and local. 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, rolling out on-by-default to a huge install base, and behaves differently from what came before.

It is shipping, and now generally available. PITR first appeared as a preview in the June 2026 optional update (KB5095093, 23 June), and reached general availability with the July 2026 update (KB5101650). It is a real, shipping feature, not an Insider-only or roadmap item. Rollout to individual machines is still staged, though, so check whether yours has it before relying on it.

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, and no more than 50 GB whatever the drive size.
• On by default on unmanaged Home and Pro devices whose OS volume is 200 GB or larger, once the staged rollout has reached the device.

Retention is configurable on Enterprise. The 72 hours above is the default, not the ceiling of what the feature can do. Windows 11 Enterprise lets you set it to 4, 6, 12, 16, 24 or 72 hours, so the tuning available to admins is about making the window shorter (to save disk) rather than longer. If you were hoping to stretch it to a fortnight, you cannot; that is what a real backup is for.

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, or 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. Those local snapshots have their own quirks on a laptop, how often they are made, how you restore from them, and how macOS thins them when the disk fills, all covered in the MacBook local-snapshots guide.

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 is usually something you install, not a default. This is the important caveat: unlike PITR on Windows or Time Machine on macOS, Timeshift is not part of the base system on most distributions. A few, notably Linux Mint, ship it and prompt you to set it up. But on most (Ubuntu, Fedora, Debian, Arch, and others) you install it yourself (sudo apt install timeshift, sudo dnf install timeshift, and so on), and even then it does nothing until you choose the snapshot type, schedule, and storage location. So on Linux, Layer 1 is opt-in: there is no rollback safety net until you deliberately set one up.

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. You can change that when you first set it up, because Timeshift offers to include the home folder for your user account and for root. You are still better off leaving it alone and pairing Timeshift with a real, versioned backup tool for personal data: Back In Time, restic, or Déjà Dup, targeting separate or off-site storage. A cloud sync tool like Dropbox covers some of the same ground, though whether file sync counts as a backup at all is a larger debate.

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. Rollout is staged (preview in June 2026, generally available with the July 2026 update), and 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

• File sync is not a backup: Dropbox, OneDrive and Google Drive
• Backing up a MacBook: Time Machine’s local snapshots explained
• Full-disk encryption: encrypt before you ever need recovery
• Data destruction: wiping, shredding, and what actually counts as secure

Written by Tom Langston, IT Infrastructure and Cybersecurity.