Backups

Cubeship backs up the databases it runs — Postgres, MySQL, MariaDB and MongoDB — and the instance itself. Redis is left out on purpose.

What a backup is

A logical dump, and only that: pg_dump, mysqldump, mariadb-dump, mongodump, each run inside the database's own container. It is the one kind of copy that works the same across the engines, survives a major version changing under it, and comes out as a single stream that can be sent somewhere else — the only property that makes any of this a backup.

What it is not: a copy of the data directory (fast to restore, pinned to the exact version, and corrupt if taken while the engine runs) or continuous archiving (WAL, binlog — a different product). Each engine's page says what its dump promises: Postgres and the MySQL family give one transaction, MongoDB one collection at a time.

Where it goes

An object store you have linked, streamed straight into the bucket without landing on this box's disk — or, with nothing linked, this machine's own disk, which works the minute the instance is installed and is not a backup. Every screen showing a local dump says so.

Statuses

A failure keeps the row. A backup that did not happen is the thing somebody most needs to find out about, and a row that vanished on failure would be a schedule that looks like it is working.

Where it is on the dashboard

• The database's Settings → Backups tab: the schedule, Back up now, and that database's own history, polling while one is in flight. Restore and download live here.
• Backups under Platform: coverage — one row per database, worst first — and the backups of deleted databases.
• Settings → Backups: the instance's own.

Roles

All of it is an admin's. A dump is every row in the database, so somebody who may take one may read everything it holds, and a restore replaces all of it. There are no MCP tools and no CLI commands for backups in this release; the API is under /backups.