There is no product at the end of this page. No contract, no cloud storage, no monthly subscription and nothing to sign. What there is, is the view from the far end: the bench where the disks turn up after a plan has been relied on and found wanting, which is a vantage point most people writing about backup do not have.
Before any discussion of products, there are two questions that settle what you actually need. How much work can you afford to lose — an hour, a day, a week? And how long can you afford to be stopped — an afternoon, two days, a fortnight? The first sets how often copies have to be taken. The second sets how quickly you have to be able to put them back. Almost every backup argument in a small business is really a disagreement about those two numbers that nobody has written down.
They are not the same question and they have different costs. A nightly copy that takes eighteen hours to restore is fine for a firm that could work off paper for two days, and useless for one that cannot invoice without its system. A snapshot every fifteen minutes is worth paying for where a day of lost data means a day of lost billing, and is pointless where the data changes weekly. Answer both honestly, in a sentence each, and the technical decisions mostly make themselves.
The third question, and the one that catches people out, is: when did you last restore something? Not check that the job ran. Actually take a file out of the backup, open it, and confirm it is what you expected. A backup nobody has restored from is a hypothesis with a schedule attached.
The most common pattern by a distance. A backup job was configured properly, years ago, by somebody who has since left. It reports its status by e-mail to an address that no longer exists, or to a mailbox that nobody reads, or to a monitoring dashboard that stopped being looked at when the person who set it up moved on. Meanwhile the job has been failing — a full destination, a permissions change, a certificate that expired, a source path that moved during a reorganisation — and has been failing quietly for eleven months.
Nothing about this is negligent, which is why it is so common. The system was designed to alert, and the alert worked exactly as designed; it simply went somewhere nobody was standing. In an eight-person firm in Leicester or Loughborough there is rarely anybody whose actual job is to look at the backup, so the check that would catch it is nobody's task and gets done by nobody.
The cheap fix is not technical. Put one person's name against it, put a recurring fifteen minutes in their calendar, and make the task restoring a file rather than reading a status page. If a report has to be relied on, make it a report that arrives whether or not the job succeeded, because a silent failure and a successful run look identical when the notification is only sent on error.
A shared folder that mirrors to cloud storage feels like a backup and behaves like the opposite of one under pressure. Its entire purpose is to make every copy look like the newest copy. Delete a folder and the deletion propagates, promptly and correctly. Encrypt ten thousand files and the encrypted versions replicate, promptly and correctly. The sync client is not failing when it does that; it is succeeding at precisely the thing it was built for.
Most of the major services keep a version history and a deletion recycle bin, and where the retention is long enough that history can genuinely save you. The catches are that the retention window is often shorter than the time it takes to notice a problem, that restoring several hundred thousand files through a web interface is slow enough to be a project in itself, and that the versions themselves count against the same storage quota that just filled up. Know your retention period as a number of days, before you need it.
The distinction worth holding on to: a backup is a copy that does not change when the original changes. If your second copy updates itself automatically to match the first, it is a convenience, and a good one, but it is not the thing that saves you from a mistake or from ransomware. Ransomware recovery deals with what survives an encryption run, and the answer is usually decided in the hours afterwards rather than during.
The backup that was attached the whole time. An external drive permanently plugged into the server, or a network share mapped with write access from every workstation, is inside the blast radius of anything that hits the machine. A power event, a controller fault, a ransomware run or a careless script reaches the backup as easily as it reaches the original. The whole point of the old off-site copy was that something had to be physically disconnected. That principle did not stop being true when the medium changed.
The backup that only holds the files. Somebody dutifully copies the data folders, and in the event they discover the application will not run without its database engine, its configuration, its licence keys, its certificates and the specific version it was installed with. Restoring the documents is an afternoon; rebuilding the system that reads them is a fortnight. Write down what a complete restore actually requires, then check that all of it is somewhere.
The backup that was never tested at scale. Restoring one file works beautifully. Restoring four terabytes over the same connection takes eleven days, because nobody ever multiplied the tested speed by the real volume. This is the failure that turns a bad week into a catastrophic month, and it is the one most easily discovered in advance, because it is arithmetic rather than luck. Time a real restore of a realistic quantity, once, and write the number down.
The old rule survives because it is right and because it is short: three copies of anything you care about, on two different kinds of media, with one of them somewhere else. Nothing has replaced it, and every failure above is a version of one of the three legs being quietly dropped.
Three copies means the original plus two, not the original plus one. Two media means two things that fail for different reasons — a NAS and a cloud account, or a NAS and rotating external drives — rather than two disks in the same box in the same cupboard on the same electrical circuit. And one off-site means genuinely disconnected or genuinely elsewhere, not a second drive on the same desk. A drive that goes home in somebody's bag on a Friday satisfies this better than most cloud arrangements do, provided the rota is real.
Two additions worth making in 2026. Immutability, where the storage will not allow a backup to be altered or deleted for a set number of days, is the single most useful defence against an attacker who has your administrator credentials — and they usually do, by the time the encryption runs. And retention long enough to survive slow discovery: if the corruption started six weeks ago and you keep fourteen days, every copy you hold is already contaminated.
The first hour matters more than the plan did. Stop every scheduled job you own — backups, snapshots, replication, sync clients — because those are the things most likely to overwrite the last clean copy with a broken one in the next few hours, and they will do it exactly on schedule. Then stop writing to the affected storage. A database still committing transactions to a damaged volume is making the reconstruction harder every minute. Then write down what happened and when, because that timeline gets asked about repeatedly and memory is unreliable.
What comes here afterwards is a set of disks. Arrays, NAS boxes, servers and SANs start at from £500 + VAT, rising with the member count. A single drive or SSD is £300 + VAT, NVMe included. Cards and USB sticks are £250 + VAT. A disk out of a CCTV or DVR recorder is £400 + VAT, as is a BitLocker or otherwise encrypted volume. Ransomware is priced on the same hardware bands — £300 + VAT a drive, from £500 + VAT an array — because criminal encryption does not change what the bench physically has to do. The diagnostic is free and closes 2 working days after booking in, and the figure that follows is fixed in writing.
Send member disks only, labelled with their bay order, with a photograph of the front of the chassis, tracked and insured to Cambridge Data Recovery, Compass House, Vision Park, Chivers Way, Cambridge CB24 9AD. Reception takes drop-offs Mon–Fri 9:00am–5:30pm; nobody collects and there is no Leicester counter. The related pages are disaster recovery in Leicester for the business version of the first hour, server data recovery, NAS recovery and data recovery cost. The freephone is 0800 689 0668.
A backup nobody has restored from is not a backup, it is an assumption with a schedule attached. The test is not whether the job reports success. The test is whether you have taken a real file out of it recently, opened it, and found what you expected to find.
Diagnosis costs nothing and finishes 2 working days from the moment Cambridge books your device in. The figure after that is written down and fixed. £250 + VAT a card or stick, £300 + VAT one drive or SSD.