This is not a case study. Nobody paid for it, no client environment is involved, and there is no customer on the other end of it to name. It is a system we built for our own infrastructure because we wanted to know whether the backups restore, and this page is the build log. The point of publishing it is simple: you can judge the engineering instead of taking a sentence on a services page at face value.
One question, narrowly: do these backups restore into a machine that boots and responds. Not whether the restore is fast enough, not whether the application inside it is correct, not whether the recovery plan is any good. One question, on a schedule, with a written answer.
Everything runs from PowerShell against the Cohesity cluster's published REST API. The pipeline authenticates, queries which protection jobs have run and which snapshots exist for the machines in scope, selects a snapshot to test, submits a recovery task, and polls until the platform reports it finished or failed.
Nothing of ours is installed inside the backup product. No production snapshot is modified, and the pipeline has no path to delete or expire a production snapshot. It reads state and it requests restores, which is the entire surface it needs.
Whole virtual machines, restored as new objects rather than in place. Nothing is overwritten and the production VM keeps running untouched throughout. The restore target spins up in an air-gapped VMware VLAN with no real internet connectivity. PowerCLI interacts with the isolated VM from outside that boundary.
Restored machines are disposable. After validation, the restored VM is torn down programmatically and verifiably through PowerShell against the Cohesity API.
Once the recovery task reports success, the pipeline powers the restored VM on programmatically and validates the running workload. The complete current monthly assertion list is: SQL Server database health checks; Domain Controller replication checks; Domain Controller diagnostics with dcdiag; and file-server checks confirming files exist at expected catalog paths. The catalog paths are checked programmatically. This is the complete current list, not a claim about every application type.
A machine that boots and answers is a meaningfully different fact from a job that reported success. It is still a long way from a working application, which is covered below.
Every run produces an HTML report matching the reporting style and template used across our automation projects. The report records the validation outcome and failures so they are named rather than counted. No sample report is published.
Elapsed times get recorded because they are useful for spotting drift. They are not published here and they are not a benchmark, since they describe our hardware and cluster and would tell you nothing true about yours.
The limits are the most useful section on this page. A validation system that oversells itself is just a more expensive way to be wrong.
Three stages, and most people should stop after the first one until it has earned the second.
A bounded, paid first engagement. We agree which machines matter, restore them for real, boot them, check them, and hand you a written result. Either way the engagement ends, and walking away afterward costs you nothing further.
If the first proof was useful enough to want again, the same check runs on a schedule and produces a record each quarter. This is a subscription to evidence, not a monitoring contract and not a help desk.
The whole pipeline built into your environment, on your accounts, running without us: restore, boot, assert, report, escalate the exceptions. Version controlled, documented, and handed over with the operating guidance to change it safely.
Tell us the platform, roughly how many virtual machines matter, and when somebody last restored one deliberately. We will tell you what a first proof would involve and what it would not settle.
