PostgreSQL backups

RDC Cloud can create a logical backup of the managed PostgreSQL database and store it in a private Cloudflare R2 bucket. Backups use the existing instance and keep its connection information unchanged.

Availability and permissionsCopy Anchor Link

Backups must be enabled by the platform operator after configuring R2. Until then, the Console displays Backups are not enabled for this environment yet. and disables creation.

Project VIEW members can read backup history. Project EDITOR, ADMIN and OWNER members, as well as workspace owners, can request a backup and manage its automatic schedule. The database must be active and have no other resource operation in progress.

Create a backupCopy Anchor Link

1. Select your workspace and project.
2. Open Relational Database and select the PostgreSQL resource.
3. Open Backups and select Create backup.
4. The Console confirms that the request was accepted. Select Refresh to check its progress.

History distinguishes Manual and Automatic attempts and shows the requested, started and completed times, status, archive size and failure details. It does not refresh automatically. Use Previous and Next to browse older attempts.

A Queued or In progress attempt is not a completed backup. Completed means that the worker created and uploaded the archive and recorded it successfully. Failed attempts do not have a completed archive.

Configure automatic backupsCopy Anchor Link

1. Open the database's Backups page.
2. Under Automatic backups, select Enable automatic backups.
3. Choose Daily or Weekly. For a weekly schedule, choose a day of the week.
4. Set the time and an IANA time zone, such as Asia/Seoul or UTC.
5. Select Save schedule and review the next scheduled run.

Select Reload schedule to load the latest saved settings. To stop future automatic backups, clear Enable automatic backups and save. Operations already queued can still complete.

A stopped database or one with another operation in progress skips that scheduled run. After a scheduler outage, RDC creates at most one catch-up backup rather than replaying every missed run. Schedules follow the configured time zone, including daylight-saving changes.

The schedule uses the access of the user who last saved it. If that user loses the required access, automatic scheduling is disabled when checked. Another authorized member can save and enable the schedule again.

RetentionCopy Anchor Link

RDC keeps the latest seven successful automatic backups for each database. Failed attempts do not count toward this limit. Older automatic archives are removed from storage, and their history remains with an Expired status and expiration time.

Manual backups are retained and are not deleted by this policy. Disabling an automatic schedule does not remove its retained backups or change the seven-backup retention policy.

Contents and limitsCopy Anchor Link

The archive contains the selected database's schema and data. It does not include cluster-wide users and passwords, access grants, other databases, server configuration or transaction logs.

• The compressed archive is limited to 1 GiB.
• The dump, archive inspection and upload stages have time limits. A dump exceeding five minutes fails.
• Resource operations, including stopping or deleting the database, cannot run concurrently with its backup.
• Restore, downloads, custom retention policies and point-in-time recovery are not available yet.

Failed attemptsCopy Anchor Link

For a timeout or interrupted worker, check that the database is available and request a new backup. If the archive exceeds the current size limit or failures continue, contact your platform operator. A failed attempt does not change your database connection information.

APICopy Anchor Link

Use your project's public identifier and the resource UUID:

POST /v1/projects/:projectId/relational-databases/:resourceId/backups
GET /v1/projects/:projectId/relational-databases/:resourceId/backups?offset=0
GET /v1/projects/:projectId/relational-databases/:resourceId/backups/schedule
PUT /v1/projects/:projectId/relational-databases/:resourceId/backups/schedule

Creation returns HTTP 202 with the queued operation. The list returns up to 20 attempts, a total count and capability flags. Completed attempts include archive metadata; pending and failed attempts have no archive. R2 credentials and internal object locations are not returned.

Example schedule request for a daily backup at 03:00 in Seoul:

{
  "enabled": true,
  "cronExpression": "0 3 * * *",
  "timeZone": "Asia/Seoul"
}

Only daily and weekly cron schedules are supported. For weekly backups, replace the final * with a weekday from 0 (Sunday) to 6 (Saturday). Schedule lookup returns availability, management permission, the retention count and the saved schedule, or null if none exists. History includes isAutomatic, scheduledAt and archive expiredAt; expiration means the archive is no longer stored.