Restore Points Are Missing: The Setting Windows Keeps Turning Off

What’s actually happening when restore points “disappear”

Windows restore points are built on top of Volume Shadow Copy Service (VSS). System Restore (the feature you interact with) is basically a consumer of VSS snapshots plus a bundle of system-state tracking: registry hives, certain system files, drivers, and configuration metadata. It’s not a full system backup, it’s not a “disk image,” and it’s definitely not a time machine that laughs at ransomware.

So why do restore points vanish?

• System Protection is actually Off for the system drive, often after an OS upgrade, policy application, or “optimization.”
• Disk space quota is too small. Restore points are stored in the “shadow storage” area. When it fills up, Windows deletes older points. If the quota is tiny, you get a revolving door: restore points are created and immediately evicted.
• VSS is unhealthy (writers stuck, services disabled, provider errors). Restore points fail silently or leave behind nothing usable.
• Cleanup tools purge them: Disk Cleanup, Storage Sense, third-party “cleaners,” some OEM maintenance suites.
• Shadow copies get deleted by administrative actions (including scripts), or by certain update/feature upgrade workflows.

What makes this infuriating is that Windows can look fine until you need the rollback. Restore points are like fire extinguishers: nobody budgets for them until the kitchen is on fire.

One quote to keep us honest: “Hope is not a strategy.” — General Gordon R. Sullivan. Operations people didn’t invent that line, but we tattooed it onto our souls.

Also, here’s your first joke: System Restore is the parachute you only notice after you’ve already jumped.

Interesting facts and historical context (yes, it matters)

1. System Restore debuted in Windows ME (2000) and then became mainstream in Windows XP. It was controversial because early versions could bloat disk usage and sometimes restored malware along with the system.
2. VSS arrived with Windows XP/Server 2003 era infrastructure and became a standard plumbing layer for backups, restore points, and file-level “Previous Versions.”
3. Restore points are not the same as “Previous Versions” even though both use shadow copies. Previous Versions depends on shadow copies existing for files; System Restore depends on protection being enabled and the OS deciding what to track.
4. Windows feature upgrades (major version jumps) commonly reset or disable protection settings on some systems, especially when disk layouts change or “system” volume identification gets fuzzy.
5. Shadow storage is per volume, and it can be located on a different volume. That’s powerful—and also a source of “I enabled it on C: but why are snapshots gone?” confusion.
6. VSS uses “writers” (components that prepare data for snapshot). When writers get stuck, you can still have a functioning PC that refuses to snapshot reliably.
7. Some enterprise images intentionally disable System Restore to reduce support variance or because they rely on full imaging/MDM rollback. If that policy leaks into unmanaged machines, you get a surprise.
8. Disk Cleanup historically had options that can remove restore points (keeping only the most recent). People click “Clean up system files” like it’s free money.
9. System Restore does not protect user files in the way users assume. It’s meant for system state recovery, not recovering your report you overwrote at 2 a.m.

Fast diagnosis playbook

This is the “don’t boil the ocean” sequence. Follow it in order. It finds the bottleneck quickly and avoids chasing ghosts.

1) Confirm System Protection status for the OS volume

If it’s Off, everything else is a side quest. Turn it On and set a sane quota.

2) Check shadow storage quota and current usage

If max size is tiny or set to 0/“unbounded but effectively starved,” restore points will churn or vanish.

3) Check VSS health (writers + services)

Writers in error state or disabled services mean snapshots won’t be created even if the UI says it should work.

4) Look for deletion behavior: cleanup, policy, scripts

Storage Sense, cleanup tasks, “optimizer” tools, and some enterprise scripts routinely delete shadow copies to reclaim space.

5) Correlate with events

VSS and System Restore log their complaints. The event log is where Windows admits what it did.

Practical tasks: commands, outputs, and decisions (12+)

These are the tasks I actually run. Each one includes: command, example output, what it means, and what you do next.

