Finding out what would actually come back

The situation

A national equipment leasing and logistics company had accumulated four different backup and recovery platforms over time — Veeam alongside NetApp snapshots, ManageEngine for Microsoft 365, Carbonite for endpoint and server protection, and native AWS snapshot and S3 configuration underneath a predominantly cloud-hosted estate.

Each platform reported success. Nobody could say with confidence what was covered, what the retention actually was, whether immutability was configured or merely assumed, or how long a real recovery would take. They also had no consistent standard for documenting their architecture, which made every one of those questions harder to answer than it should have been.

What we did

The engagement was scoped as a fixed 120 hours across three weeks and split into two workstreams.

Workstream A — the audit. We reviewed each platform in turn. For Veeam: backup and snapshot configuration across NetApp and AWS, schedules against business requirements, retention against compliance objectives, and immutability configuration for ransomware resilience. For ManageEngine: Microsoft 365 coverage across Exchange, SharePoint, OneDrive, and Teams, validated against the actual tenant to find gaps. For Carbonite: which servers and which folders were genuinely protected, and the health of DR replication. For AWS: the S3 footprint including lifecycle policies, versioning, object lock, and encryption, plus EBS and RDS snapshot usage and cross-region resilience.

Recovery testing, not configuration review. The distinguishing part of the engagement. We defined a recovery test methodology per platform, executed real recovery tests, and validated that restored data and workloads were usable and intact — not merely that a job had reported success. We measured observed recovery time and recovery point for each platform and compared them against the targets the business believed it had.

Workstream B — documentation standards. We reviewed the existing architecture documentation, gathered requirements on structure and audience, and built a reusable IT architecture documentation template covering network, compute, storage, cloud, identity, backup and DR, and security. Diagram conventions, naming standards, and required metadata were defined, and a representative section was populated using their own environment to prove the template worked in practice.

The outcome

The client received a consolidated written DR audit report covering all four platforms: current-state posture, coverage gaps including workloads nobody realized were unprotected, the measured gap between observed and target recovery objectives, and a prioritized remediation roadmap. Findings were presented to stakeholders and revised with their input.

They also received a documentation template their team could extend, plus guidance on maintaining it. The audit converted the question “are we protected?” from an opinion into a set of numbers — which is what made the remediation budget straightforward to approve.