Restore a MariaDB volume snapshot to a separate service without changing the source
eagleusacompany-cell
HOBBYOP

4 hours ago

We are evaluating backup and recovery for a synthetic-only MariaDB 13.0.2 pilot. The service uses a persistent volume and has no public database endpoint. We are currently on Hobby; the dashboard says creating backups requires Pro. Before considering an upgrade, we need to verify the recovery procedure.

Can a volume snapshot be restored to a second isolated MariaDB service in the same project and environment, while keeping the original volume mounted and the original service running without redeployment? The backup documentation describes replacing the mounted volume on the original service, which does not meet our requirement.

Please confirm whether an officially supported UI or API workflow exists for this, and provide its steps or parameter semantics. If it is not supported, please state that explicitly. Also, is Railway PITR supported for a custom MariaDB 13.0.2 image, or only the documented MySQL/PostgreSQL images?

This is a technical clarification only. Please do not modify resources, subscriptions, limits or billing. We do not want to convert the database engine or expose it publicly.

Awaiting User Response

1 Replies

Railway
BOT

4 hours ago

No, there is no supported UI or API workflow to restore a volume snapshot into a second, separate MariaDB service. A volume backup restore creates a new volume in the same project and environment, copies the backup into it, and then stages a change that swaps the original service onto that new volume. The original service keeps its current volume until that staged change is deployed. If you discard it, the restored copy just sits unattached, and attaching it to another service is not a supported path.

Point-in-Time Recovery is available only for Postgres and MySQL, and it relies on our own database images to archive continuously. It is not available for a custom MariaDB image. For the supported engines, a PITR restore creates a new sibling service and leaves the source service untouched, which is the separate-restore behavior you described. See Point-in-Time Recovery and volume backups.


Status changed to Awaiting User Response Railway • about 4 hours ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...