Task 1 — List existing restore points (if any)

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerRestorePoint | Select-Object SequenceNumber, Description, CreationTime | Format-Table -Auto"
SequenceNumber Description                     CreationTime
-------------- -----------                     ------------
           132 Windows Update                  1/31/2026 2:14:07 AM
           131 Installed NVIDIA Graphics Driver 1/30/2026 6:02:33 PM

What it means: If this returns rows, System Restore has at least some metadata. If it errors (“Cannot find path” or “System Restore is disabled”), that’s a clue.

Decision: No restore points listed? Move to System Protection and VSS checks. Some systems have VSS snapshots without SR restore points; don’t assume they’re equivalent.

Task 2 — Check whether System Restore is disabled via registry policy keys

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore' -ErrorAction SilentlyContinue | Format-List"
DisableConfig : 1
DisableSR     : 1
PSPath        : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore

What it means: DisableSR=1 means System Restore is being disabled by policy. This is common in domain-joined environments or after “hardening” scripts.

Decision: If these exist, you don’t “fix” it in the UI. You fix policy (GPO/MDM/baseline) or remove the key if appropriate and allowed.

Task 3 — Check System Protection configuration via WMI (quick sanity check)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -Namespace root/default -ClassName SystemRestoreConfig | Select-Object -Property * | Format-List"
RPLifeInterval : 7776000
DiskPercent    : 3
PSComputerName :

What it means: This shows System Restore config, like disk percent reserved. DiskPercent being very low is a red flag on modern systems.

Decision: If DiskPercent is 1–3% on a busy workstation, bump it. If the class doesn’t return data, SR might be disabled or broken.

Task 4 — List shadow copies present (VSS snapshots)

cr0x@server:~$ vssadmin list shadows
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2013 Microsoft Corp.

