Volume backups cover any data stored in a volume, including embedded databases like SQLite, and can be taken manually or on a daily, weekly, or monthly schedule. Restores can only happen within the same project and environment where the backup was created.

A restore never writes into your existing volume. It creates a new volume from the backup and stages a change that swaps your service onto it. The original volume is kept, and nothing changes for the running service until you review and deploy that staged change. If you discard the staged change instead, the service stays on its current volume and the restored copy sits unattached. That restore flow does not give you a way to mount the copy into a separate test service, so isolated restore testing alongside the live database is not part of it. See Backups for the full restore steps.

Thank you for the explanation.

I have two remaining technical questions specific to embedded PGlite:

1. Does Railway guarantee that volume backups taken while PGlite is actively writing are application-consistent and recoverable, or would the application need to pause database writes or shut down before a backup?

2. Can the new volume created during restoration be attached to a separate test service within the same project and environment, allowing us to validate PGlite recovery without modifying or replacing the original service's attached volume?

I'm looking for a supported recovery-testing procedure rather than only confirmation that volume snapshots are available.

If possible, I'd appreciate clarification from a Railway engineer familiar with volume backup consistency and restoration.

Thank you!

Our backups documentation describes volume backups as incremental, copy-on-write snapshots of the volume's contents. It doesn't describe any coordination with the application running against the volume, so there is no documented guarantee that a backup taken while PGlite is writing is application-consistent.

For restores, the supported flow creates a new volume from the backup and stages a swap onto the original service, and the previous volume is kept unmounted. That flow doesn't include attaching the restored volume to a separate test service, so we don't have a supported procedure for testing recovery in isolation alongside the original service.