Restore from Backup
You can restore a database from a previous backup either in-place or to a different cluster.
Note: Choose the resources carefully for your new database cluster. The operation may fail if there is insufficient disk space or RAM. We recommend at least 4 GB of RAM for the new database, which can be scaled down after the restore operation.
Listing all available backups
To restore from a backup you will need to provide its ID. You can request a list of all available backups:
Request
Response
Listing backups per cluster
You can also list backups belonging to a specific cluster. For this, you need a clusterId
.
Our chosen clusterId
is: 498ae72f-411f-11eb-9d07-046c59cc737e
Request
Response
Restoring from backup in-place
You can now trigger a restore of the chosen cluster. Your database will not be available during the restore operation.
The recoveryTargetTime
is an ISO-8601 timestamp that specifies the point in time up to which data will be restored. It is non-inclusive, meaning the recovery will stop right before this timestamp.
You should choose a backup with the most recent earliestRecoveryTargetTime
. However, this timestamp should be strictly less than the desirable recoveryTargetTime
. For example suppose you have three backups with earliestRecoveryTargetTime
from 1st, 2nd and 3rd of january 2022 at 0:00:00 espectively. If you want to restore to the recoveryTargetTime
2022-01-02T20:00:00Z
, you should use chose the backup from 2nd of january.
Note: To restore a cluster in-place you can only use backups from that cluster. If that backup is from an older Postgres version (after a major version upgrade), only the data is applied. The database will continue running the updated version.
Request
Response
The API will respond with a 202 Accepted
status code if the request is successful.
Restoring to a different target
You can also create a new cluster as a copy from a backup by adding the fromBackup
field in your POST
request. You can use any backup from any cluster as long as the target cluster has the same or a more recent version of PostgreSQL.
The field takes the same arguments as shown above, backupId
and recoveryTargetTime
.
Note: A backup is a continuous process, so if you have any ongoing workload in your current cluster, do not expect the old data to appear instantly. If you wish to avoid a slight delay, you need to stop the workload prior to backing up.
If you want a new database to have all the data from the old one (clone database) use a backup with the most recent earliestRecoveryTargetTime
and omit recoveryTargetTime
from the POST
request.
Note: You can use the POST
and fromBackup
functionality to move a database to another region since the new database cluster doesn't need to be in the same region as the original one.
Request
Last updated