PostgreSQL-first / Self-hosted

Recovery should not be a gamble.

Turn backups, WAL, integrity and clones into an observable recovery route. Execution stays on your infrastructure.

Verifiable integrity

Manifests and SHA-256 help identify incomplete or modified artifacts.

PITR health

Track the WAL chain, detected gaps and observed RPO per installation.

Isolated restore and delayed standby

Validate in a separate clone or maintain delayed standby to promote in minutes after a logical error.

RECOVERY ROUTE / 01LOCAL CONTROL
SourcePOSTGRESQL
Continuous WALVISIBLE RPO
Physical backupINTEGRITY
Isolated cloneVALIDATED
Observable recovery routeREADY TO VALIDATE

How it works

From production database to recovery evidence

01

Connect PostgreSQL

Install the data plane on your server and register the databases you want to protect.

02

Observe recoverability

Track backups, integrity, the WAL chain, jobs and risks in one dashboard.

03

Validate in an isolated clone

Choose a recovery point, restore separately and confirm the result.

04

Maintain delayed standby

For logical errors, freeze standby replay and promote a safe point without waiting for a full restore.

Recovery Readiness

An existing backup does not mean recovery is possible

DunckOps brings together the signals needed to assess recoverability. Availability of each capability depends on the plan and installation configuration.

Backup and integrity

Track backup execution and validate artifacts with manifests and SHA-256.

PITR health

View the WAL chain, detected gaps and observed RPO within available retention.

Validation restore

Restore into an isolated clone and record the result without destructive rollback on the source.

Delayed standby database

Keep an already restored copy, delayed by 15 minutes to 24 hours, to freeze replay and promote in minutes after an accidental DROP or DELETE.

Jobs and operations

Centralize operational job progress, logs, failures and retries.

Multichannel alerts

Receive operational events through Telegram, Slack, Teams and Discord, according to your configuration.

Context metrics

Correlate recovery risk with connections, WAL, cache, deadlocks, CPU, memory and disk.

Delayed standby database

When production breaks, recovery does not have to start from scratch.

Standby is an already restored PostgreSQL database that applies production WAL with an intentional delay, the same delayed standby pattern DBAs use natively and cloud providers offer as a line of defense. Included in the Assurance plan. Backups and PITR remain essential. Standby prevents RTO from depending on downloading hundreds of gigabytes during an incident.

14:00

Standby up to date

With a 1-hour delay, standby is applying WAL from 13:00. Production is running normally.

15:00

Production incident

DROP TABLE, DELETE without a filter, or the production instance becomes unavailable.

15:05

Operator acts in the dashboard

Logical error: freeze replay. Production outage: apply the remaining archived WAL.

minutes

Standby becomes the usable database

Promote at a safe point. The old primary remains a protected backup; the application uses the new connection string.

Logical error

DROP TABLE customers at 15:00, noticed at 15:05

  1. 1Freeze replay immediately. The destructive command is 5 minutes old; the delay is 1 hour, so standby has not applied the DROP yet.
  2. 2Promote the delayed state (around 14:05). Optionally, promote up to 14:59:59.
  3. 3Point the application to the standby connection string. The old production database is not deleted.

RTO in minutes. No need to wait for the entire backup to be restored from storage.

Production outage

Production container, disk or VPS went offline at 15:00

  1. 1Do not freeze. The goal here is to use WAL already in storage.
  2. 2Choose "Apply remaining WAL and promote": delay drops to zero, standby applies up to the last archived WAL and promotes.
  3. 3RPO is the last confirmed WAL, not the 1-hour delay. If WAL is missing, PITR into an isolated clone remains available.

The database is already running with indexes ready. Recovery time is no longer "fetch backup + full replay".

Where standby fits in the recovery route

Standard replica

Near-real-time copy.

Copies the DROP in milliseconds. Both instances become logically corrupted.

PITR into a clone

Recovers any point within retention into an isolated target.

For large databases, restoring the base backup and applying WAL can take much longer.

Delayed standby

Already restored. Freeze, catch up on WAL or promote. Short RTO for human errors and outages.

Uses disk and CPU continuously. Does not redirect application traffic automatically. Does not replace backup/PITR.

