Your PostgreSQL volume is still present and attached to the Postgres service in your production environment, with approximately 4993 MB used out of 5000 MB and in a healthy state. No volume deletion was recorded, so no restoration is needed - your data is intact.

I have a PostgreSQL service stuck in an unrecoverable recovery loop with corrupted WAL files. The volume contains ~4.99 GB of critical production data that I need to recover.

Service Details:

• Service ID: 62ca2200-26ed-412f-a4ad-3cebe27a3435
• Service name: Postgres
• Project: firmtracer-production (b7f7a08b-a5c0-47e1-bb46-f87ab5fef983)
• Environment: production (4fb648ac-8e44-4eca-8b6d-f451cb1e67d0)
• Volume ID: 2bb35b0e-0645-4355-8cbd-88adc7a11c9d
• Volume size: 20GB

Problem:

The service was running a broken Docker image that crashed repeatedly. I switched to postgres:18 official image. PostgreSQL is now stuck replaying WAL recovery with errors:

"could not write to file "pg_wal/xlogtemp.28": No space left on device"

"FATAL: the database system is not yet accepting connections - Consistent recovery state has not been yet reached"

Recovery completes the redo phase (~54 seconds) but fails on the final write, even with 20GB volume space available.

What I need:

1. Help recovering PostgreSQL data from corrupted WAL files
2. If recovery is impossible, guidance on salvaging any recoverable data
3. I have NO backups - this is critical production data

Can you help?

Click the volume, go to the settings page, and click "Resize." Redeploy Postgres after.

Volume resized to 20GB and Postgres redeployed. Service now shows ONLINE, but database is still stuck in recovery — still rejecting connections with 'Consistent recovery state has not been yet reached.' Can you help complete the WAL recovery or bypass it?

Go to the console tab of your Postgres service and run df -h /var/lib/postgresql/data.

Is the "Size" field the same as the current allocated volume size?

Update: I've discovered and fixed an issue with the volume configuration:

Problem Found: There were TWO volumes accidentally mounted to the same path (/var/lib/postgresql/data):

Original volume (ID: 2bb35b0e-0645-4355-8cbd-88adc7a11c9d) — 20GB, ~4993MB used

Duplicate volume (ID: 7d7c0b7c-ac44-419e-84f3-7998431d4091) — incorrectly mounted

What I Fixed:

✅ Removed the duplicate volume mount from the service

✅ Deleted the unnecessary second volume entirely

✅ Redeployed Postgres with ONLY the original 20GB volume

Current Status:

Service now correctly mounted to the single 20GB volume

PostgreSQL is still stuck in WAL recovery — still cannot reach "consistent recovery state"

Still rejecting connections with: FATAL: the database system is not yet accepting connections

All Data Intact:

Original volume with all database data is untouched (4993 MB)

pgdata folder never deleted

No data loss

What I Need: Since the WAL recovery is still stuck even with the correct volume and proper space, can you help with:

Advanced WAL recovery techniques or force-start options

Ability to manually inspect/repair the WAL files

Partial data extraction if full recovery isn't possible

Any other recovery methods available on Railway's side

The corrupted WAL files from the previous crashed image are preventing recovery completion. Do you have tools to work with these directly?

^

root@1ed605cab6dd:/# df -h /var/lib/postgresql/data

Filesystem Size Used Avail Use% Mounted on

/dev/zd9024 4.6G 4.5G 3.9M 100% /var/lib/postgresql/data

root@1ed605cab6dd:/# ---- The Issue:

I resized the volume in Railway's system to 20GB ✅

But the Linux filesystem inside the container is still 4.6GB ❌

The filesystem needs to be expanded/resized to use the full 20GB

This explains why PostgreSQL recovery keeps failing — there's literally no space left on the disk to complete recovery (only 3.9MB free).

Need support how to expand the filesystem.

Let me check with the team.