Canonical: [https://chrysisnetworks.com/proof/restore-validation-pipeline]() A system we built for ourselves, documented in full # A backup nobody has restored is a guess. Here's how we test ours. This 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. Built and run by us, with a Cohesity Knowledge Expert behind the work. ## The question it answers 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. Restore-validation pipeline: restore (as a new object), then boot (air-gapped VLAN), then health checks (monthly assertions), then report (HTML, every run), then escalate (the exceptions) - Restore - as a new object - Boot - air-gapped VLAN - Health checks - monthly assertions - Report - HTML, every run - Escalate - the exceptions ### What it calls 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. ### What it restores, and where it lands 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. ### How it boots and what gets asserted 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. ### What the report contains 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. ## What this does not prove 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. - It does not prove your environment restores. It proves ours does, on our cluster, on our hardware, against our data. - It does not prove an application works. Application-level validation is separate and harder, and this pipeline only carries the specific SQL Server, Domain Controller, and file-server assertions listed above. - It does not produce a recovery time objective or a recovery point objective. We will not quote you a recovery time off the back of this, because that number belongs to your environment, not ours. - It does not cover an entire estate. It tests selected machines on a schedule. A sample that passes is evidence, not a guarantee about every VM you own. - It is not an audit and it is not an opinion. Chrysis Networks is not an auditor, is not itself audited or compliance-certified, and renders no opinion on anybody's controls. It produces records. - No auditor, insurer, or regulator has accepted this output as evidence, and nobody should promise you that one will. - It has never been run against Veeam or Rubrik. Only Cohesity has real work behind it here. - It is not a product. There is no hosted version, no dashboard to log into, and nothing to buy on this page. ## What this would look like in your environment Three stages, and most people should stop after the first one until it has earned the second. I ### The assay A one-time Recovery Proof. A bounded, paid 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. II ### Fortify Evidence on a quarter. 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. III ### Refine Unattended, in your hands. 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. ## Find out whether your backups restore before the day you need them. 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. Restore testing is one specialty here. Most of the work is automation, practical AI and infrastructure, and the [homepage]() lays those out. [Ask about a Recovery Proof]()[See the rest of the automation work]() ## Related reading - [Engineering and architecture firms]() - [Specialty and trade contractors]() - [Law firms]() - [Accounting and tax offices]() - [Dental offices]() --- An engineering-led technology partner for small businesses that need custom software, integration, automation, practical AI and infrastructure, delivered as clearly scoped projects without enterprise consulting overhead. Based in Marietta, Georgia. Remote across the US. Resilience through precision. Microsoft Partner · Pax8 Partner [LinkedIn]() [Clutch]() [Crunchbase]() ### Contact - [(770) 649-3525]() - [info@chrysisnetworks.com]() - Marietta, GA 30008 © 2026 Chrysis Networks LLC. All rights reserved. Resilience through precision.