23 days ago
Hi folks,
I went through the steps of creating my Railway db instance and while I can use my app to load data into the tables of the database with API calls, I already had my database populated with all the data needed to begin hosting the application. Using pgAdmin, I connected to the remote databse on Railway and was able to browse the objects it contained and even did some test data loads using the API to make sure that part of my application functioned (it did). I took a backup of my local development database using pgAdmin (4.87 seconds and 14 MBytes compressed backup size) and then tried to restore over top of the remote database on Railway, which took 113 seconds (much faster than making API calls to load the data). However, when I looked at the database node in my project, it report that the database has crashed. It offers me the option to Restart but I'm not sure what that involves, and more to the point, I'd still like to perform a restore from my backup to avoid long data loads and burning compute cycles to make thousands of API calls.
I'd appreciate any tips on how to perform a restore safely that won't crash the database, such as what options I should choose during the creation of the backup, and which ones to choose during the restore operation. Or is this use case not supported in Railway?
Thnaks in advance!
Pinned Solution
23 days ago
The most stable and performant way to migrate data into a Railway PostgreSQL instance is using the native pg_dump and pg_restore command-line tools.
5 Replies
23 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 23 days ago
23 days ago
The most stable and performant way to migrate data into a Railway PostgreSQL instance is using the native pg_dump and pg_restore command-line tools.
23 days ago
An update following several unsuccessful attempt to RESTART and to REDEPLOY. I checked the logs for the database container and these are the log entries from the most recent restart. It looks like my restore operation succeeded but consumed all of the available space, and now each time I try to restart, the database crashes again.
Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/c296d0ae-9230-4d50-a5f9-21e8f8a75d6c/vol_p81gkp55mahar5qb
Certificate will not expire
pgbackrest: volume 433 MiB; sized wal-drop= MiB queue-max=216 MiB
pgbackrest: restore-gate WAL_RECOVER_FROM_BUCKET= POSTGRES_RECOVERY_TARGET_TIME= PG_VERSION=present PG_CONTROL=present RESTORED_MARKER=missing PGDATA=/var/lib/postgresql/data/pgdata
PostgreSQL Database directory appears to contain a database; Skipping initialization
2026-07-29 14:58:28.920 UTC [17] LOG: starting PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
2026-07-29 14:58:28.920 UTC [17] LOG: listening on IPv4 address "0.0.0.0", port 5432
2026-07-29 14:58:28.920 UTC [17] LOG: listening on IPv6 address "::", port 5432
2026-07-29 14:58:28.927 UTC [17] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2026-07-29 14:58:28.937 UTC [50] LOG: database system was interrupted while in recovery at 2026-07-29 14:58:21 UTC
2026-07-29 14:58:28.937 UTC [50] HINT: This probably means that some data is corrupted and you will have to use the last backup for recovery.
2026-07-29 14:58:29.309 UTC [50] LOG: database system was not properly shut down; automatic recovery in progress
2026-07-29 14:58:29.312 UTC [50] LOG: redo starts at 0/209E348
2026-07-29 14:58:30.879 UTC [57] FATAL: the database system is not yet accepting connections
2026-07-29 14:58:30.879 UTC [57] DETAIL: Consistent recovery state has not been yet reached.
2026-07-29 14:58:32.521 UTC [50] LOG: redo done at 0/DFFCDC0 system usage: CPU: user: 0.12 s, system: 0.17 s, elapsed: 3.20 s
2026-07-29 14:58:32.551 UTC [50] FATAL: could not write to file "pg_wal/xlogtemp.50": No space left on device
2026-07-29 14:58:32.561 UTC [17] LOG: startup process (PID 50) exited with exit code 1
2026-07-29 14:58:32.561 UTC [17] LOG: terminating any other active server processes
2026-07-29 14:58:32.562 UTC [17] LOG: shutting down due to startup process failure
2026-07-29 14:58:32.575 UTC [17] LOG: database system is shut down
cesinco
An update following several unsuccessful attempt to RESTART and to REDEPLOY. I checked the logs for the database container and these are the log entries from the most recent restart. It looks like my restore operation succeeded but consumed all of the available space, and now each time I try to restart, the database crashes again. Mounting volume on: /var/lib/containers/railwayapp/bind-mounts/c296d0ae-9230-4d50-a5f9-21e8f8a75d6c/vol_p81gkp55mahar5qb Certificate will not expire pgbackrest: volume 433 MiB; sized wal-drop= MiB queue-max=216 MiB pgbackrest: restore-gate WAL_RECOVER_FROM_BUCKET= POSTGRES_RECOVERY_TARGET_TIME= PG_VERSION=present PG_CONTROL=present RESTORED_MARKER=missing PGDATA=/var/lib/postgresql/data/pgdata PostgreSQL Database directory appears to contain a database; Skipping initialization 2026-07-29 14:58:28.920 UTC [17] LOG: starting PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit 2026-07-29 14:58:28.920 UTC [17] LOG: listening on IPv4 address "0.0.0.0", port 5432 2026-07-29 14:58:28.920 UTC [17] LOG: listening on IPv6 address "::", port 5432 2026-07-29 14:58:28.927 UTC [17] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2026-07-29 14:58:28.937 UTC [50] LOG: database system was interrupted while in recovery at 2026-07-29 14:58:21 UTC 2026-07-29 14:58:28.937 UTC [50] HINT: This probably means that some data is corrupted and you will have to use the last backup for recovery. 2026-07-29 14:58:29.309 UTC [50] LOG: database system was not properly shut down; automatic recovery in progress 2026-07-29 14:58:29.312 UTC [50] LOG: redo starts at 0/209E348 2026-07-29 14:58:30.879 UTC [57] FATAL: the database system is not yet accepting connections 2026-07-29 14:58:30.879 UTC [57] DETAIL: Consistent recovery state has not been yet reached. 2026-07-29 14:58:32.521 UTC [50] LOG: redo done at 0/DFFCDC0 system usage: CPU: user: 0.12 s, system: 0.17 s, elapsed: 3.20 s 2026-07-29 14:58:32.551 UTC [50] FATAL: could not write to file "pg_wal/xlogtemp.50": No space left on device 2026-07-29 14:58:32.561 UTC [17] LOG: startup process (PID 50) exited with exit code 1 2026-07-29 14:58:32.561 UTC [17] LOG: terminating any other active server processes 2026-07-29 14:58:32.562 UTC [17] LOG: shutting down due to startup process failure 2026-07-29 14:58:32.575 UTC [17] LOG: database system is shut down
23 days ago
Use the pg_restore CLI method outlined previously, but add the -1 (or --single-transaction) flag.
Execute the command by replacing the placeholder values with the TCP Proxy credentials found in your Railway project under the PostgreSQL Service -> Connect tab.
pg_restore -h viaduct.proxy.rlwy.net -p 54321 -U postgres -d railway --no-owner --no-acl --clean -1 mybackup.dumpIf it still persists, and if your local backup is safe, Deleting the current crashed PostgreSQL service entirely and Provide a brand new PostgreSQL database service would be your only option.
19 days ago
Thanks for the support. Indeed, the problem was mainly not having sufficient space. I did have to delete the Postgres service to get things to work finally, but now they are working. It turns out I was still able to use the backup file I created with the pgAdmin client but pushing it out to Railway using the pg_restore command. Awarding to @msns-dev
Status changed to Solved dev • 18 days ago