What "automated testing" actually means
On a schedule, the appliance spins up a recent recovery point in an isolated sandbox and checks that it boots cleanly - no shared network, no risk to production. If the VM comes up, the drill passes. If it does not, you find out from a log entry, not from a failed restore during an actual incident.
Monthly failover drills, logged
Every appliance, at every site, runs this cycle monthly by default. Each drill is captured with a timestamp, the recovery point tested, boot duration, and pass/fail status - a running record instead of a one-time claim.
Verified RTO, measured not promised
Recovery time objectives are only useful if someone has actually measured them. Each drill records how long the recovery point took to boot and become reachable, so the number on your DR plan reflects a tested result rather than a vendor estimate.
Continuous health monitoring
Backup job health, replication lag, and storage capacity are watched continuously, with alerts raised before a scheduled drill even runs. Problems tend to surface as a warning days earlier, not as a failed recovery test.
Reports you can hand an auditor
Each drill result rolls into a report you can export or hand directly to an auditor - dates, recovery points tested, RTOs observed, pass/fail history. Proof your DR plan works, on paper, without building a spreadsheet by hand every quarter.
Recovery time objectives, by tier
Not every workload needs the same recovery target. Pick a tier, and the monthly drill schedule verifies it holds.
Built on the same recovery engine you already rely on
Automated testing is not a bolt-on - it runs against the same VM recovery and replication pipeline that protects your production workloads, so a passing drill reflects the real recovery path.