Extended Backups for Crunchy Bridge

When we first launched Crunchy Bridge a key theme we wanted to deliver on was production ready Postgres. We made sure we launched with high availability, Postgres major version upgrades, and backups fully included. At that time, and still to this day, our backup mechanism helps to provide disaster recovery. Backups and disaster recovery is still built-in across all Crunchy Bridge plans, even at $10 a month. Folks love that a database on us comes with backups included right out of the box. Our backups work great, they’re solid, and they give you safety with your database– so we haven’t had to revisit our backup philosophy until today.

Today, we’re excited to announce variable backup retention for Crunchy Bridge. Whether you’re in a regulated industry, have internal company requirements, or want additional peace of mind–you can now enable additional backups with variable frequency to provide longer term backup retention for your database.

Extended backup schedules

Each cluster’s backup screen now has additional options for extended backup schedules. The additional backup schedules 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 earlier retained backups age out of the retention policy, you will see that subsequent retained backups will align to the calendar anchor points listed above.

Backups vs point-in-time recovery

Within Postgres when you "backup" a database you typically run some mechanism like pg_dump or snapshot the system in some way. A pg_dump is what is known as a logical backup. This is different from a physical one. You can read more on the differences here, but the short summary is:

• Logical backups are the set of commands used to create the data and corresponding database. As an example it will have several INSERT statements, but for indexes the commands to CREATE INDEX do exist but not the actual existence of the index.
• Physical backups in contrast are the actual bytes represented on disk. This means things like bloat and the full size/existence of indexes on disk is represented.

Of important note when physical backups are combined with Postgres write-ahead-log WAL, you get functionality like point-in-time recovery to roll back to exact moments over a period of time.

At this time, Crunchy Bridge supports full point in time recovery up to 10 days as we only retain enough WAL to restore to the date/time when they completed. Extended backups need to be restored by rebuilding the database. Depending on the size of the database, this can take several hours.

Conclusion

Crunchy Bridge backups provide disaster recovery on all Postgres clusters out of the box, because keeping your data safe is critical to winning your trust as a database provider. We provide 10 full days of point-in-time recovery and today we’re excited to announce that beyond that, we can host backups for years. If you have regulatory requirements around backup retention, internal policies, or simply want longer backups for your own piece of mind we have you covered. See our backup documentation for more details.