Solved What happens if I restore two PITR snapshots but in the wrong date order?

If i try a restore dated 25 June and it does not fix a problem, can I go on to restore a snapshot from June 23, or will that leave things in an inconsistent state?

ChatGPT wrote a load of drivel but, basically, said no. Grok said yes, possibly.

kelper said:

If i try a restore dated 25 June and it does not fix a problem, can I go on to restore a snapshot from June 23, or will that leave things in an inconsistent state?

ChatGPT wrote a load of drivel but, basically, said no. Grok said yes, possibly.

Click to expand...

If you're talking about System Restore... you "know" it doesn't really work well.

I did say PITR in the subject. Nothing to do with 'System Restore'.

kelper said:

I did say PITR in the subject. Nothing to do with 'System Restore'.

Click to expand...

I believe that's just some icing on System Restore.
It's actually RECALL in sheep's clothing. ^^






Here's another recent example of MS's BS...

Co-pilots answer ro YOUR question
You can safely restore PITR snapshots in any order. Restoring a newer snapshot and then an older one will not leave the system in an inconsistent state. PITR doesn’t “stack” or merge snapshots—each restore is a complete rollback to the exact state the system was in at that timestamp.

So if you restore:

• June 25 → the system becomes exactly as it was on June 25
• June 23 afterward → the system becomes exactly as it was on June 23

The second restore simply overwrites the first. Nothing from the June 25 restore remains unless it was already present on June 23.
There’s no corruption risk, no partial mixing of states, and no special procedure required. The only thing to keep in mind is that any changes you make after the first restore will be wiped out by the second, because PITR always replaces the entire dataset with the selected snapshot.

If the June 25 snapshot doesn’t resolve your issue, it’s perfectly safe to restore June 23 next.
----------------------------------------------
MY THOUGHTS for the masses who might read this
Since my own personal experience with system restore has ALWAYS been dubious at best, I have always cautioned anyone to NOT depend on it. Therefore I call one foolish and extend a double caution if one depends on Point-In-Time as their only means of protection.

Know that Point In Time does not deal with multiple volumes, only the volume where the OS is located. So if one has his user files on another volume and expects PIT to help him recover his personal files, he is SOL.

glasskuter said:

Co-pilots answer ro YOUR question
You can safely restore PITR snapshots in any order. Restoring a newer snapshot and then an older one will not leave the system in an inconsistent state. PITR doesn’t “stack” or merge snapshots—each restore is a complete rollback to the exact state the system was in at that timestamp.

So if you restore:

• June 25 → the system becomes exactly as it was on June 25
• June 23 afterward → the system becomes exactly as it was on June 23

The second restore simply overwrites the first. Nothing from the June 25 restore remains unless it was already present on June 23.
There’s no corruption risk, no partial mixing of states, and no special procedure required. The only thing to keep in mind is that any changes you make after the first restore will be wiped out by the second, because PITR always replaces the entire dataset with the selected snapshot.

If the June 25 snapshot doesn’t resolve your issue, it’s perfectly safe to restore June 23 next.
----------------------------------------------
MY THOUGHTS for the masses who might read this
Since my own personal experience with system restore has ALWAYS been dubious at best, I have always cautioned anyone to NOT depend on it. Therefore I call one foolish and extend a double caution if one depends on Point-In-Time as their only means of protection.

Know that Point In Time does not deal with multiple volumes, only the volume where the OS is located. So if one has his user files on another volume and expects PIT to help him recover his personal files, he is SOL.

Click to expand...

I think you are wrong. I may be wrong. Let's see. Restore does not restore the entire dataset; it restores the blocks changed while it was watching.

kelper said:

I think you are wrong

Click to expand...

Won't be the first (nor the last) time.

• Deletions: Restore points are automatically removed, starting with the oldest restore point under the following conditions:
  • Restore points become older than 72 hours.
  • The VSS storage exceeds its maximum configuration for restore points.
  • Free disk space reaches or drops below 20 GB.
  • The device reports low free space conditions that cause VSS to limit or evict restore points.
  • VSS can’t preserve prior data due to a limiting condition (for example, full disk, failure to allocate memory, inability to expand diff area in time, write errors). In this case, all restore points are removed.