Contents of shadow copy set ID: {6f5d1fe9-8d8d-4f1c-9b3a-6efaf7fadc1b}
   Contained 1 shadow copies at creation time: 2/3/2026 9:12:21 AM
      Shadow Copy ID: {c5e65b1e-0cbd-4f2d-96c2-4a0b9a3d6d62}
         Original Volume: (C:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy12
         Originating Machine: DESKTOP-OPS1
         Service Machine: DESKTOP-OPS1
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessible
         Attributes: Persistent, Client-accessible, No auto release, Differential

What it means: If shadows exist but restore points don’t, you might have VSS used by backup/Previous Versions but System Restore disabled. Or restore point metadata is missing.

Decision: If there are no shadows at all, you either aren’t creating them, they’re being deleted, or VSS is failing. Proceed to storage/quota and VSS writer checks.

Task 5 — Inspect shadow storage usage and quota (this one explains “vanishing”)

cr0x@server:~$ vssadmin list shadowstorage
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2013 Microsoft Corp.

Shadow Copy Storage association
   For volume: (C:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
   Shadow Copy Storage volume: (C:)\\?\Volume{11111111-2222-3333-4444-555555555555}\
   Used Shadow Copy Storage space: 1.421 GB (1%)
   Allocated Shadow Copy Storage space: 1.500 GB (1%)
   Maximum Shadow Copy Storage space: 1.500 GB (1%)

What it means: Max size is 1.5GB. That’s nothing on a modern Windows install. A single update can churn that.

Decision: Increase quota. If you can’t spare the space on C:, consider relocating shadow storage to another volume (carefully).

Task 6 — Increase shadow storage quota to a sane value

cr0x@server:~$ vssadmin resize shadowstorage /for=C: /on=C: /maxsize=15GB
Successfully resized the shadow copy storage association.

What it means: You’ve given VSS room to keep multiple restore points.

Decision: If disk is small (e.g., 128GB), choose proportionally (8–12GB). If endpoints are large and you rely on SR, 15–30GB is reasonable.

Task 7 — Verify VSS services are running and not disabled

cr0x@server:~$ powershell -NoProfile -Command "Get-Service VSS,swprv | Select-Object Name,Status,StartType | Format-Table -Auto"
Name  Status  StartType
----  ------  ---------
VSS   Running Manual
swprv Stopped Manual

What it means: VSS is running. The Microsoft Software Shadow Copy Provider (swprv) is Manual and stopped, which is normal until needed.

Decision: If either is Disabled, that’s a problem. Set to Manual, start VSS, and re-test restore point creation.

Task 8 — Check VSS writers health (the “why is it failing?” detector)

cr0x@server:~$ vssadmin list writers
Writer name: 'System Writer'
   Writer Id: {e8132975-6f93-4464-a53e-1050253ae220}
   Writer Instance Id: {5d1aa4f8-8b6c-4a35-8571-34a13b2bfc4d}
   State: [1] Stable
   Last error: No error

Writer name: 'WMI Writer'
   Writer Id: {a6ad56c2-b509-4e6c-bb19-49d8f43532f0}
   Writer Instance Id: {0d54d70a-7f44-4af6-8a0f-778a85b54d1c}
   State: [9] Failed
   Last error: Timed out

What it means: One writer is failed. Restore points can fail or be incomplete when critical writers are broken.

Decision: Fix the underlying service for that writer (often WMI repository issues, provider timeouts, or dependent services). At minimum, restart services and re-check. If it stays failed, you’re not “done” just because the UI says “On.”

Task 9 — Look at System Restore and VSS events (stop guessing)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='VSS'; StartTime=(Get-Date).AddDays(-7)} | Select-Object TimeCreated,Id,LevelDisplayName,Message | Select-Object -First 5 | Format-List"
TimeCreated      : 1/31/2026 2:14:10 AM
Id               : 8193
LevelDisplayName : Error
Message          : Volume Shadow Copy Service error: Unexpected error calling routine CoCreateInstance.  Error: [0x80040154]

TimeCreated      : 1/31/2026 2:14:08 AM
Id               : 12289
LevelDisplayName : Error
Message          : Volume Shadow Copy Service error: Error calling a routine on a Shadow Copy Provider.

What it means: 0x80040154 is “Class not registered” in COM terms. That often points to a broken provider registration or corrupted components.

Decision: If you see repeated VSS provider errors, don’t just enlarge quotas. Repair the VSS stack (component store checks, provider cleanup) and consider removing third-party providers if present.

Task 10 — Create a restore point manually and observe errors

cr0x@server:~$ powershell -NoProfile -Command "Checkpoint-Computer -Description 'Manual restore point for testing' -RestorePointType 'MODIFY_SETTINGS'"

What it means: No output usually means success. If it throws an exception (“System Restore is disabled” or “The restore point could not be created”), you have a direct failure signal.

Decision: If manual creation fails, you’re dealing with configuration/policy/VSS health, not “Windows forgot.” Go back to writers, services, and policy keys.

Task 11 — Check scheduled tasks that influence restore point creation

cr0x@server:~$ schtasks /Query /TN "\Microsoft\Windows\SystemRestore\SR" /V /FO LIST
Folder: \Microsoft\Windows\SystemRestore
HostName:                             DESKTOP-OPS1
TaskName:                             \Microsoft\Windows\SystemRestore\SR
Next Run Time:                        2/4/2026 12:00:00 AM
Status:                               Ready
Logon Mode:                           Interactive/Background
Last Run Time:                        2/3/2026 12:00:00 AM
Last Result:                          0x0
Author:                               Microsoft Corporation
Task To Run:                          %windir%\system32\rundll32.exe /d srrstr.dll,ExecuteScheduledSPPCreation

What it means: Task exists and last result is 0x0 (success). If it’s missing or failing, scheduled creation may not happen.

Decision: If missing, you can still create restore points manually, but automatic behavior is broken. If failing, investigate task history and event logs for why.

Task 12 — Check free space and whether C: is under pressure

cr0x@server:~$ powershell -NoProfile -Command "Get-PSDrive C | Select-Object Name,Free,Used | Format-List"
Name : C
Free : 6829434880
Used : 243915735040

What it means: About 6.8GB free. That’s “one Windows cumulative update away from a bad day.” Low free space triggers aggressive cleanup and snapshot eviction.

Decision: If free space is tight, fix that first: grow the partition, uninstall bloat, move data, or change retention strategy. No space, no snapshots.

Task 13 — Identify third-party VSS providers (frequent source of weirdness)

cr0x@server:~$ vssadmin list providers
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2013 Microsoft Corp.

Provider name: 'Microsoft Software Shadow Copy provider 1.0'
   Provider type: Software
   Provider Id: {b5946137-7b9f-4925-af80-51abd60b20d5}
   Version: 1.0.0.7

What it means: Only Microsoft provider present. Good. If you see additional providers (backup agents, storage tools), they can break VSS or change retention semantics.

Decision: If a third-party provider is present and you’re seeing VSS errors, coordinate with whoever owns that software. Don’t rip it out blind on a production workstation fleet.

Task 14 — Check Storage Sense settings that can trigger cleanup behavior

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\StorageSense\Parameters\StoragePolicy' -ErrorAction SilentlyContinue | Format-List"
01 : 1
04 : 1
08 : 1

What it means: Storage Sense is enabled (01) and configured for certain cleanup behaviors. This doesn’t directly say “delete restore points,” but it correlates with aggressive storage reclamation on low disk systems.

Decision: If restore points vanish during “cleanup days,” review Storage Sense and any enterprise cleanup baselines. Make sure you’re not sweeping away the safety net to save a few gigabytes.

Root causes that make Windows turn it off (or act like it did)

1) Feature upgrades reset protection state

