Backup & disaster recovery / Tested, not assumed
A backup is only as good as its last tested restore.
A backup job that reports success every night is not the same claim as your business staying open after a bad day. This page separates the two: what actually gets backed up, how a restore gets proven rather than assumed, and what disaster recovery does and does not promise.
Read this page in FrenchTwo different claims
“We have backups” and “you will stay open” are different sentences.
A green checkmark on a backup job means data copied somewhere last night. It does not mean that data can be put back into a usable state within a time your business can survive, or that the application depending on it will actually start again afterward. Those are two different claims, and backup marketing quietly merges them into one more often than it should.
What typically gets backed up
Not everything is covered by the same method.
| Category | What's typically covered | What your team should confirm |
|---|---|---|
| Email & Microsoft 365 | Mailboxes, files, and Teams content on a defined retention schedule | The exact retention period your team actually needs |
| Line-of-business applications | Whatever the application's own vendor supports backing up | That vendor's own recovery tools and limits |
| Devices & local files | Anything stored only on a laptop, not synced anywhere else | Whether local-only storage is acceptable at all |
| Recovery point & time | How much data loss and downtime is tolerable if the worst happens | The actual number - this page does not invent one for you |
The test that actually matters
An untested restore is a guess, not a plan.
The most common gap in backup and disaster recovery is rarely the backup itself - it is the restore. A job can report success for months while the actual recovery process has never been attempted, timed, or checked against a real failure.
- Whether a real file, mailbox, or system restore has actually been tested, and when
- How long a realistic restore actually takes - not the number assumed back at setup
- What is excluded from backup entirely, and whether that gap is accepted knowingly
- Who declares an actual disaster, and what happens in the first hour after that call
What this is / what it isn't
Real coverage, named boundaries.
What's realA defined backup scope, a documented retention period, and a restore process tested on a real cadence rather than assumed to work.
What is not claimedA guaranteed recovery time, a specific uptime percentage, or coverage of data that was never included in the agreed scope. This site does not invent a recovery number before your environment has actually been reviewed.
Before you compare providers
Ask to see a tested restore, not just a status report.
Any provider can show a dashboard of green checkmarks. The more useful ask is evidence that a real restore - a file, a mailbox, a small system - was actually performed, and how long it took. See where backup status fits the wider monitoring picture
Next step
Prepare the responsibilities before contacting a provider.
The service map turns your context into a short, copyable list: people, devices, Microsoft 365, vendors, and decisions to clarify.
Build the service map