Backups

Postgres has two mechanisms for backups:

• Physical backups are a byte for byte backup of the data on disk. These are included with Crunchy Bridge.
• Logical backups contain the raw data as a set of SQL statements such as CREATE table and INSERTs. You can take a logical backup manually.

Read more about the difference between and logical and physical backups here.

Automated backups

Physical backups are included with Crunchy Bridge clusters automatically. By default, a new backup will be taken once a day. If you have a maintenance window set, the platform will aim to run the backup process during that window, and the process is throttled in order to maintain cluster performance throughout.

For each cluster, a PostgreSQL base backup is captured each day and kept current by streaming the WAL every 60 seconds or 16MB (whichever comes first). 10 days of these backups will be retained by the platform automatically. These backups can be used to restore a fork of your cluster to any minute in its history.

Extended backup retention

By default, Crunchy Bridge automatically captures and retains the most recent 10 days' worth of backups for each cluster. That is included in the price of each cluster. The automated daily backups are stored along with the associated WAL and can be used to create a point-in-time recovery fork of your cluster.

If you would like to retain additional backups beyond the most recent 10 days' worth this can be configured in the Backups tab. When configuring additional backup retention, you will choose the number of additional daily, weekly, monthly, and yearly backups you would like to be retained:

In general, the additional backup retention schedule will align to the following standard calendar points:

• Daily
• Weekly on Mondays
• Monthly on the 1st
• Yearly on January 1st

However, when additional backup retention is initially enabled, the first retained backups will likely fall mid-week, mid-month, or mid-year. Retention of the initial additional backups will be based on the earliest available backup for each time period. As the initially retained backups age out of the retention policy, you will see that subsequent retained backups will align to the calendar anchor points listed above.

Additional backups are collected and retained as you have configured them for as long as your cluster is running. A cluster cannot be suspended while additional backup retention is configured.

If you destroy a cluster, all backups will also be destroyed after 5 days.

Contact support if you'd like to discuss additional considerations with backups.

Accessing your backups

Information about the backups that Crunchy Bridge is currently storing for a cluster can be found under the Backups tab.

You can also view and copy credentials to access your backup files directly. This can be useful for retrieving and storing backups outside of Crunchy Bridge.

Crunchy Bridge uses pgBackRest to manage cluster backups. If you want to download and use the backups created for you by the platform, you will need to use pgBackRest to do so. For more details about downloading and working with your backup files, see Downloading backups and Restoring backups.

Forking from backup

You can create a new fork from any of the backups stored for your cluster by clicking the "Fork from Backup" button. This process will create a new cluster according to the options you specify, and the new cluster will be populated with the data from the backup.

Starting a manual backup

If you'd like to trigger a manual backup, you can do so from the Backups tab or using the CLI or API.

Using the CLI or API for backups

Both the CLI and API have capabilities for managing backups and all the features described above.

Logical backups

Crunchy Bridge does not automatically capture logical backups, but you can capture your own logical backups at any time using pg_dump.