Database Postgres-vQrD with volume direction-volume

It's either an internal backup/restore failure inside Railway's System and you will have to contact Railway's Team, or you did something wrong and the backup ended up having no data.
All I can advice is for you to check if the Data is on a different Schema.

idk how i doing it wrong because volume has

/var/lib/postgresql/data

as it should and i just tap on 'create backup' button

How can i contact ralway's team except this place?

I try doing the same with staging environment on new clear database and all works properly

in my case in production it create a volume but not suggest it mount to where i tap restore. so there really some strange bug in railway backups

sometimes when you restore using volumes it actually gives you an empty one, especially if it's from a different environment

what I’d try:

check if the backup is from the same environment you’re restoring to

create a new env and attach the volume there manually, just to see if any data is inside

if still empty, then maybe the backup didn’t store the data right or got linked to a wrong volume

also if you’re trying to move data from one postgres to another, using pg_dump + pg_restore is usually safer than volumes

hope that helps.

Yea now i know that pg_dump is safer))

The environment/project the same

from interesting parts i see on metrics on volume an looks like the size it the same (but where my data )

Yea... probably it broken. Interesting that i try to backup+restore on stage and it works correctly (attach new restored volume to the pod but in production it didnt do it)

If the backup worked fine on staging but didn’t show up on production, there’s a chance the production service already had a volume attached before the restore — which can cause the new one to get ignored or overwritten depending on timing.

Sometimes just deploying the service triggers a new volume mount, especially if no volume is detected in the config yet.

You can test this by creating a clean test service and attaching the restored volume there. If the data shows up, then the backup is fine and the issue is just with how production handled the mount.

This helps isolate whether the problem is in the volume itself or how the service picks it up.