Our supported restore flow restores onto the original service. Restoring a backup creates a new volume in the same project and environment, then stages a change that swaps the service's current volume for the restored one. If you discard that staged change, the service stays on its current volume and the restored copy sits unattached. We don't have a supported sequence for attaching only that copy to a separate, isolated test service, and keeping the unattached copy doesn't give you a recovery-testing workflow on its own.

A volume backup is a point-in-time snapshot of the whole volume, taken at the storage level, so treat it as crash-consistent, not application-consistent. We don't pause your app, coordinate PGlite transactions, or flush application memory when the snapshot is taken. Whether a snapshot taken mid-write recovers cleanly depends on PGlite's own crash recovery and durability settings. A clean database shutdown isn't part of our snapshot process, so if you need application-consistent backups, that guarantee has to come from how your application handles writes and shutdown.

Thank you for clarifying the snapshot behaviour. I understand that a storage snapshot does not guarantee application consistency or successful PGlite recovery.

Could a member clarify the isolated-restore point? In this thread, a moderator explains that an unattached restored volume can be dragged onto a temporary service:

https://station.railway.com/questions/how-to-attach-existing-unattached-restor-a6ccbf18

Is that method currently supported for attaching only the restored copy to a separate test service in the same project/environment, while leaving the original service and its volume unchanged?

If yes, could you confirm the supported sequence, including how to discard the original-service swap without losing the restored copy? Our test service would run the matching PGlite version, not a PostgreSQL server.

If not, what supported method allows us to test recovery without replacing the live attachment?

This is a guidance request only; we have not initiated a restore.

We don't currently support attaching only a restored copy to a separate test service as a recovery-testing workflow, including within the same project and environment, so we can't confirm that sequence as a supported procedure.

The part we can confirm is what happens to your live setup. A restore creates a new volume and stages a change that swaps it onto the original service. If you discard that staged change before deploying it, the original service stays on its current volume and the restored copy remains as a separate, unattached volume. Deploying the staged change is what swaps the volume and redeploys the original service, so that step is not a read-only preview.

We don't offer a supported native method to test recovery from a volume backup while leaving the live attachment unchanged. Restores also stay in the same project and environment, and there's no downloadable backup archive.

Thank you.

The remaining question is the apparent conflict with the moderator’s guidance here:

https://station.railway.com/questions/how-to-attach-existing-unattached-restor-a6ccbf18

Is that guidance outdated, technically possible but unsupported, or applicable only to a different situation?

The automated replies haven’t resolved this distinction. We have made no restore or deployment changes and are waiting for human clarification.

That older thread doesn't change our current position. Attaching a restored copy to a separate service isn't a supported recovery-testing workflow, and that includes services in the same project and environment. So the moderator's description shouldn't be read as a supported procedure for your PGlite recovery test.

What we can confirm about the restore itself: it creates a new volume and stages a swap onto the original service. Discarding that staged change keeps your live service on its current volume and leaves the restored copy unattached. That unattached copy doesn't give you a supported way to attach, inspect or test it in isolation, and we don't have a supported native method to test recovery from a volume backup while leaving the live attachment unchanged.