Hello,

Can you please provide a link to the database in question?

Hi Brody!

This is the Postgres - https://railway.com/project/5d80c235-08bf-41c1-a5c4-4e23475370d5/service/ab43ca9c-a18e-49d6-a6bb-25b3126cb4a6/settings?environmentId=2271318a-172b-436f-baab-5915d26defef

Can you help me restore the latest backup that we have (2026-02-20) and mount it correctly?

Thank you kindly!

The issue is that you incorrectly mounted the volume to your database back in May 2025, and ever since then, the database has been writing to the ephemeral storage and not the volume storage, so when you restored the volume backup, it was empty since the volume hasn't had data in it.

Unfortunately, we cannot help in this scenario, as we are not at fault for the data loss.

The issue is that you incorrectly mounted the volume to your database back in May 2025, and ever since then, the database has been writing to the ephemeral storage and not the volume storage

Okay, I didn't know that, so that's why the restore didn't work. I did see some error messages when postgres first crashed:

```Railway volume not mounted to the correct path, expected /var/lib/postgresql/data but got /var/lib/postgres```

We still have the original volume (https://railway.com/project/5d80c235-08bf-41c1-a5c4-4e23475370d5/volume/e4230156-67a7-4167-9f6b-00ca3f4608e6/metrics?environmentId=2271318a-172b-436f-baab-5915d26defef) prior to the restore, can we start with that, maybe ? I tried to mount it to a newly spun PG to see if it would work. I haven't been able to remove things since we updated this workspace to Pro, that's why we have these detached volumes.

Some of the volumes do seem to have data in them, so there's something there, right ?

You are only a member of the project. Ask the workspace administrator to add you to the workspace as an admin as well.

As for getting your data back, I'm sorry, but we cannot help in that regard.

WTF. This is so bullshit. How was I supposed to know the specific mount path that PG wanted in order to be happy, which varies from distro to distro ? Why is it even an option to run a database on an ephemereal volume? So we lost everything ?

Well, you guys are gonna lose my client as a Pro customer and I'm never recommending Railway to anyone ever again.

If our volumes are all empty how come it shows ~198mb of disk space used on several of them? I refuse to believe that this is an unrecoverable situation.

~198 MB is filesystem overhead.

You are right to question why we allow running a database with ephemeral storage, and we don't, at least not anymore. We fixed that in May 2025, but this database was deployed on April 16, 2025.

Due to the misconfirmation, this is unfortunately not a recoverable scenario.