Managed Backups
Managed backup is a service where a provider runs, monitors, and — critically — tests your backups, not just configures a backup tool and walks away. The foundation is the 3-2-1 rule: three copies, two media types, one offsite. But the rule covers how many copies exist, not whether they work, and the central truth of modern backup is blunt: a backup that has never been tested is not a backup. Restore testing, not job completion, is what proves recoverability. Two more truths matter: cloud sync is not backup (a real-time mirror propagates ransomware to both copies), and at least one copy must be immutable, because ransomware now hunts and destroys backups before encrypting production. MCSNET runs managed backups from Toronto, tested and immutable, designed around your RPO and RTO.
Key takeaways
- An untested backup is not a backup: job completion proves nothing — only a restore test to a real environment proves your data is recoverable.
- The 3-2-1 rule (three copies, two media, one offsite) is the CISA-endorsed baseline, but it defines how many copies exist, not their frequency or whether they actually work.
- Cloud sync is not backup: a real-time mirror propagates ransomware encryption to both copies — false confidence with zero protection.
- At least one copy must be immutable or air-gapped, because ransomware now actively hunts and destroys network-reachable backups before encrypting production.
- RPO and RTO drive the design — how much data you can lose sets backup frequency, how long you can be offline sets the recovery approach.
Backup is one of those disciplines everyone agrees is important and far fewer actually get right — because the hard part isn’t taking a backup, it’s being able to restore one. The statistic that focuses the mind is that a large share of companies suffering major data loss never recover as businesses. And the uncomfortable reality behind most backup failures is that the organization did have backups; they just had gaps — untested restores, copies ransomware could reach, a sync mistaken for a backup — that only became visible when it was too late. This page is about backup that actually works when you need it: the 3-2-1 foundation and its limits, why testing is everything, and why immutability is now non-optional.
What is managed backup?
Managed backup is a service in which a provider takes on running, monitoring, testing, and maintaining your backups, rather than handing you a tool configured once and presumed to keep working. The reason this is a service rather than a setup is that the distance between “we have backups” and “we can actually recover” is exactly where backup strategies fail — and that distance is only crossed by ongoing work. A managed service implements the 3-2-1 baseline of multiple copies across media types with one offsite, ensures at least one copy is immutable against ransomware, monitors every job and alerts when one fails or runs late, and tests restores on a schedule so recoverability is proven rather than hoped for. It designs all of this around your recovery objectives rather than applying a generic default. The defining quality is accountability: someone is responsible for the backups genuinely working, and that is measured by successful restores, not by jobs that merely reported success. A backup tool is a product; managed backup is the discipline that makes the product trustworthy.
The 3-2-1 rule, and what it doesn’t cover
The 3-2-1 rule is the foundation worth starting from: keep three copies of your data, on two different types of media, with one copy offsite. It is endorsed by CISA as a practical defense, and its logic is that no single failure — a hardware crash, ransomware, human error, a site disaster — should be able to destroy every copy at once. It has held up for decades because the threats it addresses still exist. But it is important to be clear about what the rule does and doesn’t say, because treating it as a complete strategy is a common mistake. The 3-2-1 rule defines how many copies exist and where they sit; it says nothing about how frequently they are made, whether they are recoverable, or whether ransomware can reach them. Those gaps are exactly what modern incidents exploit. The rule is best understood as a starting point — a way to bridge from merely owning a backup tool to having a strategy — onto which the genuinely decisive practices are added: testing, immutability, and objectives. Treat 3-2-1 as the floor, not the finish line.
Why isn’t an untested backup a real backup?
This is the single most important truth in backup, and it is routinely ignored: a backup that has never been tested is not a backup. A job reporting success tells you data was written somewhere; it does not tell you the data is complete, uncorrupted, and recoverable into a working system. Some problems only reveal themselves on a restore or a reboot — and discovering one during a real incident, when the clean recovery point may already be gone, is the most expensive way to learn. Restore testing is therefore the heart of the discipline: actually recovering data to a test environment and confirming it is complete and usable. The sound approach is a tiered cadence — monthly file-level restore checks, quarterly application-level recovery to an isolated environment, and an annual full failover exercise — with CISA recommending you verify you can restore at least seven days of operations. Each test should record the actual recovery time, so your real recovery objective is measured rather than assumed. The principle is simple and absolute: a backup strategy is not healthy because jobs completed, but because restores have been proven to work.
Is cloud sync a backup?
No, and this is one of the most dangerous misconceptions in data protection because it feels like protection while providing none against the threat that matters. Cloud synchronization mirrors changes in real time, so if ransomware encrypts your primary data, the encryption propagates to the synced copy almost immediately and both are lost together. A sync is useful redundancy against a single drive failing, but it is not a backup, because it holds no independent point-in-time copy to recover from once the source is corrupted. A proper cloud backup differs in concrete ways: scheduled snapshots rather than continuous mirroring, independent retention so older clean versions survive, separate access credentials so a production compromise doesn’t reach the backups, and ideally an immutable storage lock. The test is brutally simple: if encrypting or deleting your source also encrypts or deletes the other copy, that copy is not a backup. This is why cloud storage satisfies the offsite requirement only when it is configured as a true backup — scheduled, retained, isolated — rather than a convenient real-time mirror that ransomware will happily encrypt alongside everything else.
Immutability: your backups are now targets
The threat backup defends against has fundamentally changed, and the defense has to change with it. Modern ransomware no longer merely encrypts production data — it actively hunts for and destroys backup copies before triggering encryption, precisely to remove your ability to recover without paying. Against this, a backup that sits reachable on your network, accessible with your credentials, is not a safeguard but a second target: if an attacker can encrypt your production and your backups with the same access, you don’t have a backup at all. Immutability is the answer. An immutable backup cannot be modified or deleted within its retention window, even by a compromised administrator account — typically enforced through object-lock or write-once-read-many policies on storage. An air-gapped copy, physically or logically disconnected from any network, achieves the same protection by being unreachable. This is the reasoning behind the evolution of 3-2-1 into 3-2-1-1-0: one immutable or air-gapped copy added, and zero recovery errors confirmed through testing. In the current threat landscape, an immutable copy is the line between a strategy that survives ransomware and one that merely had backups for the attacker to delete.
| Rule | Copies | Adds | Protects against |
|---|---|---|---|
| 3-2-1 | 3 copies, 2 media, 1 offsite | Baseline | Hardware, disaster, human error |
| 3-2-1-1 | + 1 immutable/air-gapped | Isolation | Ransomware targeting backups |
| 3-2-1-1-0 | + 0 recovery errors | Verification | Untested, unrecoverable backups |
RPO and RTO set the design
Two numbers should drive every backup decision, and most setups that don’t fit their business skipped them. Recovery Point Objective is the maximum data you can afford to lose, measured in time — it answers “how far back is acceptable?” and it sets your backup frequency. A four-hour RPO means backing up at least every four hours; business-critical data usually needs daily backups as a minimum, and high-value data warrants hourly or continuous protection. Recovery Time Objective is the maximum time you can afford to be offline — it answers “how fast must we be back?” and it shapes the recovery approach, because meeting an aggressive RTO may require faster storage, local copies for quick restore, or standby infrastructure. The key clarification is that the 3-2-1 rule does not set frequency — RPO does. The rule defines how many copies and where; RPO defines how often they’re taken; RTO defines how fast you recover. Define both before choosing cadence and retention, because without them you cannot even judge whether your current setup meets your needs. A hybrid of fast local recovery plus offsite continuity frequently serves both objectives at once, which is why it’s a common managed design.
The backup you don’t monitor
A backup process left unwatched degrades quietly, and the gap it leaves is exactly the one attackers exploit. A backup job that fails, or silently starts running late and skipping data, and then sits unnoticed for two weeks, creates precisely the recovery hole a ransomware attack walks through. So monitoring is not optional: the backup platform should automatically alert when a job fails or runs late, rather than relying on someone to check manually. This connects to the testing point — a backup strategy should not be considered healthy just because jobs completed; it is verified through routine checks, automated alerts, and restore testing together. The same applies to the backups’ coverage: as infrastructure grows, a new server or database added without being brought into the backup scope becomes an invisible gap, so coverage has to be maintained, not configured once. Without someone responsible for monitoring, validating, and improving the process, backup readiness erodes over time until the day it’s needed and isn’t there. Monitoring is what keeps a backup strategy from rotting between the moment it’s set up and the moment it’s tested.
Securing the backups themselves
The backups are valuable data and an attack target in their own right, so they need protecting like any other system. Encrypt all backup data, at rest and in transit, so a stolen copy is useless to whoever takes it. Restrict restore permissions more tightly than backup permissions — a subtle but important control, because if an attacker gains write access, tighter restore controls help prevent them extracting or weaponizing the backup data. Harden the backup repository itself with single-use credentials, disabled root access, and removal of unnecessary protocols, so it remains difficult to modify even if a management server is compromised. And treat the backup software as a system that needs patching like any other: backup tools have their own vulnerabilities — a documented authentication-bypass flaw in backup software is a reminder that the thing protecting your data can itself be the way in. The same security discipline applied to production servers applies to the infrastructure that backs them up, because a compromised backup system doesn’t just fail to protect you — it can become the attacker’s path to the very data you were trying to keep safe.
How we run managed backups
With MCSNET, managed backup is run as the tested, monitored, immutable discipline it should be, from Toronto. We implement the 3-2-1 baseline with at least one immutable copy against ransomware, design backup frequency and retention around your defined RPO and RTO rather than a generic schedule, and — the part that actually matters — test restores on a tiered cadence so recoverability is proven, with documented recovery times measuring your real objectives against your assumed ones. We monitor every job and alert automatically when one fails or runs late, so no silent gap opens. We secure the backups themselves — encrypted at rest and in transit, restore permissions locked down tighter than backup permissions, the repository hardened and the backup software patched like any other system. For the infrastructure we run, this covers what matters: mail spools and queues, application and configuration data, and the databases behind your platforms. And it pairs naturally with disaster recovery for the wider continuity picture. The result is backups you can actually restore from, proven by testing rather than trusted on faith.
# managed backups · tested · immutable · mcsnet 3-2-1 3 copies · 2 media · 1 offsite +1 immutable object-lock / WORM ransomware-proof frequency set by RPO · not by the 3-2-1 rule scope mail spools · config · databases restore test monthly file · quarterly app · annual failover monitor alert on job fail / late no silent gaps secure encrypted · restore perms locked tighter truth “jobs completed” is not “can restore”
Why work with us?
Because we treat backup as recoverability, not as jobs that report success. Plenty of providers will set up a backup tool and show you green checkmarks; far fewer test restores on a schedule, make a copy immutable against ransomware that now targets backups directly, design around your actual RPO and RTO, and monitor for the silent failures that open recovery gaps. We do all of that, from Toronto, and we are honest about the truths that sell less comfortably — that an untested backup isn’t a backup, that cloud sync isn’t backup, and that a backup reachable with your own credentials is a second target rather than a safeguard. We secure the backup infrastructure as carefully as the production it protects. For any business where data loss is an existential risk — which, given the survival statistics, is most of them — backups that are proven to restore are not a luxury but the whole point of having them.
Who this is for, and who it is not
It is for organizations whose data loss would be serious or fatal — which, realistically, is most — and who want backups proven by restore testing rather than trusted because jobs went green. It is for teams that understand a sync isn’t a backup, that ransomware now targets backups directly, and that recovery objectives should drive the design. It is for anyone running databases, mail systems, or application data where a clean, recoverable copy is the difference between a bad day and a closed business. It is explicitly not a guarantee that you’ll never need to recover — backups are insurance, and the point is that the insurance pays out when claimed — and it is not a substitute for the disaster recovery planning that handles full-environment continuity, which it works alongside. Nor does it remove your part: defining what data matters and your RPO and RTO is a shared exercise. Managed backup is the data-protection facet of managed services, paired with disaster recovery and database management. Keep three copies with one immutable, design around your objectives, monitor every job, and test the restores — and backup stops being a comforting assumption and becomes the proven ability to get your data back.