Major Windows upgrades are not gentle. They rearrange system files, rewrite boot configuration, and sometimes reinterpret which volume is “system.” In that process, System Protection can end up Off, or its settings revert to defaults. If you manage fleets, assume this happens occasionally and verify after upgrade waves.

2) Group Policy / MDM baselines disable it

Enterprises often disable System Restore because they prefer standardized imaging and because restore points can complicate support scripts. That can be a rational decision—if you have an alternative rollback path. The failure mode is when policy disables it unintentionally on machines that don’t have that alternative, like remote executives’ laptops or field devices.

3) “Optimization” and cleanup routines delete shadow copies

Some cleanup jobs treat shadow copies like cache. They’re not cache. They’re state. Deleting them isn’t “maintenance,” it’s removing the rollback lever. Disk Cleanup and third-party tools can remove all but the most recent restore point, or wipe shadow copies outright.

4) Disk space pressure forces eviction

VSS has a quota. When you hit it, older snapshots get deleted. If your quota is tiny, you effectively have “restore points” for about five minutes. If your disk is nearly full, Windows will also make ruthless choices. It cares more about the OS continuing to run than about your future self’s feelings.

5) VSS writer/provider failures

Restore point creation depends on a chain of components: services, COM registrations, writers, and providers. One broken writer can stall the whole snapshot operation, or create unreliable restore points that won’t apply.

Second (and final) joke: VSS errors are Windows’ way of saying “I tried” while quietly not trying at all.

Three corporate mini-stories from the trenches

Mini-story #1: The incident caused by a wrong assumption

The environment: a mixed fleet of Windows 10 and Windows 11 laptops, plus a handful of workstation-class desktops used for CAD. A team pushed a driver update for a docking station. It wasn’t malicious. It was just… ambitious.

By lunch, helpdesk tickets spiked: external monitors black-screening, USB devices dropping, machines intermittently freezing. The on-call engineer did what every sane person would do: “No worries, roll back using restore points.” Except restore points were missing on a large chunk of devices.

The assumption was subtle: “Windows always keeps restore points.” In reality, System Protection had been disabled months earlier in a “standardization” baseline intended for lab machines that were reimaged weekly. That baseline was later reused for laptops. Nobody noticed because everything was fine—until it wasn’t.

The fix wasn’t heroic. They reverted the policy for the laptop OU, re-enabled protection, set a quota that could survive two cumulative updates, and added a post-change verification step: confirm at least one fresh restore point exists on test devices before rollout. The lesson was humbling: if a safety mechanism isn’t explicitly monitored, it doesn’t exist.

Mini-story #2: The optimization that backfired

Another shop, another “we need to reclaim storage” moment. SSDs were filling up, and someone decided to deploy an aggressive cleanup script. It removed temporary files, browser caches, old update downloads, and—because it seemed reasonable at the time—shadow copies.

