3 posts tagged with "pitr"

Babelfish stores everything in a standard PostgreSQL database (babelfish_db). Your T-SQL schemas, tables, stored procedures (compiled to PL/pgSQL internally), triggers, and views are all PostgreSQL objects underneath. This means the backup story for Babelfish is exactly the backup story for PostgreSQL: pgbackrest, WAL archiving, and point-in-time recovery.

This post documents how backups work on a live Babelfish 4.8.0 instance, using confirmed results from FoundryDB staging.

Every managed database service on FoundryDB gets automated backups from the moment it starts running. There is nothing to configure, no S3 bucket to provision, and no cron job to maintain. Backups run daily, are encrypted before they leave the server, and are stored in object storage across a separate availability zone.

But automated daily backups are only half the story. For PostgreSQL, MySQL, and MongoDB, FoundryDB continuously archives write-ahead logs (WAL), binary logs (binlog), or oplogs to enable point-in-time recovery (PITR). This means you can restore to any specific second within a 7-day window, not just to the last daily snapshot.

This post covers how backups work across all engines, how to trigger and restore them, and how to use PITR to recover from the kind of mistakes that daily snapshots cannot fix.

MongoDB is one of the most popular document databases in the world, but running it in production comes with real operational overhead: replica set initialization, oplog sizing, backup orchestration, WiredTiger cache tuning, and disaster recovery planning. FoundryDB handles all of this out of the box, so you can focus on your application logic.

This post walks through provisioning a MongoDB service, running aggregation pipelines against it, and recovering from data loss using oplog-based point-in-time recovery.