What does the 3-2-1 backup rule actually mean?
Three copies of your data, on two different media types, with one copy off-site. That's the rule. Most shops we audit have one copy (the production data), call the backup software's local snapshot the second copy (it's not — same disk, same room, same fire), and have nothing off-site. The architecture we deploy is: Tier 1 local NAS for fast recovery (sub-hour RPO) and Tier 2 nightly encrypted off-site replication on every engagement, plus Tier 3 immutable cloud copy with AWS S3 Object Lock in compliance mode for clients with regulated-data or cyber-insurance requirements.
Doesn't Microsoft 365 back itself up?
No — and Microsoft is explicit about this in the shared-responsibility model. M365 protects against infrastructure failure on their side. It does not protect against a user (or attacker) deleting mail, a SharePoint site getting wiped, OneDrive being encrypted by ransomware, or a former employee's data being permanently lost after their license is reclaimed. Those are your responsibility. We add Veeam Backup for Microsoft 365 (Exchange Online, SharePoint, OneDrive, Teams) as the standard add-on for any M365 client.
What is S3 Object Lock and why does it matter for ransomware?
S3 Object Lock in compliance mode is AWS's WORM (write-once, read-many) feature: once a backup object is written, it cannot be modified or deleted by anyone — including the AWS root account, including someone with our credentials — until the retention clock expires. That's the property ransomware operators have learned to defeat by stealing backup credentials and deleting the backups before they encrypt production. Object Lock makes that attack mechanically impossible. It's the standard we deploy as Tier 3 for any client whose cyber-insurance carrier or regulator asks about immutable backup.
How often do you test that the backups actually restore?
Quarterly, documented in your monthly health report. The test isn't "did the backup job complete" — every backup tool reports green when nothing useful was captured. The test is: pick a real file, a real database, or a real VM, restore it to an isolated environment, verify integrity, and time the restore. The architecture is built so that the moment of need is never the first time the chain runs end-to-end — it's tested every quarter, on schedule, with the results in your monthly report.
What are RTO and RPO and what should mine be?
RPO (Recovery Point Objective) is how much data you can afford to lose — the gap between the last backup and the failure. RTO (Recovery Time Objective) is how long you can afford to be down. For a typical small business, our targets are RPO under 1 hour for production data and RTO under 4 hours for a full environment restore. Mission-critical workloads can be tighter (RPO 15 min, RTO 1 hour) by adding warm replication. Both numbers are documented per-workload in your runbook so "how bad is this" has an answer the day of the incident.
If we get hit by ransomware, how fast can you have us back up?
For a normal small-business environment with the full 3-tier backup architecture deployed, a typical recovery target is: 1–2 hours to contain and isolate (Huntress automation does most of this), 2–4 hours to restore the immutable Tier-3 copy to clean infrastructure, and 4–8 hours to validate and bring users back online — so back inside one business day. The tail (forensics, insurance reporting, full root-cause writeup) takes longer. The key variable is whether the backup is actually clean and untouched — which is the entire reason we deploy an immutable Object Lock tier on any engagement where ransomware survival matters.
