Home / Managed IT / Backup & Disaster Recovery
Section E · Service 16
Backups only matter if they restore.
Managed backup across servers, endpoints, cloud workloads and SaaS data, with immutable and air-gapped copies, defined recovery objectives, and restore testing that produces documented results rather than a green tick on a dashboard.
Book a consultation →All managed IT servicesThe standard we work to
3-2-1-1-0, and why the last two digits are the point
Most organizations have backups. Far fewer have backups that would survive the event they are meant to protect against, and fewer still have evidence that a restore works. The rule we design to extends the familiar 3-2-1 with the two conditions ransomware made necessary.
Three copies of your data
The production copy plus two others. One backup is a single point of failure wearing a reassuring name.
Two different media types
So that a failure mode affecting one storage technology does not take both copies with it.
One copy stored offsite
Protecting against fire, flood, theft and the site-wide events that ignore how well the server room was configured.
One copy immutable or air-gapped
The ransomware condition. Modern attacks deliberately locate and encrypt or delete backups first, often using the backup software’s own credentials. A copy that cannot be altered or deleted within its retention window is what defeats that.
Zero errors after restore testing
The condition that separates a backup from a hope. A job reporting success proves data was written; only a restore proves data comes back.
Why the last two matter most
Nearly every organization we assess satisfies the first three and fails one or both of the last two. That combination is exactly the one a ransomware operator is counting on.
Protect and prove
Proactive data protection
Protect and prove
- Managed backup for servers, endpoints, cloud workloads and SaaS data
- Immutable and air-gapped copies to withstand ransomware and credential compromise
- Daily backup monitoring with automated restore verification, not just job status
- Disaster recovery planning with defined recovery time and recovery point objectives
- Scheduled failover tests with documented results you can show an auditor or insurer
- Encryption, data loss prevention, classification and labelling
Restore and resume
- File, folder, mailbox and database restores — the everyday case, and the most common
- Bare-metal and full-system recovery
- Ransomware recovery to a clean restore point, validated before reconnection
- Disaster declaration and failover to cloud
- Post-recovery validation and failback to normal operations
Recovery objectives are the part of this that requires a business decision rather than a technical one. Recovery time objective is how long the organization can function without a system; recovery point objective is how much data it can afford to lose. Both cost money to shorten, and setting them honestly — per system, not as a single number for everything — is what makes a recovery plan affordable. A finance system and a file share rarely deserve the same target.
SaaS data
The gap most organizations do not know they have
Cloud platforms operate on a shared responsibility model. The provider is responsible for the availability and resilience of the platform. You remain responsible for your data within it. That distinction is written into the agreements and is routinely misread as “the cloud backs itself up”.
What the platform protects against
- Hardware failure in the provider’s data centres
- Site-level outages and regional failover
- Platform-level data corruption
What remains your responsibility
- Accidental or malicious deletion by a user
- Retention policies that expired before you needed the data
- Ransomware encrypting local files that then synchronize to the cloud
- A departing employee clearing a mailbox or drive
- Data lost when a licence is removed and the retention window elapses
Independent backup of Microsoft 365 and Google Workspace closes that gap, and it also addresses a legal one: retention obligations and legal hold requirements frequently exceed the default retention period of the platform. Where a matter is in litigation, the ability to produce data from a defined point in time becomes an evidentiary question rather than an IT one — which is the boundary where this service meets our eDiscovery and litigation support work.
Contingency and recovery planning follows NIST SP 800-34, Contingency Planning Guide for Federal Information Systems. Backup and recovery safeguards map to the CIS Critical Security Controls.
Planning
Building a recovery plan that someone can actually follow
A disaster recovery plan is only useful under conditions that make it hard to use: people are stressed, systems are unavailable, the person who knows the environment may be unreachable, and the plan itself may have been stored on the file server that is currently encrypted. Designing for those conditions changes what the document contains.
Rank systems honestly
Not everything is critical. Ranking every system as tier one guarantees the plan is unaffordable and that nobody knows what to restore first. We work through systems with the business and assign recovery objectives per system, accepting longer targets where the impact genuinely justifies it.
Map the dependencies
Applications rarely fail alone. Restoring a line-of-business system before its database, directory services, certificates or licence server is a common way to turn a four-hour recovery into a two-day one. Dependency order is established before an incident, not discovered during one.
Keep the plan reachable
Runbooks, contact lists, vendor details and recovery credentials are held where they remain accessible when the primary environment is not. A plan stored only inside the systems it exists to recover is not a plan.
Name the decisions
Who declares a disaster, who can authorize failover, who speaks to customers, and at what point the incident becomes a notification obligation. These are decisions with legal and financial consequences and they should not be made for the first time at two in the morning.
Test the failover
A scheduled test with a documented result, including what did not work. Tests that only ever pass are usually tests that were scoped to pass. The findings are the deliverable.
Plan the failback
Returning to normal operations is a second project and is routinely forgotten. Post-recovery validation and a defined failback path prevent an organization running indefinitely on infrastructure that was meant to be temporary.
Where an incident may involve a criminal act, an insurance claim or litigation, recovery and evidence preservation pull in opposite directions: restoring a system quickly can destroy the artefacts needed to establish what happened. We plan for both, so the decision to preserve a forensic image before rebuilding is made deliberately rather than lost in the urgency — which is where this work connects directly to incident response and forensic examination.
Questions we hear first
About backup and disaster recovery
Our backups report success every night. Is that enough?
No. A successful job means data was written, not that it can be read back into a working system. Restore verification is a separate test, and it is the one that finds corrupted chains, missing application state and encryption keys nobody kept. Until a restore has been performed, the backup is an assumption.
Why do we need an immutable copy if backups are offsite?
Because modern ransomware targets backup infrastructure deliberately, frequently using credentials harvested from the environment, and offsite is not the same as out of reach. If the backup system can delete or overwrite a copy, so can an attacker holding its credentials. Immutability removes that option for a defined retention window.
If we are hit by ransomware, can you recover everything?
That depends on what was protected before the incident, how far back clean restore points exist, and what the attacker reached. We will not promise a particular outcome — anyone who does before seeing the environment is selling rather than advising. What we can do is establish the recovery position in advance so the answer is known before it is needed, and treat any promise of a certain outcome as a warning sign when you hear it elsewhere.
How often should restores be tested?
Routine file-level restores happen continuously as part of normal service requests, which gives ongoing evidence. Full failover tests are scheduled less frequently and produce a documented result, because that document is what an insurer or an auditor will ask for. The right cadence depends on how much the environment changes.
Does this cover endpoints, or only servers?
Both, and SaaS data alongside them. Endpoint backup matters more in a hybrid workforce, where meaningful work may sit on a laptop for weeks. It also converts a lost or stolen device from a data loss event into an inconvenience, provided the device was encrypted — which is handled under endpoint management.
Find out what would actually restore
A recovery assessment establishes what is protected, what is not, how far back clean copies exist, and what a real restore would take. That is the number worth knowing before you need it.
Book a consultation →