Skip to content

[Epic]: DBaaS M1 PostgreSQL Backup, Snapshot, and Point-in-Time Recovery #248

Description

@Yohansenanayake

Description

Deliver an RDS-like backup and recovery experience for PostgreSQL databases in the DBaaS M1 release.

Today, tenants do not have a defined way to protect a managed database, retain durable recovery points, or restore from data loss and operational mistakes. This epic introduces the user-facing APIs and platform behavior required for:

  • automated backups with point-in-time recovery (PITR);
  • durable manual and final snapshots; and
  • snapshot or PITR restore into a new DB instance.

Tenants will provide their own S3-compatible object storage. A BackupRepository will represent one database instance's isolated bucket destination, prefix, and credentials, with an immutable binding to the concrete DB instance UID.

The M1 experience is intentionally narrow, but its API concepts should remain extensible to additional database engines and managed storage integrations in later releases.

Goals / Scope

In scope

  • Define and implement the M1 backup and restore API contract for PostgreSQL.
  • Introduce a namespace-scoped BackupRepository with one-database binding, readiness status, and storage-access validation.
  • Support tenant-owned S3-compatible object storage with isolated prefixes and credentials.
  • Allow DB instances to be provisioned without a repository when automated backups and final snapshots are both disabled.
  • Support automated backups and continuous recovery with a configurable retention period of 1–35 days; 0 disables automated backups and PITR.
  • Support a preferred UTC backup start window.
  • Report truthful backup health and effective earliestRestorableTime and latestRestorableTime values independently of database readiness.
  • Introduce immutable, asynchronous DBSnapshot resources for manual snapshots.
  • Support an optional final snapshot before DB instance deletion.
  • Keep manual and final snapshots until the tenant explicitly deletes them.
  • Remove automated PITR data during source DB teardown in M1.
  • Introduce DBRestore for restoring a snapshot or a selected PITR timestamp into a new DB instance.
  • Ensure a restored DB receives a new identity, endpoint, network and TLS configuration, and fresh credentials before becoming Available.
  • Restore only to the same PostgreSQL major version in M1.
  • Implement retention, garbage collection, status conditions, events, authorization, and failure handling for the supported workflows.
  • Provide end-to-end tests, restore drills, operational documentation, and user documentation.

Out of scope

  • MySQL backup and restore execution.
  • Managed object-storage provisioning through COSI.
  • Native Azure Blob or Google Cloud Storage repositories.
  • Retaining automated PITR data after the source DB instance is deleted.
  • In-place restore or automatic application cutover.
  • Cross-tenant snapshot sharing or copying.
  • Cross-region backup replication.
  • Table-, schema-, or single-database restore.
  • Restore across PostgreSQL major versions.
  • Backup export as a general-purpose data export feature.

Child Issues / Tasks

No response

Design Document

Metadata

Metadata

Labels

Type/EpicDenotes an epic, which is a large body of work that encompasses multiple tasks

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions