Category: Backups

Almost every company believes it has backups. Very few have a backup that actually saves them the day they need it. The difference doesn’t show up in the day-to-day: it shows up at three in the morning, when the server won’t boot, ransomware has encrypted the files or someone deleted the wrong folder, and it’s time to really restore. That’s when most people discover their backup had been failing silently for months, that nobody had ever tested it, or that it was sitting in the same place as the data they just lost.

This article is about exactly that: why the backup you think you have almost never saves you, and how hiring backup as a service for your business takes the problem off your plate for good. Not with more disks, but with managed backups, monitored and tested by someone whose job is to make sure that, on the bad day, you recover.

The backup you think you have vs. the one that actually saves you

A backup isn’t a file that exists. It’s a process that has to work from start to finish: get created, get stored somewhere safe and—most important of all—be restorable. When any of those three links breaks without anyone noticing, you have the worst possible combination: the false peace of mind of thinking you’re protected when you’re not.

These are the three unhappy endings we see time and time again:

• The backup that fails silently. The job has been erroring out for weeks or months, but nobody checks the alerts. The disk filled up, a password changed, a scheduled task broke. The backup “exists,” but it dates from before everything broke.
• The backup nobody tests. It copies every day, sure. But it has never been restored. The day it’s needed, it turns out the file is corrupt, incomplete, or that the one database that mattered was missing.
• The backup that ransomware encrypts. The copy sits on a USB drive plugged into the server or in a visible network folder. When the attack hits, it encrypts the data and the backup along with it. You had a backup; you had it right next to everything else.

A backup that isn’t tested doesn’t exist. And a backup ransomware can delete isn’t a backup: it’s just one more file waiting its turn.

What backup as a service (BaaS) is and why it takes the problem off your plate

Backup as a service (or BaaS) flips the whole approach on its head. Instead of your company buying disks, configuring software and trusting that someone remembers to check whether everything is fine, you contract the outcome: your data copied, watched over and recoverable—and you leave the how to a specialised team.

The key isn’t the technology, it’s the accountability. A managed backup isn’t “install the software and you’re done.” It’s someone monitoring every job every single day, acting when something fails—before you even notice—and periodically proving that restores work. It’s the difference between having a tool and having a service that answers for the outcome.

For a small or mid-sized business, this changes the equation completely. The backup stops depending on an overloaded employee remembering to check it, and becomes part of your outsourced IT: a professional, documented process with someone behind it. It is, quite literally, outsourcing your IT at the point where getting it wrong hurts most.

What a serious backup has to deliver (not just any copy will do)

Not all backups protect equally. A serious copy—one that survives a fire, a theft, an accidental deletion and a ransomware attack—meets a set of requirements that aren’t negotiable. If your current backup doesn’t tick every one of these boxes, you have a problem, even if you haven’t noticed it yet:

• The 3-2-1 rule. At least three copies of your data, on two different media and with one off-site. That way no single incident—fire, theft, disk failure—wipes out everything at once.
• Immutable, isolated copies. At least one copy that cannot be modified or deleted for a set period, not even with admin credentials. That’s what stops ransomware: even if it compromises your network, it can’t touch that copy.
• Thoughtful retention. Last night’s copy isn’t enough. You need to be able to go back to last week or last month, because many attacks and errors take days to detect. A solid retention policy gives you versions to choose from.
• Encryption at source and destination. The data travels and is stored encrypted. If someone intercepts the copy or gets into the storage, all they find is noise, not your information.
• Periodic restore testing. The requirement almost nobody meets and the only one that truly proves the backup works. Restoring for real, at regular intervals, so you know that on the real day you’ll be able to.

Meeting all of this by hand, every day, in a company that also has its own business to run, is exhausting and unreliable. That’s why it makes so much sense to have a managed service for businesses handle it rather than a homemade procedure.

How long recovery takes: RTO and RPO, what really matters

When something goes down, nobody asks “do we have a backup?” The real question is “when am I working again and how much data have I lost?”. Those two questions have technical names, and they’re the ones that should drive every decision about backups.

