I'm Building an Open-Source PostgreSQL Backup and Recovery Tool. Help Me Test It.

Pop_Star💫 — Mon, 26 Oct 2026 22:53:30 +0000

Tags: #postgres #opensource #golang #devops

Database backups are one of those things you don't fully appreciate until you actually need to restore one.

Taking a backup is one thing. Knowing that you can recover your database after accidental deletion, a failed deployment, or data corruption is another.

That's the problem I've been working on with Acrynite, an open-source PostgreSQL backup and recovery tool.

I'm now looking for developers to help test it before its broader public release.

Why I'm Building Acrynite

I've been exploring PostgreSQL backup and recovery, and one thing that stood out to me is that backing up a database and recovering it to a useful state are two different challenges.

A backup file alone doesn't necessarily give you the recovery flexibility you need.

For example, imagine your database is working perfectly at noon. At 2:30 PM, a faulty migration or accidental query deletes important data.

Ideally, you want to recover the database to a point before that incident without losing all the valid transactions that happened earlier in the day.

That is where PostgreSQL's Write-Ahead Logging (WAL) and point-in-time recovery (PITR) become important.

I wanted to build a tool that makes these backup and recovery workflows easier to manage through a CLI.

What Is Acrynite?

Acrynite is an open-source PostgreSQL backup and recovery tool I'm building in Go.

The current direction includes:

Physical backups: Back up a PostgreSQL cluster using PostgreSQL's physical backup capabilities.
Logical backups: Create logical dumps for use cases such as database migrations and selective recovery.
WAL archiving: Preserve the WAL segments needed to support recovery beyond the time of a base backup.
Point-in-time recovery: Recover a physical backup to a requested time when the necessary base backup and WAL history are available.
Multiple storage destinations: Support configured storage destinations for backup files.

The goal is to make the operational workflow straightforward, from registering a database and configuring storage to running backups and recovering data.

Acrynite is still evolving, and I'm working through the implementation and testing of its recovery workflows. These capabilities need to be validated across different environments, not just my own.

Why I Need Other Developers to Test It

So far, I've been building and testing Acrynite in my own environment. But that only tells me so much.

I want to find out what happens when someone with a different setup tries to use it.

Can they install it without needing personal guidance? Are the commands intuitive? Does the backup reach the intended destination? Can they restore it successfully? What happens when a configuration is wrong or a recovery prerequisite is missing?

These are the things I'd like to learn over the next one to two weeks.

I'm looking for PostgreSQL users, backend developers, database administrators, DevOps engineers, and open-source contributors who are willing to try the tool and share honest feedback.

You don't need to contribute code. Testing, reporting bugs, pointing out confusing documentation, and suggesting improvements are all valuable contributions.

What I'd Like You to Test

If you decide to participate, here are some useful starting points:

1. Installation and configuration

Try setting up Acrynite and registering a PostgreSQL database. Let me know where the instructions or commands are confusing.

2. Backup workflows

Try the supported physical and logical backup workflows. Verify that the backup completes and that the resulting files reach the configured storage destination.

3. Restoration

Try restoring a backup into an isolated development environment. A backup is only useful if it can actually be restored.

4. WAL archiving and point-in-time recovery

Where the required configuration is supported, test WAL archiving and recovery to a specified point in time. I'm particularly interested in failures, missing WAL segments, and cases where the requested recovery point is not reachable.

5. Developer experience

Tell me what you'd change about the CLI commands, flags, error messages, documentation, or overall workflow.

You can report issues directly on GitHub or join the community to discuss your experience with other testers.

How to Get Involved

Here are the links:

GitHub repository: https://github.com/bendev-w/acrynite-cli/
Discord community: https://discord.gg/V6G3mz5wk

You can explore the code, follow the setup instructions, report bugs, and suggest improvements.

I'm hoping to spend the next one to two weeks working through feedback, fixing issues, and improving the experience before a broader public release.

One important note: Acrynite is still in its testing phase. Please use disposable development databases and non-critical data. Don't use it as your only backup solution or rely on it to protect production databases during testing.

I'd Also Like to Hear From You

If you work with PostgreSQL, I'd be interested in hearing about your own experience.

What do you currently use to back up your PostgreSQL databases?
Have you tested restoring to a specific point in time?
What's the most frustrating part of your current backup and recovery workflow?
What would you expect from a CLI tool designed to simplify this process?

I'm building Acrynite in the open, and I want it to solve problems developers and teams actually encounter.

If this sounds interesting, give it a try and let me know what you think.

Thanks for helping me make Acrynite better.