Skip to content

Database Backups

Database backups are configured per database service from the Backups tab.

EngineBackup toolFormat
PostgreSQLpg_dump -Fcpg_dump custom
TimescaleDBpg_dump -Fcpg_dump custom
MySQLmysqldumpSQL
MongoDBmongodump --archive --gzipgzip archive
Redisredis-cli --rdbRDB

ClickHouse backups are not available yet.

Aeroplane creates a local backup file first. Then it follows the selected destination:

  • disk: keep the local file.
  • r2: upload to R2, then remove the local file.
  • disk+r2: keep the local file and upload a copy to R2.

If disk+r2 is selected and the R2 upload fails after the local backup exists, Aeroplane marks the backup succeeded on disk and records the R2 error.

If r2 is selected and upload fails, the backup fails.

Disk backups live under:

DATA_DIR/backups/{serviceId}

The filename includes timestamp, service slug, engine, and backup ID.

Local disk backups are fast and easy to restore, but they are still on the same server. Use R2 or disk+r2 when you need off-server recovery.

Automatic backups are off by default for database services unless you enable schedules during onboarding. Daily, weekly, and monthly schedules can be toggled individually per database service from the Backups tab.

Aeroplane runs:

TriggerIntervalRetention
Daily24 hours6 days
Weekly7 days31 days
Monthly30 days90 days

The scheduler starts after the control plane has been running for about 60 seconds, then checks hourly.

Click Create backup from the database Backups tab to create a manual backup immediately. Manual backups use the selected destination unless you choose a specific destination for that run.

Use manual backups:

  • Before imports.
  • Before application migrations.
  • Before database redeploys.
  • After a successful Railway import.
  • Before deleting old services or volumes.

Each backup records engine, status, trigger, storage target, format, local path, R2 key, size, checksum, error, and timestamps.

Checksums are used when restoring or validating bundle database dumps.