Point-in-Time Recovery on Windows: Why "We Have Backups" Isn't the Same as "We Can Undo This"

Ask most IT teams whether they have point-in-time recovery, and they'll say yes, pointing to a nightly backup job that's been running without complaint for years. That answer is usually wrong, and the gap between "we have a backup" and "we have point-in-time recovery" tends to surface at the worst possible moment — during an actual incident, when someone finally tries to restore to a specific minute rather than the last scheduled snapshot.

Point-in-time recovery, or PITR, is the ability to restore a system or database to its exact state at any arbitrary moment — not just the moment your last backup happened to run. On Windows, this capability exists at several different levels, ranging from consumer file versioning to genuine database-level recovery, and conflating them is where most recovery plans quietly fail.

1. What "Point in Time" Actually Means

A traditional backup captures a system at fixed intervals — nightly, hourly, whatever the schedule dictates. If something goes wrong at any moment between two scheduled backups, your recovery options are limited to those two bracketing snapshots: restore to before the problem, and lose everything since, or restore to after, and keep the problem.

True point-in-time recovery removes that constraint entirely. Instead of only being able to land on scheduled snapshot moments, you can recover to any specific timestamp — 2:46 PM, thirty seconds before a bad transaction committed, for instance — because the system has been continuously capturing the information needed to reconstruct that exact moment, not just periodic full copies.

2. Volume Shadow Copy Service: The Foundation Windows Is Built On

Nearly every form of point-in-time capability on Windows — from the "Previous Versions" tab on a file's properties, to File History, to the consistent backups that Windows Server Backup and most third-party backup tools rely on — sits on top of a single underlying component: the Volume Shadow Copy Service, usually abbreviated VSS.

VSS works by creating a shadow copy — a consistent, frozen snapshot of a volume at an exact moment, even while files on that volume are actively being written to. It accomplishes this by briefly coordinating with applications through a set of writers, letting a database engine or application flush its in-memory state to disk first so the resulting snapshot is transactionally consistent rather than a snapshot of data mid-write. Applications that support VSS integration — SQL Server among them — implement a VSS writer specifically so that any shadow copy taken includes their data in a valid, recoverable state.

3. Two Very Different Tiers of PITR on Windows

The phrase "point-in-time recovery" gets applied loosely to two capabilities that are not equivalent, and understanding the difference changes what you should actually expect from your recovery plan.

Both are legitimately useful. The problem is treating the first as a substitute for the second, particularly for transactional systems where the exact second of a failure genuinely matters.

4. Why Windows Server Backup Isn't True PITR

Windows Server Backup, the built-in backup role available on Windows Server, uses VSS to create block-level snapshots of volumes on a schedule you define. It's a solid, native tool for full-system and volume-level recovery, and it can restore individual files, volumes, or entire systems — but it operates on the same principle as any scheduled snapshot tool: recovery points exist only at the moments a backup job actually ran.

If your only recovery mechanism is a nightly Windows Server Backup job, you have solid disaster recovery — but you do not have point-in-time recovery in the strict sense, and it's worth being precise about that distinction internally rather than discovering it during an actual incident.

5. Real Point-in-Time Recovery: SQL Server's Log Chain

SQL Server running on Windows is the clearest example of genuine PITR available in a typical Windows environment, and it works through a mechanism distinct from VSS snapshots entirely: the transaction log.

Every change to a SQL Server database running in the Full recovery model is first written to the transaction log before it's applied to the data files. Regular transaction log backups capture this stream of changes continuously, rather than just a snapshot of the data at one moment. Because the log contains a complete, ordered record of every change and precisely when it happened, SQL Server can replay that log up to — and stop at — any exact point you specify.

The STOPAT clause is the entire point-in-time mechanism in a single argument: SQL Server replays the log up to that exact timestamp and then stops, giving you the database exactly as it existed one second before whatever went wrong — a corrupted update, an accidental mass delete, a failed application deployment that wrote bad data.

6. The Mistakes That Silently Break PITR

PITR capability is deceptively easy to lose without realizing it, because the failure is often invisible until the moment you actually need to restore.

• Running a database in the Simple recovery model, which automatically truncates the transaction log and makes arbitrary point-in-time restores impossible — only full and differential backup points remain recoverable.
• Gaps in the transaction log backup chain — if a single scheduled log backup fails silently and nobody notices, every point-in-time restore after that gap becomes impossible until a new full backup restarts the chain.
• Assuming a file-level shadow copy schedule provides the same guarantee as a database log chain, when in fact it only offers recovery to discrete snapshot moments.
• Not testing restores at all — a backup or log chain that has never actually been restored in practice is an assumption, not a verified capability.
• Retention policies that purge log backups faster than anyone would realistically need to look back, eliminating the recovery window before an incident is even discovered.

7. Building PITR Into a Windows Environment Properly

• Identify which systems genuinely need second-level recovery granularity — typically transactional databases — versus which are adequately served by scheduled file-level snapshots.
• For SQL Server databases requiring PITR, confirm the recovery model is set to Full (or Bulk-Logged where appropriate), not Simple.
• Schedule transaction log backups frequently enough that your acceptable data-loss window matches business requirements — the interval between log backups defines your worst-case recovery gap.
• Monitor the backup chain actively, alerting on any failed or skipped log backup rather than only monitoring full backup success.
• Periodically perform actual test restores to a specific timestamp, not just verification that a backup file exists.
• Keep VSS-based file recovery (Shadow Copies, File History) as a complementary layer for accidental file loss, understanding clearly that it is not a substitute for database-level PITR.
• Document your actual recovery point objective and recovery time objective explicitly, and verify your current setup actually meets them rather than assuming it does.

Conclusion

The difference between a backup strategy and a true point-in-time recovery capability comes down to a single question: can you land on any exact moment, or only on the moments a scheduled job happened to run? Windows provides the building blocks for both — Volume Shadow Copy Service underlying file and volume-level snapshots, and SQL Server's transaction log chain underlying genuine arbitrary-timestamp recovery — but they solve different problems, and mistaking one for the other is a gap that usually goes unnoticed until an actual incident forces the question.

The fix isn't complicated: know which tier of recovery each of your systems actually has, keep the log chain unbroken and monitored if a database genuinely needs PITR, and test the restore itself periodically rather than trusting that a backup job's green checkmark means the same thing as a verified recovery capability.