"Restore it" sounds like a single button. It is not. There are at least three genuinely different operations hiding behind that word, and the difference between them is the difference between a quiet recovery and a second incident. The mode you pick decides what happens to the data that is already in the mailbox — and that is the part people forget until it is too late.
Side-by-side: the safe default
A side-by-side (staging) restore writes the recovered items into a new, clearly labelled folder next to the live data. Nothing that exists is touched; the user gets their lost item back and can move it where they want. It is the right default for "I deleted an email last week," and it is the mode you reach for when you are not certain what the live state should be — because it cannot make anything worse. The only cost is a folder to tidy up afterwards.
In-place: merge back into the original
An in-place restore puts items back where they came from, additively — it re-creates what is missing and leaves what is present. This is what you want when a folder was emptied and you need its contents back in exactly that folder, with the structure intact. It is additive by design: it will not delete anything that is currently there, so a stray recent email is safe. Because it writes into live mailboxes, it sits behind an approval step rather than running on a whim.
Exact-state: the destructive revert
The third mode is the sharp one. An exact-state restore does not just add what is missing — it also removes what should not be there, so the mailbox ends up matching the chosen point in time exactly. That is precisely what you need after a compromise, when the problem is not deleted data but injected data: rules, forwards, or messages an attacker planted. It is also precisely the mode that can destroy legitimate recent mail if pointed at the wrong target.
So it is fenced. It always requires approval, it computes and shows the exact set of items it would remove before it runs, and it is blocked outright while a legal hold is in force — you cannot quietly revert away data that is under preservation. Removed items are soft-deleted (recoverable), not shredded. The guardrails are not bureaucracy; they are what make a destructive tool safe to hand to an operator at 2 a.m.
Deleted data → side-by-side or in-place. Injected data (a compromise) → exact-state. If you are unsure which you are dealing with, start side-by-side: it is the only one of the three that cannot make the situation worse.
The honest physics of "point-in-time"
Every mode restores from a point in time, and it is worth being precise about what that means, because the marketing word "any point in time" is usually not true. Backups are snapshots taken on a cadence — in our case every four hours. When you ask to restore to a specific instant, the system resolves to the nearest snapshot captured at or before that instant, and it tells you how far before: a restore point, not a time machine.
This is the same reality every snapshot-based system lives with. You cannot restore to a moment between snapshots without continuous data protection, which is a different and far heavier mechanism. The honest version is: pick your instant, and we will restore the last known-good state before it and show you the gap. Anyone promising to reconstruct the exact millisecond is either running CDP or overselling.
Why the distinction matters
The reason to separate these three is that they fail differently. A side-by-side restore fails safe — worst case, a duplicate folder. An exact-state restore, misused, fails loud — it deletes live data. A product that collapses them into one "restore" button, or that hides which one it is running, is making the most consequential decision in the whole operation on your behalf, silently. Naming the three, gating the dangerous one, and being honest about the granularity of the point you are restoring to is not extra process. It is the difference between recovery and regret.