Backups & Restore

Forgeon’s mdx-service can snapshot your databases automatically and restore them quickly — either in place or to a new environment for safe testing.

What gets backed up

• Block-level snapshots for volume-backed engines (Postgres, MySQL/MariaDB, ClickHouse, Cassandra, FerretDB’s Postgres backend).
• Logical exports when the engine exposes a safe, consistent export mode (optional for Postgres/MySQL).
• Config metadata (connection URLs, ports, engine settings) for fast re-provisioning.
• Not included: external services you connect to outside Forgeon (back them up where they live).

Where to manage backups

• Go to Project → Databases → [your database] → Backups.
• See last run, retention, next scheduled, and the Restore actions.

Default schedule & retention

• Daily automatic snapshots (off by default on Dev, on by default on Production).
• Retention: 7 days on starter tiers; extend to 30/90 days on higher tiers.
• Manual backups are always available and don’t change the schedule.

Engine specifics (how we capture consistency)

Postgres

• Snapshots are taken with the instance quiesced for consistency.
• Optional Point-in-Time Recovery (PITR) using WAL archiving if enabled in settings.
• Logical dumps (pg_dump) available for migration/export use cases.

MySQL / MariaDB

• Volume snapshots coordinated with flush/lock to ensure consistency.
• Optional logical dumps (mysqldump or mydumper) for selective table restores.

Redis / Valkey

• Persistence uses RDB or AOF per your config.
• Backups capture the persisted files; for strict persistence, enable AOF.

ClickHouse

• Volume snapshots; large merges are coordinated. For partial table export, use engine’s table-level backup/restore tools.

Cassandra

• Node snapshots + schema capture; compactions coordinated to reduce repair on restore.

FerretDB

• Backups mirror the underlying Postgres persistence; restore brings back collections as they were.

Qdrant / OpenSearch / Trino / Dremio / QuestDB

• Snapshot or export methods vary by engine/version. We capture volumes where supported; for metadata-only engines (Trino/Dremio), configuration is backed up, not external datasets.

Restoring data

You can restore in place (overwrite current) or to a new database (safer).

Restore to a new database (recommended)

1. In Backups, choose a point (snapshot or PITR time).
2. Select Restore to New → pick Environment (e.g., Staging).
3. Forgeon creates a new database and exposes a new connection URL.
4. Update your app to point to the new URL and verify data.

Restore in place (fastest)

• Choose the backup → Restore In Place.
• The database will be briefly unavailable during the cutover.
• Your existing DATABASE_URL remains valid.

Point-in-Time Recovery (PITR)

• Enable PITR on Postgres/MySQL in Backups → Settings.
• Pick a window (e.g., 24–72 hours).
• We archive write-ahead logs/binlogs so you can restore to any second within that window.

Cross-region safety

• Toggle Cross-Region Copies to store snapshots in a secondary region.
• Restores can target either region; great for disaster recovery drills.

Costs & retention

• Snapshot storage is billed by GB-month; first N GB included on paid plans.
• Longer retention → more storage. Choose a window that matches your audit/SLA needs.

Backup integrity & drills

• We verify snapshot checksums after creation.
• Run a restore drill monthly: restore to a staging database, run basic integrity checks, and rotate the staging DB away.

Best practices

• Separate app/admin users and rotate passwords; backups don’t replace access hygiene.
• Quiesce long-running migrations during backups if your workload is highly write-heavy.
• Encrypt at rest (default for managed storage) and in transit.
• Tag manual backups with a note (“before schema v12 migration”).

Common pitfalls

• Dev DBs not persisted → backups appear but data resets on redeploy. Switch to a persistent tier.
• App hardcodes localhost → restores work but app can’t connect in cloud. Always use the provided host/URL.
• PITR disabled → you can only restore to snapshot times, not the second before a bad migration.

FAQ

Can I download a backup?
Yes — from the Backups tab, choose Export (logical dumps for relational engines, snapshot exports where supported).

How long does restore take?
Depends on size. Small DBs restore in minutes; multi-hundred-GB datasets take longer (we parallelize where engines allow).

Can I restore just one table?
Use logical exports (Postgres/MySQL) to restore specific tables or rows into a staging DB, then copy into prod carefully.

---