• RTO (recovery time objective): how long it takes you to be operational again. Half an hour? A day? Three? Every hour down has a real cost for your business: sales you don’t close, customers left waiting, teams unable to work.
• RPO (recovery point objective): how much data you can afford to lose. If you back up once a day, at the worst moment you lose up to 24 hours of work. If that hurts, you need more frequent copies.

A cheap, unplanned backup usually has a terrible RTO: yes, the data is there, but restoring it and rebuilding the system takes days. Designing your backup backwards—starting from how much time and how much data each part of your business can afford to lose—is what turns a copy into a genuine recovery plan. And that’s exactly what a managed service does: it defines those objectives with you and builds the copies to meet them.

What MagicBoxDesk offers: managed backup as a service

At MagicBoxDesk we set up and manage your backups from start to finish, so you stop worrying about whether they work. We don’t sell you software and wish you luck: we give you backup as a service with someone watching it every day and proving that it restores. It’s contracted with a monthly fee based on data volume, no surprises, as part of your outsourced IT.

Here’s what the service includes:

• Custom design of your backup policy following the 3-2-1 rule, with the RTO and RPO your business needs—not a generic template.
• Immutable, isolated copies that are ransomware-proof, encrypted at source and destination, with one copy always off-site.
• Daily monitoring of every job and proactive alerts if something fails: you hear it from us, not from a disaster.
• Documented periodic restore tests, so you know—with proof, not faith—that on the bad day you will recover.
• Assisted restoration whenever you need it, with our support team getting you back to production as fast as possible.
• A monthly fee by volume, clear and predictable, with no hidden costs and no upfront hardware investment.

The backup doesn’t work in isolation: it fits together with our 24/7 monitoring and the rest of our managed IT services, so your infrastructure is watched end to end. What you gain is easy to sum up: peace of mind, compliance and the certainty that an incident doesn’t turn into a crisis.

Stop trusting your backups to luck

The question isn’t whether you have a backup. It’s whether you’re sure it will save you the day you need it. If answering means crossing your fingers, you already know what to do. At MagicBoxDesk we make sure your backups work, get tested and withstand an attack, so you can get on with your business instead of praying.

Contract your managed backup with MagicBoxDesk. Request a no-obligation quote and we’ll tell you exactly what you need to sleep soundly. If you’d rather talk it through, get in touch and we’ll look at it with you.

The question that really matters about your backups isn’t “are they running?”. It’s “when was the last time you actually restored one?”. In audits, the first gets answered with a calm yes and the second with an awkward silence. That silence is the hole: a backup that runs every night without throwing an error looks like a backup that works, and it isn’t always. You only know once you restore it.

This article is about the part almost nobody does: testing backup restores. Setting up the drill, timing it and finding what breaks in cold blood, not on the day of the fire. Because the backup that has never been restored isn’t a backup: it’s an unverified promise.

The backup that has never been restored isn’t a backup

A backup job that finishes green tells you one thing only: that some data was read and written somewhere else. It doesn’t say the data is complete, that the file isn’t corrupt, that the database is consistent or that you can boot a system from it. “Green” measures the write, not your ability to recover. Confusing the two is the most expensive false sense of security in all of IT.

The day you need to restore is never a quiet Tuesday. It’s three in the morning, with ransomware already inside or the server dead and management asking when invoicing comes back. The worst possible moment to discover the database backup was only half done, that a folder was missing or that restoring 2 TB over your connection takes three days. The restore test exists so those discoveries happen today, cold and at no cost, and not then.

Nobody has a backup problem. Everybody has a restore problem. Most just don’t know it yet.

What a restore test is and how often to run it

A restore test is recovering for pretend so you know that on the real day you actually can: you take a backup, spin it up in a controlled environment and verify that the data is there, is consistent and the system works. It’s not reading the report or checking the file is the size you expected; it’s touching the recovered data and confirming it’s usable. And not all tests are equal: each level tests something different and has its own sensible frequency.

• Restoring a file or folder (monthly). The cheapest drill and the most common in real life: someone deleted something. Recover a file from a week ago and one from a month ago and check that it opens. It validates retention, not just last night’s copy.
• Restoring a mailbox or email account (quarterly). Test recovering a full mailbox or specific messages, especially with Microsoft 365 or Google Workspace, where many people wrongly believe the provider is already backing them up.
• Restoring a full server or application (quarterly or half-yearly). Spin up the file server, the ERP or the database in isolation and verify that it boots and is coherent. This is where forgotten dependencies surface: services that won’t start, licences, connections to other machines.
• Bare-metal or whole-environment recovery (yearly). Rebuild from scratch, as if nothing were left. The real disaster drill: this is where your RTO truly gets measured and the times nobody had ever clocked come out.

