a day ago
I’m planning a recovery drill for a non-production MySQL 9.4 service using Railway native volume backups.
Railway’s automated support response clarified that Restore creates a new volume, stages a swap, and leaves the current volume untouched until Deploy. It also stated that if the staged change is discarded, the restored volume remains as an unattached copy.
My remaining question is:
Is there a supported way to attach or mount that unattached restored volume to a temporary/disposable MySQL service—or otherwise boot and read the restored MySQL data—without deploying it over the currently active service?
I understand that restoring the backup directly to a sibling service is not supported through the normal restore flow. I’m specifically trying to determine whether there is a safe way to validate that the restored database actually starts and is readable while leaving the active service and volume untouched.
If you have performed this successfully on Railway, what supported workflow did you use?
I’m only looking for procedural guidance; no project changes are requested.
2 Replies
a day ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 1 day ago
a day ago
Yes, you can create a new MySQL service, and drag the volume over the newly created service to swap volumes to inspect the data. However, you may encounter authentication issues. To fix that: copy down the current MYSQL_ROOT_PASSWORD variable in your old service, and change the MYSQL_ROOT_PASSWORD variable in the newly created temporary service, and redeploy.
a day ago
Yeah, this is doable, create a throwaway MySQL service in the same project/environment, then in its volume settings attach the existing unattached restored volume (don't let it provision a new one) at /var/lib/mysql, deploy that temp service, and poke around to confirm the data's actually there; since you're attaching the restored copy to a brand new service, production's volume and deployment never get touched, just don't use "Swap Volume" anywhere in this since that detaches whatever it's currently sitting on. Once you've confirmed it boots and reads fine, delete the temp service (and the restored volume too if you're done with it), that's basically the same flow Railway support walked someone through on a Postgres restore a few weeks back, same mechanics apply to MySQL.