+44 (0)1482 770583
hello@systechitsolutions.co.uk
Backup Services
Monitored, tested backup so recovery is fast, verified and stress-free, including Microsoft 365.
Recoverable, whatever happens
In short: Monitored, tested backup including Microsoft 365, so recovery is proven rather than assumed. The question worth asking is not whether you are backed up, it is when you last proved a restore and how long it took.
Everyone has a backup. Far fewer have a restore, because a backup nobody has monitored or tested is just a hope with a schedule, and you only find out which you have on the worst day.
The problem
Untested backups fail silently: the job that quietly errored for months, the Microsoft 365 data Microsoft never promised to keep, the restore that turns out to be days long when you needed hours. You discover the gap at exactly the moment you can least afford to.
What we would do
Stop asking whether you are backed up and start asking when you last proved a restore and how long it took. Every product protects an estate configured properly; the failure is always a job erroring unread, a scope that never included the new server, or a restore nobody timed.
- If Microsoft 365 is your main concern, decide first whether you need a copy held outside the service boundary, because that is what separates first-party backup from third-party.
- If ransomware is the driver, immutability enforced by the storage layer rather than by a setting in the backup application is the control that matters.
When we are not the answer: If you have tested restores on record, a documented recovery point and recovery time objective agreed with the business, and a scope you know is complete, you do not need us. That is rarer than it sounds, and checking costs nothing.
Backups are only worth having if they work when you need them. We provide monitored, regularly tested backup for your servers, endpoints and cloud workloads, including Microsoft 365.
More on how we deliver our backup services
When something goes wrong, whether it's ransomware, hardware failure or simple human error, you recover quickly with confidence, because we've already proven the restore works.
Everything you need, managed for you
What is the difference between having backups and being recoverable?
Recoverability is a tested property of the whole estate; a backup is one input to it. The gap between the two is where most organisations discover, at the worst possible moment, that they had the wrong thing.
A job can complete successfully every night and still be useless: it might be backing up a database while it is running, without quiescing it, so what lands is a file nobody can mount. It might have stopped covering a server that was rebuilt in March. It might be perfectly valid and take four days to restore over the link you have.
So the questions worth asking are not about the backup, they are about the restore. How long does it take to get the finance system back, measured rather than estimated? Who does it, and what happens if that person is unavailable?
Where are the credentials for the backup platform, and are they somewhere that survives the same incident? What is the order of restoration, given that half your systems will not start until identity and DNS are working? An organisation that can answer those is recoverable. One that can only show green job reports has backups.
Does Microsoft back up Microsoft 365, and what exactly is missing?
Not in the way most people assume. Microsoft's shared responsibility model makes them accountable for keeping the service available and resilient, and makes you accountable for your data within it.
What the platform gives you is recycle bins, version history, retention policies and legal hold: controls designed for accidental deletion and for legal preservation, not for restoring a tenant after a compromised administrator account deleted at scale, or after ransomware encrypted files that then synced happily to the cloud. Recycle bins have finite windows, and once one lapses the content is gone.
The specific gaps that catch people out, and where Microsoft's own backup product stops
The gaps that catch people out are specific. Deletion discovered months later, long after the recycle bin window closed. A leaver's OneDrive and mailbox, which are retained for a limited default period after the account is deleted and then removed permanently unless a hold was applied first, in advance. Teams data, which is scattered across chat, channel messages, files and the underlying SharePoint sites, and which people rarely realise is not covered by whatever they think covers Exchange. And the point-in-time restore of a whole site or mailbox to how it looked before the incident, rather than item-by-item retrieval from a bin.
Those are the reasons a dedicated Microsoft 365 backup exists. Microsoft now sells one itself: Microsoft 365 Backup reached general availability in late 2024 and covers OneDrive, SharePoint and Exchange Online with a one-year retention window. It restores quickly, because its copies sit inside the Microsoft 365 service boundary, which is also precisely why it is not an independent copy. Which of the three layers you need is set out in full on our page on whether Microsoft 365 backs up your data.
How do you set RPO and RTO without guessing?
By asking the business two questions per system and writing the answers down. The recovery point objective is how much work you are prepared to lose, which in practice means how far back you can afford to roll: an hour of orders is a very different proposition from a day of them.
The recovery time objective is how long the system can be unavailable before the consequence becomes serious. Both are business decisions, not technical ones, and the technology exists to meet them rather than to define them.
The discipline that makes this useful is refusing to answer 'zero' for everything, because that produces a design nobody will pay for and so nothing gets designed. Rank systems into a small number of tiers by what actually stops if they are down, accept that the file share holding archived project folders does not need the protection the practice management system needs, and check that the resulting design genuinely meets the stated numbers rather than assuming it does.
A stated RTO that has never been timed against a real restore is an aspiration, and it is the number people quote in a crisis right up until the moment it is disproved.
What does the 3-2-1 rule mean in a cloud-first estate?
Three copies of the data, on two different types of media, with one held off site. It predates the cloud and it still holds, because it is really a rule about correlated failure: the copies must not be able to fail for the same reason at the same time.
What has changed is what counts as separation. Two containers in the same cloud account are not two independent copies, because a single compromised administrator credential reaches both. Neither is a replica that faithfully replicates the encryption an attacker just applied.
In a modern estate the practical reading is: a local copy for fast restores, a copy in a different platform or account with separate credentials, and at least one copy that is immutable for a defined period.
Many people now extend it to 3-2-1-1-0, adding one immutable or offline copy and zero errors on verification. The number is less important than the test: for each pair of copies, name the single event that could destroy both. If you can name one, they are not really two copies.
Why does immutability matter, and what makes a copy genuinely immutable?
Because modern ransomware attacks the backups first. The operators know that an organisation with working backups does not pay, so a competent intrusion spends time locating the backup platform, deleting or encrypting the repositories, and only then triggering the encryption of live systems. Retention alone does not stop that: a copy an administrator can delete is a copy an attacker with administrative credentials can delete, and by that stage in the intrusion they usually have them.
Immutability means the copy cannot be altered or removed for a defined period, by anybody, including whoever holds the highest privilege on the platform. That last clause is the whole point, and it is the one to test rather than take on trust.
The practical checks are:
- Is immutability enforced by the storage layer rather than by a setting in the backup application
- Can the retention period be shortened by an administrator
- Is there an approval or delay before any destructive operation
- Are the backup platform's own credentials separate from the domain and cloud identities an attacker would already hold
A vendor that answers those clearly is worth more than one with a longer feature list.
What actually gets missed when a backup is scoped?
Consistently the same things. Endpoints, on the assumption that everything is in OneDrive, which is true right up until somebody saves the important spreadsheet to the desktop. Microsoft 365, on the assumption that the cloud is backed up by definition.
Configuration rather than data:
- Firewall rules and network device configs
- The identity platform's own settings
- Certificates
- The build definitions that let you stand a server back up rather than just restore its files
- Line-of-business applications where the database is captured but the licence keys, integration settings and interfaces to other systems are not
Then the recovery dependencies, which are the ones that turn a restore into an ordeal. Where are the credentials for the backup platform stored, and are they in the system you are trying to restore? Is the documentation for the restore process itself only available on the file share that is down?
Is there an offline copy of the recovery plan? Does anyone other than one person know how to do it? An estate can have technically excellent backups and still fail to recover, purely because everything needed to run the restore was inside the thing that broke.
What does a real restore test look like?
It restores something to somewhere it can be used, and somebody who knows what the data should look like confirms that it is correct. That is the bar, and it is higher than what usually passes for testing.
Verifying that a backup file exists and passes a checksum proves the file is intact, not that the application inside it will start, that the database will mount, or that last week's transactions are present. A test that ends at the storage layer has tested the storage layer.
A useful test runs to an isolated environment so production is never at risk, follows the written procedure rather than the knowledge in someone's head, and is timed, because the elapsed time is the only honest measure of your real recovery time objective. Rotate what gets tested so that over a cycle the important systems have each been proven rather than the same convenient one every time, and include at least one restore performed by somebody other than the person who built the backup.
Record what was restored, how long it took and what went wrong, because the things that went wrong are the actual output of the exercise. We agree a testing schedule with each client and report against it, so the evidence exists before it is needed rather than after.
What does a disaster recovery plan need beyond backup?
An order, an owner and a way to communicate. Order matters because systems have dependencies: identity, DNS and network services usually have to come back before anything that authenticates against them, and restoring the visible business application first is a common way to waste hours. The plan should state the sequence, the target time for each tier and what the business does manually in the meantime, because there will be a period where the answer is paper and telephones.
Ownership matters because in a real incident people are unavailable, distracted or already dealing with something else, so every step needs a named owner and a named deputy.
Communication matters because staff, clients and sometimes regulators need to hear something accurate and early, and the mechanism for telling them cannot depend on the systems that are down: if your only route to reach staff is the email platform, and the email platform is the problem, you have no route. Print the plan. Keep contact details offline. Decide in advance who is authorised to declare an incident and who speaks for the organisation.
How does backup interact with Cyber Essentials, ISO 27001 and insurance?
Precisely and differently, and it is worth being accurate rather than implying more than is true. Cyber Essentials covers five technical control themes, and backup is not one of them, so no amount of backup capability will pass a control you have failed elsewhere.
ISO 27001 is different: its Annex A includes a control specifically on information backup, so an organisation certified to it is expected to have backup arrangements that are documented, aligned to agreed requirements and, importantly, tested. That word is what turns backup from a purchase into a discipline. Systech holds both ISO 27001 and Cyber Essentials, so this is a standard we run against as well as advise on.
Cyber insurance is where the detail bites hardest. Proposal forms and renewal questionnaires routinely ask whether backups are held offline or immutably, whether they are separated from the production environment, and whether restores are tested, and the answers form part of the basis on which cover is written.
Answering optimistically about a control you do not actually operate is a poor position to be in at claim time. The safe approach is to answer from evidence you could produce, which is another argument for testing on a schedule and keeping the records.
What should backup reporting actually tell you?
Four things, and most reporting only manages the first. Whether jobs completed, obviously, but with warnings treated as failures rather than as background noise, because a job that has been completing with warnings for six months is usually a job that is quietly skipping something.
What is protected against what should be protected, so a new server or a new site that nobody added to the schedule shows up as a gap rather than as an absence nobody notices. Whether restores have been tested, when, what was restored and how long it took. And how retention and storage consumption are trending, because that is what predicts the next capacity or cost surprise.
The failure pattern is silent success. Alerting configured only for failure means a job that stops running altogether, or an agent that stopped checking in, produces no alert at all, because nothing failed: nothing happened.
Reporting should assert what it expects to see and flag the absence, and it should go to somebody whose job it is to act on it rather than to a shared mailbox. That is the difference between monitored backup and backup with a monitoring product attached.
When do you not need this, and where does our scope end?
You do not need us if you already have an owned, immutable, off-platform copy of everything that matters, a documented and timed restore procedure, and a record of tests somebody actually ran this year. That is a genuinely well-run position and it is rarer than it should be.
Where it is worth having the conversation is the far more common situation:
- Backups inherited from a previous supplier
- A platform nobody has looked inside for a while
- Microsoft 365 assumed to be covered
- No test on record
Our scope is servers, endpoints, cloud workloads and Microsoft 365 data, with monitoring, immutable copies, restore testing and recovery planning around them. We will tell you where the platform you already own is sufficient rather than replacing it for the sake of it.
What we will not do is state a recovery time we have not measured on your estate: any figure quoted before a test is an estimate, and we would rather test it and tell you the real number, even when the real number is not the one you wanted.
| Scenario | Native retention, recycle bins and holds | Dedicated Microsoft 365 backup |
|---|---|---|
| Accidental deletion, spotted quickly | Handled well; the recycle bin or version history is usually enough | Also handled, but the native tools are the faster route |
| Deletion discovered months later | Gone once the retention window has lapsed | Recoverable for as long as your own retention policy keeps it |
| Compromised admin account deleting at scale | Deletions and policy changes are made with legitimate privilege, so the platform obeys them | An independent copy outside the tenant, held immutably, that tenant credentials cannot reach |
| Ransomware encrypting synced files | Version history may help if versions survived; the encrypted versions sync too | Point-in-time restore of a site or mailbox to how it looked before the event |
| A leaver's mailbox and OneDrive | Retained for a limited default period after deletion, then removed unless a hold was applied first | Retained on your schedule, decided after the fact rather than only in advance |
| Teams chat, channels and files | Governed by retention, and spread across chat, channels and the underlying sites | Captured as a set, so a Team can be restored rather than reassembled |
| Long-term regulatory retention | Achievable with retention policies and holds, inside the tenant and under admin control | Independent of the tenant, which is what makes it defensible as a separate copy |
| Who is accountable | Microsoft for service availability and resilience | You, for your data, which is exactly what the shared responsibility model says |
Questions we hear a lot
Doesn't Microsoft back up Microsoft 365 for us?
Microsoft keeps the service running, but under its shared responsibility model your data is your responsibility. Deleted or ransomware-encrypted mail, files and Teams data can be lost once retention windows pass. A dedicated Microsoft 365 backup gives you independent, long-term, recoverable copies.
How do you know a backup will actually restore?
Because we test it. We monitor every backup job and run regular recovery tests, so a restore is a proven routine, not a gamble. That's the difference between having backups and having recoverability.
Are your backups protected against ransomware?
Yes. We keep immutable, ransomware-resilient copies that can't be altered or deleted by an attacker, so even if live systems are encrypted, there's a clean copy to recover from.
What are RPO and RTO, and how do we decide ours?
The recovery point objective is how much work you can afford to lose, so it sets how often backups run. The recovery time objective is how long a system can be down before the consequence becomes serious, so it sets how the restore is designed. Both are business decisions rather than technical ones. Rank your systems into a few tiers by what actually stops when they're unavailable, avoid answering 'zero' for everything because that produces a design nobody will fund, then check the resulting design genuinely meets the numbers by timing a real restore rather than assuming.
Is replication the same as backup?
No, and confusing the two is a common and expensive mistake. Replication keeps a second copy continuously in step with the first, which is excellent for hardware failure and site loss because failover is fast. It is no use at all against ransomware, corruption or deletion, because it faithfully replicates those too, usually within seconds. Backup keeps historical points you can go back to. Most estates that need fast failover need both: replication for availability, backup with immutable retention for recovery.
Does the 3-2-1 rule still apply if everything is in the cloud?
Yes, though what counts as separation changes. The rule is really about correlated failure: three copies, two media types, one off site, arranged so no single event destroys more than one. Two storage accounts under the same cloud tenant are not two independent copies, because one compromised administrator credential reaches both. The useful test is to take each pair of copies and name the single event that could destroy both. If you can name one, you effectively have fewer copies than you think.
What does a restore test actually involve?
Restoring real data to somewhere it can be used, and having somebody who knows the data confirm it is correct and complete. Verifying that a backup file exists and passes a checksum only proves the file is intact; it doesn't prove the application will start or the database will mount. A worthwhile test runs to an isolated environment, follows the written procedure rather than someone's memory, is timed so you learn your true recovery time, and rotates across systems so the same convenient one isn't the only thing ever proven. What went wrong during the test is the most valuable output.
What is usually left out of a backup scope?
Endpoints, on the assumption everything is in OneDrive. Microsoft 365, on the assumption the cloud backs itself up. Configuration rather than data: firewall and network device configs, identity platform settings, certificates and server build definitions. And the recovery dependencies, which is the one that hurts most: the credentials for the backup platform, the documentation for the restore procedure, and the recovery plan itself all stored inside the environment you are trying to restore. Keep an offline copy of all three.
Our backup services is delivered UK-wide from our office in Brough, East Yorkshire, with on-site support across the county where it helps. We work with businesses in Harrogate, Huddersfield, Scarborough, Bradford, Hull and Leeds and 6 more Yorkshire towns and cities, and remotely with clients right across the UK.
When did you last prove a restore?
Not whether the jobs are running. Whether somebody has restored from them, how long it took, and what you could not get back if it happened tonight.
Technology partners
Best-of-breed technology we use to deliver our backup services.
See all technology partners →