The practical rule: the more critical and harder to rebuild, the more often you test. And whenever something relevant changes—a new server, a migration—you repeat the drill. A backup that worked in January may have been broken since the March migration without anyone noticing.

How to set up a serious restore test

A badly done test gives you peace of mind that’s even worse than not testing. “I opened a PDF from the backup and it looked fine” proves nothing. A serious drill is run in an isolated environment, follows a script and produces a measured number, not a feeling. This is our checklist:

• Isolated environment, never production. You restore on a separate network or machine, without touching live systems. Restoring over production “to see if it works” is the best way to turn a drill into a real incident.
• Start from the scenario, not the file. Define which disaster you’re simulating: accidental deletion, lost server, ransomware that encrypted production and the reachable backups. Restore the way you would on that real day.
• Verify the data, not that it “exists”. That the database opens and is consistent, that the figures add up, that the backup date is the one expected. A restored file that won’t open is a lost file with extra steps.
• Time the RTO for real. Measure from “we decide to restore” to “the service is usable”, including what nobody counts: downloading the backup from offsite, decrypting, reinstalling, reconfiguring. That clock is your real RTO, not the one on the brochure.
• Confirm the real RPO. Check how many hours of work you lose with the backup you used. If you copy once a day, the worst case is 24 hours. Make sure management knows that number and accepts it, in writing.
• Document and compare against what was agreed. Record the result and check it against the RTO/RPO the business said it could withstand. If the plan says eight hours and the test says twenty-six, you have a problem to fix today, calmly.

That last point is what makes the exercise useful. Without an RTO and RPO agreed with management, the test has nothing to measure against and stays a technical anecdote. With them, every drill tells you whether you’re inside or outside the margin your business can bear.

Typical failures you only see when restoring

There are failures no backup report catches, because they don’t happen when copying but when recovering. They stay invisible until the day you restore; that’s why the drill flushes them out before they do damage.

• Incomplete backups. The copy runs, but doesn’t include everything: a database is missing, a shared folder or the server that was added eight months ago and nobody put in the job. Green forever; you recover and exactly what mattered is gone.
• Forgotten dependencies. You restore the application and it won’t start because it’s missing a service, a version, a certificate or the neighbouring machine it talked to. Recovering a system is almost never recovering a single server.
• Encryption and lost keys. The backup is encrypted—good—but the key was on the same server that was lost, or nobody knows where it lives. A backup you can’t decrypt is perfectly useless noise.
• Inconsistent data. The copy was taken with the database running and without a consistent dump: the file is there, but corrupt or mid-transaction. You only find out when you try to mount it.
• An unbearable real RTO. Everything’s there and everything’s correct, but restoring it over your internet line takes four days and the business can bear one. You had the backup; you didn’t have the time.

None of these gets fixed by buying more disks. They get fixed by testing: only the drill makes them visible while you can still correct them without rush or losses.

How MagicBoxDesk does it

Testing restores by hand, with judgement and on a regular basis, is exactly the kind of task a company busy with its own work never gets round to: important, not urgent, until the day it’s extremely urgent. That’s why at MagicBoxDesk we run it for you. Our managed backup includes restores tested on a regular basis: we don’t hand you software and wish you luck, we give you a service that answers for the result. We spin your backups up in an isolated environment according to their criticality, verify the data is consistent, time the real RTO and hand you a report with what works and what needs adjusting before it becomes a problem.

All of this fits with our 24/7 monitoring, which watches every backup job and alerts if something fails—you hear it from us, not from a disaster—and with the rest of the managed IT services that make up your outsourced IT. The difference is concrete: you go from believing you’re protected to having the proof, with a date and measured times.

Stop trusting that your backup restores and check it. Request a no-obligation quote and we’ll set up your company’s restore tests so that on the bad day you recover for real, not on faith.