Skip to main content

Backup and recovery

CloudBase PostgreSQL backup and recovery are supported by the underlying Tencent Cloud PostgreSQL service. They reduce risk from accidental operations, program defects, and data corruption.

The actual backup policy, retention period, recovery method, and console entry depend on the console. For underlying capabilities, see Tencent Cloud PostgreSQL Backup and Recovery.

Backup types

Common backup capabilities include automatic and manual backups:

TypeDescription
Automatic backupGenerated periodically according to instance policy
Manual backupCreated before releases, migrations, or bulk updates
Point-in-time recoveryRestores to a specified time based on backups and logs. Actual support depends on the console

Before risky operations

Confirm backup status before:

  • Bulk deleting or updating data.
  • Changing schemas, constraints, or indexes.
  • Importing large external data sets.
  • Running data migration or cleansing scripts.
  • Releasing versions that affect core table reads or writes.

Recovery drills

A backup is useful only if it can be restored. Regularly perform recovery drills in a test environment and check:

  • Whether the backup is complete.
  • Whether restored tables, indexes, and extensions match expectations.
  • Whether key row counts and aggregate values are correct.
  • Whether the application can connect to the restored database.
  • Whether RLS policies and account permissions are still correct.

Logical exports as a supplement

For long-term retention or cross-environment migration, use pg_dump to create logical backups.

pg_dump "$DATABASE_URL" \
--format=custom \
--no-owner \
--file=cloudbase-postgres.dump

Logical backups do not replace platform backups, but they are useful for migration, auditing, and versioned initialization scripts.

Notes

  • Recovery usually affects data changes after the target time. Evaluate business impact first.
  • Keep a snapshot or export of the current database before recovery to avoid a second mistake.
  • After recovery, recheck connection strings, account permissions, RLS policies, and scheduled jobs.
  • Data recovery is high risk. Run it during off-peak hours and notify stakeholders in advance.