The script worked beautifully. Disk space graphs went up and to the right. Everyone applauded. Two weeks later a bad Windows update triggered boot issues on a subset of machines. Recovery options narrowed fast: BitLocker keys were available, sure, but restore points would have been the cleanest rollback for many systems.

They were gone, because the script had been deleting them on schedule. Worse, the script ran right after Patch Tuesday, which is when you most want restore points to exist. The optimization achieved the metric (free space) by sabotaging the outcome (fast recovery).

The correction was to treat shadow copies as protected capacity. They reworked the cleanup policy to target known-safe areas and set minimum free space thresholds, but never mass-delete shadow copies. They also started measuring “restore point freshness” as a health signal on representative endpoints. The backfire wasn’t technical. It was a priority mismatch.

Mini-story #3: The boring but correct practice that saved the day

A finance org had an old-fashioned practice: before monthly close, they ran a standard “stability checklist” on critical workstations. One item was painfully dull: verify System Protection is On for C: and that at least one restore point exists created in the last seven days.

During a close week, a line-of-business app update shipped with a kernel driver. It triggered intermittent BSODs on machines with a particular storage controller firmware. Not all machines—just enough to be expensive.

Because restore points existed and had enough quota to survive routine churn, the desktop team rolled systems back quickly, stabilized operations, and then fixed the root cause (firmware + driver combo). No emergency reimaging wave. No “send the laptop to IT and wait three days.” Just boring hygiene paying interest.

If you’re looking for a moral, it’s this: flashy incident response is a tax. Quiet preparation is a dividend.

Common mistakes: symptom → root cause → fix

1) Symptom: “No restore points have been created”

Root cause: System Protection is Off for C: (or the OS volume).

Fix: Enable System Protection for the correct volume, then create a test restore point. Confirm it appears via Get-ComputerRestorePoint.

2) Symptom: Restore points exist briefly, then vanish within a day

Root cause: Shadow storage max size is tiny; VSS evicts old points immediately.

Fix: Increase quota (vssadmin resize shadowstorage). Ensure free disk space supports the quota.

3) Symptom: UI shows protection “On,” but creation fails

Root cause: VSS writer failures, provider issues, or disabled services.

Fix: Check vssadmin list writers, review VSS event logs, repair underlying services/components. Then retry Checkpoint-Computer.

4) Symptom: Restore points disappeared right after running Disk Cleanup

Root cause: Cleanup removed restore points or reduced to the most recent.

Fix: Adjust cleanup practice. Treat restore points as protected. Increase quota so normal operation doesn’t force you into “cleanup roulette.”

5) Symptom: Restore points disappeared after a Windows feature update

Root cause: Upgrade reset protection settings or invalidated old snapshots.

Fix: Post-upgrade verification: ensure protection is enabled and create a new restore point. Don’t expect old ones to survive major upgrades.

6) Symptom: On domain machines, System Protection keeps turning off again

Root cause: Policy enforcement via registry keys or domain GPO.

Fix: Fix the baseline. Stop fighting policy locally; it will win every refresh cycle.

7) Symptom: Previous Versions works, but System Restore doesn’t (or vice versa)

Root cause: Different consumers of VSS. One can be enabled while the other is effectively disabled.

Fix: Check both: restore points list and vssadmin list shadows. Configure System Protection explicitly for the system volume.

8) Symptom: Restore points fail on laptops more than desktops

Root cause: Low disk space, frequent power transitions, and aggressive cleanup policies hit mobile devices harder.

Fix: Increase quota, enforce minimum free space, and don’t schedule cleanup right after patch deployment.

Checklists / step-by-step plan

Checklist A — One machine, right now (15–30 minutes)

1. Confirm OS volume: Usually C:, but verify if Windows is installed elsewhere.
2. Check restore points list with Get-ComputerRestorePoint. If empty, continue.
3. Check policy keys under HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore.
4. Check shadow storage quota using vssadmin list shadowstorage.
5. Resize quota to a sane number (8–30GB depending on disk size and change rate).
6. Check VSS writers via vssadmin list writers.
7. Review VSS event logs for the last week. Look for repeated IDs like 8193, 12289, 13.
8. Create a manual restore point using Checkpoint-Computer.
9. Re-list restore points. If the new one exists, you’ve restored the pipeline.