What the operator does in the dashboard

  • Creates standby in the database details with a delay of 15 minutes to 24 hours. Recommended: 1 to 6 hours.
  • Tracks observed delay, last applied WAL and whether replay is frozen.
  • During an incident, chooses to freeze, promote the delayed state, apply remaining WAL or promote up to a timestamp.
  • Promotion asks for the container name. Standby inherits the previous production schedule, retention and WAL interval, restarts archiving and triggers the first backup. The old primary becomes a protected backup.

What this is not

  • Not automatic failover or a DNS switch. The application needs the new connection string.
  • Does not replace physical backups, the WAL chain or restores into isolated clones.
  • There is no universal RPO/RTO. Results depend on the selected delay, archived WAL and host disk.
  • Full-interval protection is available after standby has run for the configured duration.

Execution stays in the self-hosted environment. The commercial cloud does not access PostgreSQL, WAL or standby.

Operational visibility

From backup execution to recovery diagnosis.

Screenshots of self-hosted operations across Production, Staging and Development. RPO and RTO results depend on each installation.

Operations portfolio1/10

01

Operations overview

Projects, databases, jobs and operational signals together in your self-hosted environment.

For PostgreSQL operators

Local control without going back to a collection of scripts.

SaaS on a VPS

Standardize PostgreSQL backups, PITR and delayed standby without handing your data plane to an external platform.

Software companies and MSPs

Centralize risk assessment and operations across projects and installations.

Lean DevOps

Replace fragmented signals with jobs, alerts and evidence in one workflow.

Trust architecture

The commercial cloud is not your data plane.

Accounts, billing and licenses stay in the commercial platform. Databases, credentials, backups, WAL and operational execution remain in your controlled environment.

  • Locally validated RS256 entitlement
  • Customer-selected local or S3/R2 storage
  • Delayed standby, clones and PITR run on the customer host
  • Short validity with a grace period for continuity

Commercial cloud

Accounts, plans, payments, licenses and commercial support.

API + license

Customer environment

PostgreSQL, credentials, backups, WAL, storage and jobs.

Separation of responsibilitiesPrivate key only in the cloudNo operational database in the cloud

Plans

Choose the recovery level you need to prove

Compare databases, installations, retention, PITR, observability and support. Infrastructure and storage are purchased and operated separately by the customer.

Catalog currently unavailable

Plans are loaded from the API to avoid outdated prices. Try again shortly or contact us.

Questions

Frequently asked questions

Does the DunckOps cloud access my databases?

No. The cloud handles accounts, billing, licenses and commercial support. Databases, credentials, backups, WAL and jobs stay in the self-hosted environment.

Can I validate a restore safely?

The supported recovery flow creates a separate clone for validation. Execution depends on prerequisites, storage and the WAL chain available in the installation.

What is a delayed standby database?

An already restored PostgreSQL database that applies production WAL with an intentional delay (15 minutes to 24 hours). Useful for human errors and production outages when a full restore from storage would be too slow.

If production goes down, does the 1-hour standby become the new database?

Yes, through explicit promotion. Standby becomes Primary, inherits the previous schedule/retention/WAL settings, restarts archiving and automatically starts the first backup. The application needs the new connection string; the old primary is not deleted. A new standby can then be created using the same flow.

Does standby replace PITR?

No. Physical backups, the WAL chain and restores into isolated clones remain the complete recovery path. Standby reduces RTO when a usable database must already be running.

Can I change plans later?

Renewal, cancellation and reactivation are available in the portal. Plan and limit changes must be confirmed under the current agreement.

Does the entry plan require payment?

No. The Validation plan is activated free of charge so you can explore the workflow with one database and short retention.

Are infrastructure and storage included?

No. VPS, local or S3/R2 storage and traffic are purchased and controlled by the customer unless an additional service is explicitly contracted.

Are RPO and RTO guaranteed?

There is no universal guarantee. DunckOps reports observed values per installation; results vary with volume, network, storage, WAL and server capacity.

First result

Turn backups into recovery evidence

Start with the Validation plan or choose the recommended plan for production PostgreSQL.

Free Validation plan · 1 database · 1 installation · 3-day retention