The 72 hours is for the Enterprize Edition only. No documentation in this article for Home and Pro editions?

@kelper Per this article near the bottom under "limitations,"it states “For devices that have multiple volumes, only the MainOS volume is restored.”

Asus272 said:

Deletions: Restore points are automatically removed, starting with the oldest restore point under the following conditions:

• Restore points become older than 72 hours.

Click to expand...

And this is why i inactivate automatic restore points and its services and run them manually,. this way i can have restore points that actually matters instead of 10 identical as only a bit have changed since the last one.
There is no point to make other restore points then before a bigger change on system level and after if it works.

Another puzzle - DiskGenius shows six PITR snapshots. But Windows only shows three, with none yesterday. But if I launch PIT Restore, it shows them.

glasskuter said:

@kelper Per this article near the bottom under "limitations,"it states “For devices that have multiple volumes, only the MainOS volume is restored.”

Point-in-time restore for Windows

documentation for point-in-time restore feature

learn.microsoft.com

Click to expand...

Not sure why you are telling me, I know that.

I had an interesting chat with Claude AI

Claude Ai responded to this question

I still don't understand why my test did not show any errors. think the PITR OPERATION MAY USE EVERY SNAPSHOT TO ENSURE INTEGRITY
17:56


That's an interesting hypothesis and probably the most technically plausible explanation. The idea would be that when restoring to the 3-day snapshot, VSS doesn't just look at that snapshot in isolation — it walks the entire snapshot chain to reconstruct a coherent volume state. This is actually consistent with how VSS diff areas work:

VSS doesn't store complete volume images for each snapshot. It stores the original blocks that were about to be overwritten, in a chain. So to reconstruct the volume at any given point, it may inherently need to traverse multiple snapshots in the chain to arrive at a consistent state — making the "absolute target" behaviour essentially a byproduct of how the diff chain is structured rather than a deliberate design choice around sequential restores.

If that's correct, it would also explain why Microsoft caps retention at 72 hours and warns about storage — a longer or broken chain could compromise the integrity of any restore in it, not just the oldest one.

It's still somewhat speculative, but your hypothesis fits the evidence better than anything else. The behaviour you observed wasn't an accident — it was likely the snapshot chain doing exactly what it's supposed to do.

Anyway, I did two PITR restores in the wrong order and Chkdsk and DISM ScanHealth found no errors. I opened all the apps I use frequently so I think MS has figured this out, which might explain why a restore takes ten times longer than Macrium Reflect.

@kelper, since we both use Macrium Reflect, you might find the following useful.

I asked my Copilot if I should use the new PITR or turn it OFF. Here's my Copilot's reply:

You make a daily Macrium Reflect X image alternating on two 4TB Samsung T9 portable SSD drives. You always have images going back 30 days.

All your data and photos are kept in your OneDrive folder and kept in real-time sync in cloud OneDrive and on both your computers.

Your Macrium and OneDrive discipline exceeds PITR’s capabilities by an order of magnitude.

Given your workflow, PITR provides no meaningful benefit. You can safely turn PITR OFF.

TraderGary said:

@kelper, since we both use Macrium Reflect, you might find the following useful.

I asked my Copilot if I should use the new PITR or turn it OFF. Here's my Copilot's reply:

You make a daily Macrium Reflect X image alternating on two 4TB Samsung T9 portable SSD drives. You always have images going back 30 days.

All your data and photos are kept in your OneDrive folder and kept in real-time sync in cloud OneDrive and on both your computers.

Your Macrium and OneDrive discipline exceeds PITR’s capabilities by an order of magnitude.

Given your workflow, PITR provides no meaningful benefit. You can safely turn PITR OFF.

Click to expand...

I asked three AIs and still would value your personal opinion far more.