2 posts tagged with "disaster-recovery"

OpenSearch has a native snapshot API that writes index data to remote storage. FoundryDB wraps this API so you can trigger, list, and restore backups without configuring S3 credentials, IAM roles, or snapshot repositories manually. This post documents the backup flow using real metadata from a test run against an OpenSearch 2.19.1 cluster.

All commands use YOUR_SERVICE_ID and YOUR_API_TOKEN as placeholders. The FoundryDB API base is https://api.foundrydb.com.

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.