Technical disclosure · Recovery

Recovery state is inspectable, not assumed.

A successful backup record is not proof that an application can recover. Korve exposes the configured policy, the observed recovery window, individual recovery points, copy status, and restore state so an operator can test the workflow before making an application claim.

Policy and recovery window

Each managed database has point-in-time, daily, weekly, and monthly retention settings. The live recovery-window operation shows the timestamps that are currently restorable.
Continuous write-ahead-log recovery uses the primary repository. Daily, weekly, monthly, and manual recovery points use separately retained labels.
A longer-lived discrete recovery point does not expire only because the shorter point-in-time window advances.

Independent copies

Optional managed regional copies are independent recovery points with their requested area, status, and retention.
Regional snapshots have a six-hour target RPO. This is an operating target, not a contractual guarantee or availability SLA.
A customer can also configure a compatible customer-owned destination, test access, and create a portable logical or physical export.

Restore and promotion

A restore creates an isolated target instead of overwriting the source database in place.
Promotion is a separate two-step action. The operator previews the binding change, receives a one-use token, and confirms the exact target and binding.
Applications must test their own schema, migrations, secrets, dependent services, and traffic behavior after database recovery.

No published recovery-time objective

Korve does not publish an RTO. Provisioning and full hydration time change with data size, resource class, selected location, and failure mode. Inspect the live operation state and measure a representative restore. Do not convert a benchmark, timeout, or successful test into a contractual recovery-time promise.