PostgreSQL backup and recovery, without unnecessary complexity.

What Acrynite does

You register PostgreSQL connection profiles and S3 destinations once. Acrynite then creates logical or physical backups, records a manifest for every run, and supports WAL-backed recovery in an isolated Docker container.

# public commands in the current release
acrynite database register | list | show | test-connection
acrynite storage register | list
acrynite backup run | list | show
acrynite schedule create | list
acrynite wal enable | status
acrynite recovery-points list
acrynite restore plan | run

Backup capabilities

Physical backups

Physical backups use PostgreSQL's own pg_basebackup to capture the whole database cluster for physical restoration. They are the base for point-in-time recovery.

• pg_basebackup must be on your PATH.
• You need a replication-capable PostgreSQL role and server-level access. An application role normally does not have these rights.
• pg_hba.conf, wal_level, max_wal_senders and max_replication_slots must be compatible with physical backup and replication.

$acrynite backup run --database production --type physical --storage s3-prod-backups

Logical backups

Logical backups use pg_dump to export a database. They suit portability, migration and restoring into another environment. Logical backups are imported through psql into a registered target profile.

$acrynite backup run --database production --type logical --path ./backups/production

Manifests and the backup catalog

Every run gets a unique ID such as bkp_20261023_030000_a1b2. Its manifest records the type, status, timestamps, artifact size, actual destination, PostgreSQL version and cluster identifier when available, and the associated WAL destination for physical backups. Failed runs are catalogued with their error.

WAL archiving and point-in-time recovery

WAL files are PostgreSQL's write-ahead log: a record of every change, written before the change reaches the data files. Archiving those files preserves the history of changes made after a base backup.

Point-in-time recovery restores a compatible physical base backup, then replays archived WAL up to a target time. To recover to a given moment you need the base backup, every WAL segment from that backup up to the target, and a compatible PostgreSQL version.

What Acrynite automates today:

• wal enable configures archive_command to call Acrynite's internal WAL uploader. It is set once per cluster, not per schedule.
• wal status reports the archiving configuration.
• recovery-points list shows known physical base backups and their configured WAL destination.
• restore run --target-time downloads the base backup and WAL archive and starts recovery.

The Acrynite executable and its configuration must be available to the PostgreSQL server process. PostgreSQL may need a restart to activate archive_mode, and Acrynite reports that. Many managed PostgreSQL services do not permit ALTER SYSTEM or custom archive commands.

Storage

$acrynite storage register s3-prod-backups --provider s3 --bucket company-backups --prefix acrynite/production --region eu-west-1

• Credentials. The preferred method is the normal AWS credential chain: environment, shared profile or IAM role. Access and secret keys can be supplied at registration for local setups.
• Association. Each backup run names its destination with --storage or --path, which are mutually exclusive. The manifest records where the artifact actually went.
• Discoverability. A manifest is stored beside each backup artifact, so completed runs stay discoverable after a schedule changes.
• Retention. Acrynite does not delete backup history. Use bucket lifecycle rules to manage retention, and keep base backups together with their matching WAL.

Automation

Schedules run backups on a fixed interval using Go duration syntax such as 6h, 24h or 168h. Creating a schedule starts Acrynite's scheduler daemon, which runs the same validated backup run flow when jobs are due.

$acrynite schedule create production-daily --database production --type physical --interval 24h --storage s3-prod-backups
$acrynite schedule list --status enabled

Each occurrence gets an independent backup ID and manifest. Schedules never own or delete earlier backup history.

Recovery is part of the backup process.

$acrynite restore plan --database production --target-time "2026-10-23T14:30:00Z" --target docker
$acrynite restore run --backup-id bkp_20261022_030000_c3d4 --target docker --target-time "2026-10-23T14:30:00Z" --publish-port 55432

Docker restore today

• Physical restores target Docker only. Docker must be running.
• Acrynite uses postgres:<major> when the source version is known.
• It never overwrites the source cluster and publishes no port unless you ask. --publish-port binds to 127.0.0.1 only.
• Logical restores go into a registered target profile, and Acrynite rejects a restore into the backup's own source profile.

Restore targets other than Docker are future work and are not part of the current release.

Technical architecture

Everything on the left of the storage box runs in your environment. The only external service that receives backup files is the S3 or S3-compatible bucket you configure.