Cloud & Operations
Backup & Disaster Recovery Services
We design backup and disaster recovery you can actually restore from, built to real recovery targets, hardened against ransomware, and proven by testing the restore rather than trusting the backup.
What Backup Solutions means in practice
Who it’s for: Organisations that would rather find out their backups work by testing them on a quiet afternoon than by discovering, during a real data-loss or ransomware incident, that they never did.
This is the service that answers a single, uncomfortable question: if your database, your files or an entire system disappeared this afternoon (deleted, corrupted, or encrypted by ransomware), how much would you lose, and how long would it take to get back? Most organisations cannot answer that with confidence, because they have backups but have never tested a restore, or have a backup job that has been quietly failing for months, or have never decided how much data loss and downtime the business can actually survive. We design, build and operate backup and disaster recovery for databases, files and whole systems so that the answer is known, small, and rehearsed rather than discovered during an incident.
The work is more than switching on a backup job. It is deciding how many copies exist and where they live, on what schedule they are taken, how long they are kept, how they are encrypted, and (the part almost everyone skips), how you prove they can be restored before you need them. It is putting numbers on what the business can tolerate: how much recent data you can afford to lose, and how long you can afford to be down. And it is protecting the backups themselves, because backups are now a prime target: modern ransomware goes looking for your backups first, precisely because encrypting them is what turns a recoverable incident into a ransom you have to pay.
We will be blunt about the trade-offs, because they cost real money and pretending otherwise helps nobody. Backing up more often, keeping copies longer, and recovering faster all cost more, sometimes far more. So the right design is not the most protective one; it is the one matched to what this business actually needs, service by service. The genuinely catastrophic failure is not spending too little on backups. It is spending on backups that give false confidence (that look green on a dashboard, that nobody has ever restored from), and finding out, in the middle of a real incident, that they were never working or cannot be restored in time.
What you get
- A backup design built on the 3-2-1 rule, three copies of your data, on two different types of media, with at least one held off-site, sized to your systems rather than a generic template
- Automated, scheduled backups of databases, files and whole systems, with alerting when a job fails, because a silent backup failure is the most common way people discover they had no backup at all
- Defined RPO and RTO targets, agreed per system with the business, so recovery is designed to meet what you can actually tolerate rather than to whatever the default happened to be
- Ransomware-resistant backups, immutable or air-gapped copies that an attacker with full access to your systems still cannot alter or delete, so an intrusion cannot take your recovery path with it
- Encryption of backups in transit and at rest, with proper key management, because backups often hold the most sensitive data you have in one convenient, portable place
- A retention policy that keeps the right number of daily, weekly and monthly copies for as long as the business and any compliance obligations require, and no longer
- Regular, documented restore testing (an actual rehearsed recovery), plus a written disaster-recovery runbook, because a backup you have never restored is not a backup, it is an assumption
What Backup Solutions does for you
The worst day becomes a bad afternoon
The difference between a well-designed backup position and a poor one is rarely visible until something fails, and then it is the difference between a few hours of restore and an existential threat to the business. When backups are complete, tested and recoverable within a known time, a ransomware hit, a corrupted database or a fat-fingered deletion becomes a defined recovery procedure with a predictable end, rather than an open-ended crisis where nobody knows whether the data is coming back at all. We build for that day specifically, because it is the only day a backup strategy is ever really judged.
No more false confidence
A backup dashboard showing green is not evidence that you can recover; it is evidence that a job ran. The two are not the same, and the gap between them is where organisations get destroyed. Backups fail silently, back up the wrong thing, capture a database mid-write in an unusable state, or write to storage that is itself compromised. By testing restores on a schedule and checking that recovered data is genuinely complete and usable, we replace the comforting assumption that backups work with the far more valuable knowledge that they do, and catch the failures on a quiet afternoon instead of during the incident.
Spend that matches the risk
Recovery point and recovery time objectives are the dials that control cost, and setting them honestly per system stops you doing the two expensive things people usually do: protecting everything to the strictest, most expensive standard whether it needs it or not, or protecting nothing properly because a single blanket approach felt too costly. Agreeing what each system actually needs means the customer database gets frequent backups and fast recovery, the reporting server that could be rebuilt gets something cheaper, and the total is money spent where a failure would actually hurt.
Why teams choose us for Backup Solutions
- You want backups that have been restored, not just taken. A service where the deliverable is a proven, timed recovery and a runbook, not a backup job with a green tick that nobody has ever tested against a real failure.
- You are worried about ransomware specifically and want backups an attacker cannot reach, immutable or air-gapped copies that survive a full compromise of your environment, because a backup a single stolen admin credential can delete is no protection at all.
- You want the recovery targets set honestly against what the business can tolerate and afford, with the cost trade-offs of tighter RPO and RTO explained plainly, rather than a one-size design that over-protects some systems and neglects the ones that matter.
- You care that backups are handled as the sensitive, valuable data they are (encrypted, access-controlled and kept only as long as needed), because a backup is a complete, portable copy of your data and a poorly-secured one is a breach waiting to happen.
What Backup Solutions includes
The concrete pieces of work this covers, scoped to what your problem actually needs.
Backup design to the 3-2-1 rule
We design your backups around the discipline that has survived every change in technology: three copies of the data, on two different types of media or storage, with at least one copy held off-site and out of reach of whatever might take down the primary. That structure is what protects you against the full range of failures: a deleted file, a dead disk, a corrupted volume, a burned-down data centre, a ransomware sweep of a whole environment. We size it to your systems and your risks rather than applying a generic template, and we make the off-site, out-of-reach copy a real one rather than a second folder on the same server.
Defining and meeting RPO and RTO
Before we design anything, we put numbers on two things per system: the recovery point objective, how much recent data you can afford to lose, which decides how often backups must run (and the recovery time objective), how long you can afford to be down, which decides how the recovery is architected. These are business decisions with direct cost consequences, so we agree them with you rather than assuming, and then we build to meet them: frequent backups and warm standby where minutes matter, cheaper and slower where a day of rebuild is tolerable. The point is that recovery is designed against a target you chose, not against whatever the tooling defaulted to.
Automated, monitored backup jobs
Backups are automated and scheduled so they do not depend on anyone remembering, and (just as important), they are monitored so a failure is noticed. The single most common way organisations discover they have no usable backup is that the job had been failing silently for weeks or months and nobody was watching. We wire in alerting on failed and missed jobs, on backups that completed but produced a suspiciously small file, and on storage filling up, so a broken backup is an alert you act on this week rather than a nasty surprise during a restore you cannot afford to have fail.
Retention policies and lifecycle
How long you keep backups, and how many, is a deliberate policy rather than an accident of default settings. We design retention around what the business and any compliance obligations actually require: a sensible ladder of daily, weekly and monthly copies, kept for as long as they are useful and no longer, because holding backups indefinitely is both a needless cost and a growing liability. Older copies age out automatically, storage tiers are used to keep long-term retention affordable, and the policy is written down so there is a clear, defensible answer to how far back you can recover and why.
Ransomware-resistant, immutable backups
We assume an attacker will reach your environment and go looking for your backups, because that is exactly what modern ransomware does, deleting or encrypting backups is how it forces you to pay. So we make the critical copies immutable or air-gapped: written once and unchangeable for a set period, or held on storage that is disconnected or credential-isolated from the systems being protected. The test we design against is deliberately harsh: could an attacker who has gained full administrative control of your environment still not destroy your ability to recover? If the answer is yes, an intrusion stays a recovery job instead of becoming a ransom negotiation.
Restore testing and disaster-recovery runbooks
The capability that separates a real backup strategy from a hopeful one is restoring on purpose, regularly, and confirming the result. We rehearse restores (a single database, a set of files, a whole system), time them against the RTO you agreed, and verify the recovered data is complete and actually usable rather than a file that exists but will not open or a database that comes back inconsistent. Around that we write the disaster-recovery runbook: the ordered, specific steps to recover under pressure, so the person doing it at three in the morning is following a rehearsed procedure rather than improvising against a clock during the worst day of their year.
Where it fits
From no strategy to a proven one
An organisation that has backups of a sort (a job somebody set up, a copy on a drive), but no coherent strategy and no confidence in it. We work out what actually needs protecting, agree RPO and RTO per system, build backups to the 3-2-1 rule with off-site and immutable copies, and (crucially), run a restore to prove it works and time how long it takes. The outcome is not just better backups; it is the first time anyone in the business can answer, with evidence, what would happen if a key system was lost this afternoon.
Hardening backups against ransomware
A business that has functioning backups but has realised, often after reading about someone else’s incident, that those backups sit on infrastructure an intruder could reach and wipe. We add immutability and air-gapping so the recovery copies survive a full compromise, separate the credentials that control backups from everyday administrative access, and test that a simulated total loss of the live environment can still be recovered from the protected copies. The change turns ransomware from an existential threat into an operational recovery with a known cost in time.
Meeting a compliance or customer requirement
An organisation facing an auditor, a regulator or an enterprise customer’s security review that asks pointed questions about backup, encryption, retention and disaster recovery, and finding that the honest answers are vague. We put in place the arrangements the requirement demands and, just as importantly, make them provable: documented retention, encrypted backups with managed keys, a written DR plan, and evidence of tested restores. The deliverable is not only a compliant position but the documentation and test records that let you demonstrate it rather than assert it.
Rebuilding confidence after a near miss
A team that has just had a scare. An accidental deletion recovered only by luck, a corruption that a backup restored slowly and incompletely, a drive failure that came closer to disaster than anyone likes to admit. The near miss exposed that the recovery position was far weaker than assumed. We treat it as the warning it is: reassess what could be lost and how fast it must come back, fix the gaps the incident revealed, and prove the fixed position with a real restore, so the next event (and there is always a next event), is met by a rehearsed procedure rather than another lucky escape.
How we approach Backup Solutions
We start with the honest questions before we touch any tooling: for each system that matters, how much recent data can you afford to lose if it fails, and how long can you afford to be without it? Those two numbers (the recovery point objective and the recovery time objective), drive everything and cost real money, so we agree them with the business per system rather than assuming a single target fits your customer database, your file shares and a reporting server that could be rebuilt at leisure. A design that protects everything to the strictest standard is usually a design that wastes money on things that did not need it and, worse, distracts from the systems that did.
From there we build to the 3-2-1 rule and treat the restore as the deliverable, not the backup. Anyone can schedule a backup job; the value is in proving it comes back. So we rehearse restores, time them against the RTO you agreed, and check that the recovered data is actually complete and usable rather than a file that exists but will not open. We harden the backups against ransomware from the outset (immutable copies an attacker cannot delete even with full access), because a backup strategy that a single compromised admin account can wipe is not a strategy, it is a liability with a green tick next to it.
How the engagement runs
We start with what you are protecting and what losing it would cost, not with a product. The opening work is an honest inventory: which systems, databases and file stores matter, and for each one, how much recent data you could afford to lose and how long you could afford to be without it. Those RPO and RTO numbers are agreed with the business, because they drive the design and the cost, and a target nobody signed off on is a target that gets quietly missed. We also look hard at what you have today: where copies live, whether jobs are actually succeeding, whether a restore has ever been done, because the current state is usually weaker than assumed, and naming that honestly is the first useful thing an engagement produces.
From there we build to the agreed targets and the 3-2-1 rule, automate and monitor the jobs, and put the ransomware protections (immutability, air-gapping, encryption, key management), in place from the start rather than as a later hardening pass. Then we do the part that most backup work skips: we restore. We rehearse recoveries, time them against your RTO, confirm the recovered data is complete and usable, and write the disaster-recovery runbook from what we actually did rather than from theory. You finish the engagement not with a dashboard that shows green, but with evidence (a timed, verified restore and a documented plan), that recovery works.
Backup architecture: the 3-2-1 rule
The backbone of a sound backup architecture is a rule old enough to predate the cloud and robust enough to have survived it: 3-2-1. Keep three copies of your data (the live copy plus two backups), so that no single loss leaves you without options. Hold them on two different types of storage or media, so that a failure mode affecting one (a storage array fault, a filesystem bug, a provider outage), does not silently take out your backups along with your primary. And keep at least one copy off-site, physically or logically separated from the primary environment, so that a disaster that destroys or compromises the whole site or account cannot reach it. The most common way this rule is quietly broken is that all three copies turn out to live in the same place: a second folder on the same server, or a snapshot in the same account and region, which reduces three copies to one risk.
On top of that structure we layer the decisions that make it fit your systems. Databases need application-consistent backups: captured so the database is in a coherent, restorable state, not a snapshot taken mid-transaction that restores into corruption, which usually means proper database backup mechanisms and point-in-time recovery rather than a naive file copy of the data directory. Whole-system recovery needs images or infrastructure-as-code that let you rebuild the machine, not just the data on it. File stores need versioned backups so you can recover the state before a corruption or deletion, not just the latest, already-damaged version. And every off-site copy is chosen to be genuinely out of reach of the primary’s failure and compromise, because an off-site copy that shares a credential or a blast radius with production is off-site in name only.
Security: protecting backups from ransomware
Backups are a security problem in two directions at once, and both matter. First, they are a prime target: modern ransomware deliberately hunts for backups and encrypts or deletes them before triggering, because an organisation that can restore does not pay, and an organisation whose backups have been destroyed does. So the central security question we design against is not whether backups exist, but whether an attacker who has gained full control of your environment could also destroy them. If a single compromised administrator account can delete or encrypt the recovery copies, those copies are not protection. We answer that with immutability: backups written in a form that cannot be altered or deleted for a defined retention period, even by an administrator, and with air-gapping, where the critical copies are held on storage that is disconnected or credential-isolated from the systems being protected, so the path an attacker uses to reach production does not also reach the backups.
Second, backups are among the most sensitive data you hold, precisely because a backup is a complete, portable, single-file copy of everything (customer records, credentials, financial data), in one convenient place. A stolen backup is a full data breach with none of the effort of extracting the data piece by piece. So backups are encrypted in transit and at rest, with keys managed properly and kept separate from the backups themselves, because encryption whose key sits next to the ciphertext protects no one. Access to backups and to the systems that manage them is tightly controlled and separated from everyday administrative access, so the blast radius of a compromised account is limited. And retention is treated as a security matter too: keeping backups longer than needed simply widens the window in which an old copy of sensitive data can be stolen. The principle throughout is that a backup is both your escape route from disaster and, if mishandled, a disaster of its own, and it has to be designed for both.
Signs it’s time
- You have no backup strategy, or an unclear one, backups happen somewhere, but nobody can say confidently what is covered, how often, where the copies are, or whether a restore has ever been done
- Ransomware is a real worry and you cannot answer whether an attacker who got into your systems could also reach and encrypt or delete your backups, which, without immutability or air-gapping, they usually can
- A compliance obligation, customer requirement or auditor is asking about your backup, retention and disaster-recovery arrangements, and you need them to actually exist and be provable rather than assumed
- You have just had a near miss (an accidental deletion, a corruption, a failed drive, a scare), and it exposed that your recovery position was far weaker than everyone had assumed it was
Our working method
Our method rests on one blunt conviction: a backup you have never restored is not a backup, it is an assumption, and assumptions about recovery have a habit of failing at the exact moment they are relied upon. So we invert the usual emphasis. Where a lot of backup work ends when the job runs green, ours treats that as the halfway point and the restore as the deliverable. We rehearse recoveries, time them, and verify the data that comes back is complete and usable, because the failure modes that matter, the backup that captured nothing, the database that restores inconsistent, the file that will not open, are invisible until you actually try to restore. Catching them on a scheduled test costs an afternoon; catching them during a real incident can cost the business.
The second principle is that recovery targets are business decisions with real costs, so we make them explicitly and honestly rather than letting them default. Tighter RPO and RTO (less data lost, faster recovery), cost more, sometimes a great deal more, and the right level differs system by system. We would rather spend an hour agreeing that your customer database needs frequent backups and rapid recovery while a reporting server can tolerate a slower, cheaper rebuild than apply one expensive standard everywhere or, worse, under-protect the thing that would actually hurt. And we are candid about the current state at the start: if your backups are not working, or a single stolen credential could wipe them, we say so plainly, because false confidence is the specific thing this work exists to remove.
Technologies we build it with
Chosen per problem, not per fashion. This is the stack we most often reach for on this work.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Want a straight answer on Backup Solutions?
A short call with a senior engineer, before you write a brief. If Backup Solutions is the wrong answer for your situation, we will say so and tell you what we think is right.
What changes
Recovery you have proven
Backups that have actually been restored and timed against agreed targets, so you know (rather than hope), that you can get your data and systems back, and roughly how long it will take.
Ransomware cannot take your escape route
Immutable or air-gapped copies that an attacker with full access to your environment still cannot alter or delete, so an intrusion is a recovery job rather than a ransom demand.
Cost matched to real need
RPO and RTO agreed per system, so you pay for fast, frequent recovery where the business needs it and sensibly less where it does not, instead of over-spending everywhere or under-protecting what matters.
Industries we serve
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
How pricing works
- A backup and disaster-recovery assessment for an existing setup, reviewing what is actually backed up, whether the jobs are succeeding, where the copies live, how exposed they are to ransomware, and whether a restore has ever worked, priced by the scope of the estate, with a clear findings-and-fixes report as the deliverable.
- A fixed-scope design and implementation for a defined set of systems, building backups to the 3-2-1 rule with agreed RPO and RTO, immutability, encryption and retention, and a first proven restore, quoted once the systems and recovery targets are understood.
- A monthly senior engagement for ongoing backup and DR operation, where you want the restore testing actually run on a schedule, the monitoring watched, retention and costs kept in check, and the runbook kept current as your systems change, rather than a one-off setup that quietly drifts out of date.
- The main cost drivers are named up front so there are no surprises: the number and size of systems, how tight the RPO and RTO targets are, how much long-term retention you need, and the storage for the off-site and immutable copies, because those choices, not our time alone, decide most of the ongoing bill.
Typical timeline
- 01
Assessment and recovery targets
One to two weeks taking an honest inventory of what needs protecting, reviewing what you have today and whether it actually works, and agreeing RPO and RTO per system with the business so the design has real targets to meet.
- 02
Backup design and build
Building backups to the 3-2-1 rule (application-consistent database backups, system images or infrastructure-as-code, versioned file backups), with automation, monitoring and alerting on failed or missed jobs so nothing fails silently.
- 03
Hardening and retention
Adding immutability or air-gapping so the recovery copies survive a full compromise, encrypting backups in transit and at rest with managed keys, separating backup access from everyday administration, and setting the retention policy the business and compliance require.
- 04
Restore testing and handover
Rehearsing real restores, timing them against the agreed RTO, verifying the recovered data is complete and usable, writing the disaster-recovery runbook from what we actually did, and handing over so your team can run the tests and recoveries themselves.
What working with us actually means
We test the restore, not just the backup
The whole value of this service is in the part most people skip. We treat a proven, timed recovery as the deliverable and the backup job as merely the means, because we have seen too many organisations discover during a real incident that their backups captured nothing usable. You get evidence that recovery works (an actual rehearsed restore against your targets), rather than a dashboard that shows green and an assumption that has never been challenged.
We design against a real attacker
We do not assume your backups are safe because they exist; we assume an attacker will reach your environment and try to destroy them, because that is exactly what ransomware does. So immutability and air-gapping are designed in against the harsh test: could someone with full control of your systems still not wipe your recovery?, rather than added as an afterthought once an incident has already proven the point at your expense.
We are honest about cost and trade-offs
Faster and more frequent recovery costs more, and we say so and help you spend it where it matters. Instead of selling the most protective design or the cheapest, we agree RPO and RTO per system so you pay for tight recovery where a failure would hurt and sensibly less where it would not. No marketing about total protection, just the trade-offs stated plainly and a design matched to what your business actually needs.
We operate what we build
We run the backup and DR arrangements we design, so the unglamorous disciplines that only matter over time. The scheduled restore tests, the monitoring of failed jobs, the retention that does not silently balloon, the runbook kept current: are treated as the ongoing work they are, not a setup handed over and left to rot. A backup strategy is only as good as the day it is judged, and we build for that day continuously rather than once.
How to engage us
Three ways to work with us on this, chosen to fit the problem, not our margin.
- Dedicated team A standing team that works only on your product, in your rituals and your tooling. Best when the roadmap outlives the project. Ongoing product development
- Staff augmentation Named senior engineers embedded into your existing team, reporting into your leads. Best when you know what to build and need capacity. Filling a capability gap
- Software outsourcing A defined outcome delivered end-to-end by an accountable team. Best when you want the result owned, not just the hours filled. Outcome-owned delivery
Related services
Part of Cloud Engineering. Other work we do alongside this.
Common questions
We already have backups running, why would we need this?
Because having backups and being able to recover are not the same thing, and the gap between them is where organisations get badly hurt. The most common failure we see is not a missing backup; it is a backup that has been failing silently for months, or backing up the wrong thing, or capturing a database in an unusable state, and nobody knew because nobody had ever tried to restore it. A backup you have never restored is an assumption, not a plan. If you can tell us, with evidence, that a full restore has been tested recently, timed, and produced complete and usable data, you may well be in good shape. If you cannot (and most cannot), that uncertainty is exactly the thing this service exists to remove.
What are RPO and RTO, and why do they matter so much?
They are the two numbers that decide how your recovery is designed and how much it costs. The recovery point objective (RPO) is how much recent data you can afford to lose, if it is one hour, backups must run at least hourly; if it is a day, daily is fine. The recovery time objective (RTO) is how long you can afford to be down before the system is back: minutes implies a warm standby ready to take over, while a day allows a cheaper rebuild from backup. Both cost more the tighter you set them, so we agree them per system with you rather than assuming a single target fits everything. Setting them honestly is what stops you either over-spending to protect things that did not need it or under-protecting the systems that would actually hurt the business if they were lost.
Can ransomware encrypt our backups too?
Yes, and that is precisely what it is designed to do. Modern ransomware actively hunts for backups and encrypts or deletes them before it triggers, because an organisation that can restore does not pay the ransom, and one whose backups are gone often has no choice. If your backups sit on infrastructure your normal administrative credentials can reach, then an attacker who compromises those credentials can reach them too. The defence is immutability and air-gapping: recovery copies written so they cannot be altered or deleted for a set retention period even by an administrator, and held on storage isolated from the systems being protected. We design against a deliberately harsh test: could someone with full control of your environment still not destroy your ability to recover?, so that an intrusion stays a recovery job rather than becoming a ransom demand.
How often should backups actually be tested?
Regularly enough that a broken backup is caught on a quiet, scheduled test rather than during a real incident, and often enough to keep pace with how much your systems change. For most organisations that means a full, verified restore test at least a few times a year, plus a fresh test whenever something significant changes: a new system, a major upgrade, a change to how data is stored. A test is not just running the restore; it is timing it against your RTO and confirming the recovered data is complete and genuinely usable, because a restore that finishes but produces an inconsistent database or a file that will not open has told you nothing useful. We build the schedule into how the backups are operated, so testing happens as a matter of routine rather than being remembered only after a scare.
Backups are just copies of data, do they really need this much security?
They need more, not less, than the live systems, for two reasons. First, a backup is a complete, portable copy of everything you hold (customer records, credentials, financial data), packaged conveniently in one place, so a stolen backup is a full data breach achieved in a single grab rather than piece by piece. That is why we encrypt backups in transit and at rest, manage the keys separately from the data, and control who can access them tightly. Second, backups are the target ransomware goes for first, so they need protecting from destruction as well as from theft, which is where immutability and air-gapping come in. Backups are both your escape route from a disaster and, if mishandled, a disaster of their own, and they have to be designed for both, which is why we treat them as some of the most sensitive data you own rather than as an afterthought.
Thinking about Backup Solutions?
Tell us the problem in your own words, not in requirements. A senior engineer reads it and comes back with a straight view on whether Backup Solutions is the right answer here, or what would be.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.