RestoreCtl

RestoreCtl started after noticing a recurring problem in production systems: backups were “successful,” but nobody had actually verified whether recovery would work during a real incident. Most teams monitor backup creation. Very few continuously test restore integrity, recovery time, or whether data can actually be recovered correctly. RestoreCtl was built to automate restore drills for PostgreSQL backups inside isolated environments, validate integrity, measure real recovery time, and generate audit-ready reports, without requiring agents or a hosted control plane. Currently focused on PostgreSQL pilots and actively looking for feedback from DevOps, SRE, and platform engineering teams.

Strong positioning: testing the restore path is where most backup plans fail. A trend view for RTO over time and backup size would be especially useful for SRE teams, with alert thresholds when drill duration or verification failures regress. That would make the reports useful for capacity planning as well as audits.

The 'ephemeral isolated restore + real RTO measurement + cryptographic integrity check' combo is the right approach. Most teams treat a successful pg_dump as 'backup done' and never measure actual restore time until an incident forces them to. Audit-ready PDF/JSON for SOC 2 evidence is a smart touch too. Does the measured RTO scale with data volume, so you can see how recovery time grows as the DB gets bigger?

Restore drill automation is the part of backup strategy most solo teams skip until it's too late. "We have backups" and "we've verified the restore works and measured how long it takes" are very different claims, this closes that gap nicely.