Backup that actually restores.
3-2-1 backup architecture with immutable retention, quarterly restore tests, and RTO and RPO measured against your business plan. The day you need it is the wrong day to learn it doesn't work.
Backup + DR program scope
3-2-1 architecture review
Three copies, two media types, one offsite. Documented dependencies, retention policies, encryption posture, and immutability windows.
Immutable retention
Object-lock or equivalent so ransomware can't delete what hasn't aged. Default 30-day immutability for general data, longer for regulated scope.
Quarterly restore tests
Not 'list of backup jobs ran'. Actual file, database, mailbox, and VM restores into an isolated environment with documented success / failure.
RTO + RPO measured
Recovery time objective and recovery point objective benchmarked per business system, not assumed. Documented against the cost of downtime.
Microsoft 365 + Google Workspace backup
Native retention is not backup. Third-party SaaS backup (Veeam, Datto, Acronis, etc.) configured to protect against insider deletion, malicious admin, ransomware.
Disaster recovery runbook
Written, tested, version-controlled. Covers email outage, ransomware containment, full-tenant recovery, regional failover. Reviewed annually.
What a backup readiness review delivers
Veeam's 3-2-1-1-0 rule expanded into 10 checks against real evidence. Sample shown, anonymized.
- ✓3 copies of every protected workload· Pass
Production + on-prem repo + cloud repo for tier-1 systems
Evidence: Veeam job report: 100% of tier-1 systems with 3 copies
- ✓2 different storage media· Pass
Disk-based repo + object-storage cloud tier
Evidence: Wasabi S3 immutable tier + local ReFS volume
- ✓1 copy off-site, geographically separated· Pass
Cloud copy in a region >300 km from primary site
Evidence: Cloud copy in EU-Central, primary in EU-West
- !1 copy immutable (object-lock or air-gap)· Warn
Hardened repository or S3 Object Lock with retention period
Evidence: Object Lock at 14 days — recommended minimum is 30 days
- ✗0 backup verification errors· Fail
SureBackup or recovery-verification job passes on every restore point
Evidence: 4 of 12 tier-1 jobs without verification configured
- !Quarterly full-restore test, written record· Warn
A complete restore-to-clean-infrastructure dry-run with documented timing
Evidence: Last test 11 months ago — overdue per policy
- ✓RTO target documented per workload tier· Pass
Recovery Time Objective per system, agreed with the business
Evidence: Tier-1: 4 hr · Tier-2: 24 hr · Tier-3: 72 hr (signed off)
- ✓RPO target documented per workload tier· Pass
Recovery Point Objective expressed in minutes/hours of data loss
Evidence: Tier-1: 15 min · Tier-2: 4 hr · Tier-3: 24 hr
- ✗Backup credentials separated from production AD· Fail
A compromised domain admin must not be able to delete backups
Evidence: Veeam service account is a domain admin — high-risk finding
- ✓Backup repository monitored by SOC· Pass
Alerts route to a 24×7 watched queue, not a shared inbox
Evidence: Veeam ONE → Wazuh → SOC ticketing pipeline live
Standard versions should be verified from the official source before contractual reliance.
Questions before we start.
We have Microsoft 365 — isn't that backed up?
Microsoft retains data for the period defined by their service agreement (typically 30-93 days for various item types). That's retention, not backup. It does not protect against malicious admin, retention-policy changes, or extended ransomware dwell time. Third-party SaaS backup closes that gap.
How often do you actually test restores?
Quarterly at minimum. Annually for full-tenant or full-region DR scenarios. Test results are documented and included in monthly reports.
Do you provide DR-as-a-Service for on-prem systems?
Yes — typically via Azure Site Recovery, AWS Elastic Disaster Recovery, or equivalent for on-prem-to-cloud DR. Cold, warm, and hot tiers depending on RTO requirements and budget.
Start with your domain.
Free passive external assessment. 60 seconds. No signup to start.