Checklist B — Fleet hygiene (what you standardize)

1. Define a restore point retention policy: quota target and minimum expected freshness (e.g., at least one point in last 7 days on user endpoints that allow it).
2. Set consistent quotas based on disk size tiers. Tiny quotas cause churn and false confidence.
3. Stop shadow-copy deletion in cleanup baselines unless you have a better rollback mechanism and you mean it.
4. Post-upgrade verification: after feature updates, confirm protection is enabled and create a new restore point.
5. Monitor VSS writer health on representative machines; a broken writer is often a precursor to backup failures too.
6. Educate helpdesk playbooks: “No restore points” is a diagnosable condition, not a mystical curse.

Checklist C — When you absolutely need rollbacks to work

1. Don’t rely on System Restore as your only safety net. Pair it with imaging or a real backup strategy where possible.
2. Before risky changes (driver rollouts, security agents, kernel components): create a restore point and verify it exists.
3. After risky changes: confirm you still have restore points and that shadow storage isn’t saturated.
4. Keep free space headroom. If C: lives under 10–15GB free on modern builds, you’re courting entropy.

FAQ

1) Why does System Protection keep turning off?

Most commonly: policy (GPO/MDM), feature upgrades resetting settings, or third-party “optimization” tooling. Sometimes it’s not “off,” it’s effectively useless due to a tiny quota.

2) Are restore points the same as backups?

No. Restore points are designed for system-state rollback (drivers, registry, system files). They’re not a dependable method to recover user data or a full disk state.

3) How much disk space should I allocate for restore points?

Enough to survive normal churn: updates, driver installs, and app changes. On a 256GB+ system drive, 15–30GB is usually sane for endpoints that rely on SR. The right number depends on change rate and free space.

4) Why do restore points disappear after a Windows update?

Some updates create restore points; others trigger cleanup or consume enough shadow storage that older points get evicted. Feature upgrades can invalidate or remove older snapshots entirely.

5) Can Disk Cleanup or Storage Sense delete restore points?

Yes. Disk Cleanup can remove restore points (often keeping only the newest). Storage Sense and low-space behavior can indirectly cause eviction by pressuring disk usage and triggering cleanup policies.

6) I have VSS shadows, but System Restore shows nothing. Why?

VSS shadows can be created by backups or “Previous Versions” without System Restore being enabled. System Restore needs System Protection enabled and tracks restore point metadata separately.

7) Is it safe to relocate shadow storage to another drive?

It can be, but it adds complexity. If the secondary volume is removable, flaky, or heavily utilized, you may trade one failure mode for another. If you do it, monitor it and document it.

8) What does it mean when VSS writers are in “Failed” state?

It means one of the components that must quiesce data for snapshots is unhealthy. Restore points and backups can fail or be incomplete. Fix the underlying service/component and re-check writer status.

9) Should enterprises disable System Restore?

Only if you have a better rollback story that works on real endpoints under real pressure. Disabling it without an alternative is like removing seatbelts because you prefer airbags.

10) What’s the single best test to confirm it’s working?

Create a manual restore point with Checkpoint-Computer, then confirm it exists with Get-ComputerRestorePoint, and verify shadow storage has enough headroom.

Practical next steps

If restore points are missing, stop treating it like bad luck. It’s almost always configuration, quota, or VSS health.

1. Check System Protection for the OS volume and confirm policy isn’t disabling it.
2. Fix shadow storage quota so restore points can survive normal Windows churn.
3. Validate VSS writers and event logs; a broken VSS stack will sabotage restore points and backups alike.
4. Hunt down cleanup behavior that deletes shadow copies, especially right after patching.
5. Institutionalize one boring check: “Do we have a recent restore point?” Put it in your change playbook.

Restore points aren’t glamorous. They’re not even particularly loved by Windows. But when you need them, you need them. Make them boringly reliable.