5 months ago
I pushed a codebase update to my Database volume by mistake instead of the correct service. Since doing that the db service cannot connect to the volume.
Is this data corruption within the db tables or a connection issue between the service and the volume?
There is 236mb file size on the volume which implies there hasnt been any data loss.
Stupidly have no backups of the volume to restore from.
If anyone from railway could advise on how screwed i am that would be great.
Thanks!
2 Replies
5 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open brody • 5 months ago
5 months ago
pretty simple. good news: 236mb still on the volume means your data likely exists. pushing code to the db service probably overwrote config files or the postgres binary, not necessarily the actual data files in the volume.
first thing: don't wipe anything. detach the volume from the broken postgres service and mount it to the filebrowser template to inspect whats there. delete the volume that comes with filebrowser, mount yours at /data, and set USE_VOLUME_ROOT=1 in the env vars. check if the postgres data directory structure is intact (look for base/, pg_wal/, postgresql.conf). if those files exist your tables are probably fine.
if the data files look good, deploy a fresh postgres service, stop it, delete the volume, mount your old volume over its data directory, and start it. postgres should pick up the existing data. if it fails to start, check the logs for specific errors. worst case you can use pg_resetwal or zero_damaged_pages to force recovery, but try the clean remount first. definitely download a backup of the volume via filebrowser before attempting any repairs since recovery attempts can make things worse.
yusufmo1
pretty simple. good news: 236mb still on the volume means your data likely exists. pushing code to the db service probably overwrote config files or the postgres binary, not necessarily the actual data files in the volume. first thing: don't wipe anything. detach the volume from the broken postgres service and mount it to the [filebrowser template](https://railway.app/template/Nan7Bs) to inspect whats there. delete the volume that comes with filebrowser, mount yours at `/data`, and set `USE_VOLUME_ROOT=1` in the env vars. check if the postgres data directory structure is intact (look for `base/`, `pg_wal/`, `postgresql.conf`). if those files exist your tables are probably fine. if the data files look good, deploy a fresh postgres service, stop it, delete the volume, mount your old volume over its data directory, and start it. postgres should pick up the existing data. if it fails to start, check the logs for specific errors. worst case you can use `pg_resetwal` or `zero_damaged_pages` to force recovery, but try the clean remount first. definitely download a backup of the volume via filebrowser before attempting any repairs since recovery attempts can make things worse.
5 months ago
Massively overcomplicated, OP simply needs to redeploy a previous deployment on that service that was the Postgres image.