Crunchy Bridge supports point-in-time recovery (PITR), and it is automatically enabled for all clusters regardless of plan or region.
Carrying out a point-in-time recovery means that you are provisioning a new database cluster from an existing one. The new cluster (also referred to as a fork) will be an exact reflection or snapshot of the original based on a selected point in time.
You might use PITR to restore your database backend as it was before a particular point or change that has taken place. The new cluster is created from the latest base backup as of the selected point, and then the Write Ahead Logs (WAL) are “replayed” to bring the cluster up to that precise state. This is critical for disaster recovery since no data or transactions are lost, so the fork is consistent with and can function like the original cluster.
Backups are taken daily for Crunchy Bridge instances. Up to 10 days of backups are available for creating a PITR.
Create a new PITR
On the Crunchy Bridge dashboard, select the cluster for which you want to create a fork. Click “Create PITR (Fork).”
The following will be automatically set up for the fork based on the original cluster:
- Postgres version
- Infrastructure provider
- High availability
You’ll be able to select a different region and instance (plan) for the fork.
One use case for selecting a different region or plan is to compare latency between the original and the fork/s. Or, you may be migrating an application from one provider to another, and are considering migrating your database backend to the new provider as well. You could use PITR to test and compare between the two.
The same pricing and billing rates based on plan, storage, high availability, and usage apply for each fork. The cost per month is displayed in a summary along with the region and plan selected.
Provide a unique name for the fork.
Next, select a recovery point:
a) “Now” will use the most recent backup taken for the original cluster, then replays the WAL to the most recent moment in time.
b) To pick another target time, uncheck “Now” and select the desired date and time in the corresponding fields. The target date can be from or after the oldest available backup (up to 10 days prior).
Once you name the fork, select a recovery point, and provide payment details, you can deploy the fork. The amount of time taken may depend not just on database size but transaction volume as well.
The fork will appear on the dashboard as a cluster under the corresponding team. It can be connected to, and deleted, like any cluster.