Backups
Set a backup policy on each database: a schedule (hourly, every 6 hours, daily or weekly, in UTC), how many days to keep backups, and how many of the newest to keep. You can also start a backup at any time.
- Consistent backups pause the database for the few seconds a snapshot takes, so files are copied at rest. Use these for anything you need to restore reliably.
- Live backups snapshot while running with no downtime, but the restored database may need crash recovery.
Refresh from backup
Refresh replaces a database's data with a consistent backup from another database — for example to give staging a copy of production. The target's existing data is lost. Take a consistent backup on the source first.
Clone
Clone creates a new database instance and restores a consistent backup of the source into it once it is running. Take a consistent backup on the source first. The source is not changed.
Migrate to a newer version
To move PostgreSQL to a newer major version, start a logical export on the old database, wait for it to finish, then use Migrate from logical backup on the new one. The new database's objects are overwritten and the source stays available.
Example: refresh staging from production
- Take a consistent backup of the production database and wait for it to finish.
- Take a backup of the staging database if you need a way to recover its current data.
- On the staging target, choose Refresh and select the production consistent backup.
- After the restore finishes, test the staging connection and expected data.
Refresh overwrites the target. Use Clone when you want a separate new instance instead. For a PostgreSQL major-version upgrade, use a logical backup and Migrate on the new target rather than a physical refresh.