When a US MSP gets the 2 a.m. call — a business-email-compromise, a ransomware detonation, a user who emptied a folder — the first decision is not "restore," it is which restore. There are at least three genuinely different operations behind that word, and the one you pick decides what happens to the data already in the mailbox. 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 labeled folder next to the live data. Nothing that exists is touched. It is the right default for "a user deleted an email last week," and the mode to reach for whenever 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 afterward.
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, structure intact. Because it writes into a live mailbox, it sits behind an approval step rather than running on a whim — the person who runs the recovery is not always the person authorized to change production.
Exact-state: the destructive revert
The third mode is the sharp one. An exact-state restore does not only add what is missing — it removes what should not be there, so the mailbox ends up matching the chosen point in time exactly. That is precisely what a compromise needs, where 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 under preservation, which keeps a recovery from becoming a spoliation problem. Removed items are soft-deleted and recoverable, not shredded. The guardrails are not bureaucracy; they are what make a destructive tool safe to hand an operator mid-incident.
Deleted data → side-by-side or in-place. Injected data, i.e. a compromise → exact-state. 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, because "any point in time" is usually not true. Backups are snapshots on a cadence — as often as every four hours. Ask to restore to a specific instant and the system resolves to the nearest snapshot at or before it, and tells you how far before: a restore point, not a time machine. That is the reality every snapshot-based system lives with; reconstructing the exact millisecond between snapshots needs continuous data protection, a different and far heavier mechanism. The honest version is: pick your instant, and we restore the last known-good state before it and show you the gap.
Why naming the three matters
They fail differently. Side-by-side fails safe — worst case, a duplicate folder. Exact-state, misused, fails loud — it deletes live data. A product that collapses them into one button, or hides which one it is running, is making the most consequential decision in the operation on your behalf, silently. Naming the three, gating the dangerous one, and being honest about the granularity of the point you restore to is the difference between recovery and regret.