Backup and recovery implementation
A backup is only useful if you can restore from it. We set up backup for the client’s servers, endpoints and Microsoft 365, sized to what they can afford to lose, and we don’t call it finished until we’ve restored real data from it.
- Older restore pointsKept as far back as the client needs to reach
- Last good backup
- What’s lostShrinks when the system is backed up more often
- Something goes wrongDeletion, ransomware, a failed disk
- Time without itShrinks when the restore has been planned and rehearsed
- Working again
How much can the client afford to lose?
Count back from the moment it went wrong to the last good copy. That distance is the recovery point, and it sets how often each system is backed up.
How long can they be without it?
Count forward to the moment people can work again. That’s the recovery time, and it decides what gets restored first and how the restore is done.
Every system gets its own answer
One schedule for everything is the most common backup design, and usually the wrong one. The accounts database and last year’s project archive don’t deserve the same treatment.
So the first part of the project is agreeing three things with you and the client, system by system.
-
What
Start from what the business would miss, not from the list of servers. The line-of-business database, the shared drive, the mailboxes, the laptop of the person who keeps everything on their desktop.
Then the things that are easy to forget: the configuration that lets a system be rebuilt, and the accounts and keys needed to get into the backups themselves.
-
How often
Set by how much each system can lose. A database that changes all day is backed up more often than an archive that changes once a quarter.
It’s also backed up in a way the application understands, so the copy opens cleanly instead of coming back as a half-written file.
-
How long
Long enough to reach back past the problems people notice late: a folder deleted months ago, a file corrupted long before anyone opened it, an intrusion that sat unnoticed.
Where the client has record-keeping obligations, their requirements set the minimum. We ask the client rather than guess.
Microsoft 365 is not its own backup
Microsoft keeps the service running. Keeping the client’s data recoverable is up to the client. Recycle bins, version history and retention settings are time-limited conveniences inside the same tenant, not a separate copy, and a deletion noticed too late or a bad sync can outlast them. So mail, OneDrive, SharePoint and Teams go into the backup alongside the servers.
-
Mail
We confirm which mailboxes are covered, shared ones included, and how finely you can restore: one message, one folder or the whole mailbox.
-
OneDrive
Each person’s files, with enough history to roll back past a sync that overwrote good copies with bad ones.
-
SharePoint
Team sites and document libraries, set to pick up new sites as they’re created rather than relying on someone to remember to add them.
-
Teams
Its files live in SharePoint and OneDrive; its conversations are stored separately, and backup products differ in what they capture. We check what the chosen platform covers and tell you.
How backups fail without anyone noticing
Backups usually fail months before anyone needs them, and the failure only shows on the day of the restore. These are the ones we design against.
-
The job has been failing for weeks
Alerts for failed and missed backups go to your service desk, where someone will act on them, not to a mailbox nobody reads.
-
The ransomware reaches the backups too
The backups can’t be reached with the everyday admin accounts, and we use immutable or offsite copies where the platform you’ve chosen supports them.
-
The database comes back but won’t open
Servers running applications are backed up in an application-aware way, and the test restore checks the data opens, not just that files came back.
-
The new server was never added
Where the platform allows, protection follows the environment as it grows. The configuration document records what’s in and what’s deliberately left out, so any gap is a deliberate decision.
-
Nobody knows how to restore, or where the key is
The recovery runbook covers the order of restore, the steps for each system, and where the access details and encryption keys are kept, so recovery doesn’t depend on one person’s memory.
The restore is the proof
Until something has been restored from it, a backup is just a column of green ticks.
The project isn’t finished until we’ve restored real data from the new backups. It goes to a safe location, so nothing live is overwritten, and then it’s checked: does it open, is it complete, is it the version we expected.
Then we write down what happened, including anything that took longer or behaved differently than planned. That record is what turns “we have backups” into something you can show the client.
- What was restored
- The file, mailbox, database or whole server chosen for the test.
- Restore point
- Which backup it came from, and when that backup was taken.
- Restored to
- Where it went, so the test didn’t touch live data.
- How long it took
- Measured, not estimated. This is the number the recovery time rests on.
- How it was checked
- Opened, compared and confirmed complete.
- What didn’t go to plan
- Anything slow, missing or surprising, and what was changed because of it.
What the client ends up with
-
A tested restore
Evidence that the backups can be restored from, with the record to show for it.
-
A recovery runbook
What to restore first, how, and who to call, written for whoever is on the desk the day it’s needed.
-
Backup configuration documentation
What’s backed up, how often, how long it’s kept and where, so your team can support it and answer the backup questions on a cyber insurance form.
Delivered under your brand, at a fixed price
We work remotely and white-label, under your brand or as your named specialist partner, and quote you a fixed price for the scope we agree. The backup platform is your choice, and once it’s in, the alerts and the ongoing service sit with your team.