a month ago
Hi, every deployment of my service fails at the container creation stage. The build and image push complete successfully every time, and there are no runtime logs at all. Deploying without the volume attached works fine.
What happened: The service was running normally. I tried to set up a second service in the same project (a cron job meant to back up my database, which lives on the volume). To give that service access to the data, I called volumeInstanceUpdate via the GraphQL API to attach the volume to it. This immediately triggered a redeploy of the main service, which failed. I then reattached the volume to the main service and deleted the second service. Since then, every deployment fails at container creation.
What I observe now: railway status lists the volume twice on the same service, both at the same mount path:
my-service
status: ● Failed
volume: my-volume · /data · 0.2 GB / 4.9 GB
volume: my-volume · /data · 0.1 GB / 4.9 GBThe GraphQL API confirms two volume instances for this volume, both in the same region. Detaching and reattaching via the CLI or dashboard always reattaches both instances. The second instance seems to have existed before (it already appeared in the API with serviceId: null before my manipulations).
My production database is on this volume and I don't have a recent backup, so I want to be careful not to lose any data.
Has anyone run into duplicate volume instances like this? Is there any way to detach or remove a single volume instance without touching the other?
1 Replies
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
Hi, this is fixed. Your volume had two instances attached at the same mount path, a leftover from a bug on our end when the volume was created back on June 8. That duplicate is what made container creation fail whenever the volume was attached. We removed the stale instance and redeployed your service, and it's running again. Your data wasn't touched. We confirmed the live instance holds your current database.
Please take a volume backup soon since you mentioned you don't have a recent one.
One note on your original goal: a volume can only be mounted by one service at a time, so the backup cron can't share it. A better approach is having the cron service connect to the database over the private network (for example pg_dump against the private hostname) instead of mounting the volume.
Railway Team
Status changed to Awaiting User Response Railway • about 1 month ago
Status changed to Solved sam-a • about 1 month ago