PostgreSQL Backup Isn’t Enough: How We Automated Restore Testing

I Automated the Database Restore Drill Nobody Runs Until 3 AM There’s a ritual almost every Postgres team knows. Backups are configured. Alerts are in place. Someone has probably written a disaster recovery document. And somewhere in that document is a sentence that says: “We test restores regularly.” Except “regularly” usually means “when we get around to it.” That’s the problem we wanted to solve with Revenant. Instead of asking someone to remember to run a restore drill every quarter, we wanted the infrastructure to ask the question itself: Can this database actually be recovered? So we built a way to run that check every week, directly from CI. No Go installation. No application code. No ORM integration. No special framework plugin. Just PostgreSQL, a small YAML file, and a GitHub Action. Here’s what the setup looks like. First, define what a healthy restored database means for your application. Create a : You can write the checks yourself, or start from an existing database: Revenant looks at the live schema and generates a starting configuration. You review it. You change the checks that matter to your application. Then commit it to the repository. The important part is that Revenant doesn't need to understand your application. It doesn't care whether you're running Next.js, Django, Rails, or a ten-year-old monolith. It only needs to know what a healthy PostgreSQL database looks like. Then comes the part that makes this useful. Put the validation into GitHub Actions. Add as a GitHub secret. Run it once manually. After that, your repository has a weekly restore validation running automatically. The output is deliberately boring. And that's a good thing. If something is wrong, you don't just get “backup failed.” You get the reason. A table is missing. A critical table is empty. A foreign key is broken. A business query returns unexpected results. The restored data is stale. That's much more useful than discovering the problem at 3 AM. And there's another level. If you're using AWS RDS, you can validate an actual snapshot rather than simply validating the live database. Revenant can restore the latest snapshot into a temporary sandbox, run the same validation checks against it, record the recovery time, and then tear the sandbox down. The workflow is essentially: Restore. Validate. Measure. Delete. If something goes wrong halfway through, acts as the safety net and cleans up orphaned sandboxes. You're not maintaining a second production database. You're renting proof for a short period and then deleting it. That distinction matters. Because disaster recovery isn't really about having a backup. It's about knowing what happens after you click: Restore. We also wanted the tool to be easy to debug before throwing it into CI. So there's a command: It checks configuration, environment variables, and connectivity before you start wondering why your GitHub Action isn't working. And the GitHub Action itself is intentionally simple. It downloads a pre-built Revenant binary from GitHub Releases and runs it. Your CI environment doesn't need Go. Your application doesn't need to change. It's just another CLI running as part of your workflow. Where we are today Revenant is open source and Apache-2.0 licensed. The current releases include: CLI v0.1.1 GitHub Action v1.0.3 PostgreSQL validation checks JSON and Markdown reports AWS RDS snapshot restore validation Commands for , , , , and CLI: https://github.com/277pawan/revenant-cli GitHub Action: https://github.com/277pawan/revenant-action Example workflows: https://github.com/277pawan/revenant-cli/tree/main/examples/workflows But honestly, this is still early. There is a lot more we want Revenant to become. We're thinking about fleet-wide restore drills, scheduled recovery testing across many databases, centralized evidence, signed reports, audit workflows, recovery-time tracking, and eventually a hosted control plane for teams that have outgrown a single YAML file. We don't want to build all of that in isolation. That's where I'm asking for your help. Revenant is open source, and we're actively looking for people who want to contribute. You don't have to build a huge feature. Try it against your own PostgreSQL database. Tell us where the workflow doesn't make sense. Open an issue. Suggest a check you think is missing. Improve the documentation. Add an example. Test it against a setup we haven't thought about. Or, if you're interested in the bigger vision, contribute code and help us shape what this becomes. The roadmap is intentionally bigger than what's shipping today. The more real-world feedback and contributions we get now, the more useful we can make the tool for everyone. Because I don't think “we have backups” should be the end of the conversation. It should be the beginning. **Backups prove you copied the data. Revenant proves you can recover it.** If that's a problem your team has been putting off, try it this week. And if you have an idea for what Revenant should become, I'd genuinely like to hear it. The project is open source. Come build it with us. PostgreSQL #OpenSource #DevOps #SRE #DisasterRecovery #GitHubActions #AWS #RDS #Database #CI #Infrastructure #Backup