Yes. A volume backup is a single point-in-time copy-on-write snapshot of the whole volume, taken while your service keeps running and without pausing or flushing it, so v11.db, v11.db-wal and v11.db-shm are all captured at the same instant. That is equivalent to a power loss at that moment, so running SQLite's normal crash recovery on a copy of the backup is valid.

No, there is no nondestructive way to read a backup. Its contents only become reachable through a restore, which creates a new volume and stages a swap that takes effect when you click Deploy. Volume file access through the CLI also requires the volume to be attached to a service with an active deployment, so a restored copy that is left unattached, whether the swap is still staged or has been discarded, cannot be listed or downloaded.

Thanks, that answers the snapshot-consistency question.

I just want to confirm one detail before I touch the backup:

After I click Restore on the backup, but before clicking Deploy, can I discard only the staged changes that would:

1. unmount the existing production volume from my production service, and
2. mount the restored volume onto that production service,

while keeping the newly created/restored volume itself?

If so, would that leave the restored volume as an unattached volume in the same environment that I can then attach to a completely separate temporary service, without changing, restarting, detaching, or replacing anything on the currently running production service?

I specifically want to inspect the backup through a separate temporary service and avoid deploying the restored volume to production at any point.

Thanks

Yes, discarding the staged swap before you click Deploy leaves your production service on its current volume, unchanged, and keeps the restored volume as a separate, unattached copy of the data as of that backup, which you can keep or delete.

That unattached copy is not a supported way to inspect a backup, though. Attaching the restored volume to a separate temporary service is not a supported inspection workflow, and discarding the swap does not create any file-access path to it, so this route will not give you a supported read of the backup that keeps production untouched.

Thanks. I need one more clarification from a Railway employee before proceeding.

My goal is to inspect a SQLite database contained in a volume backup without modifying, restarting, replacing, or detaching anything from my running production service.

You confirmed that restoring the backup and discarding the staged swap leaves the restored volume as a separate unattached copy, but the automated response says attaching that restored volume to a temporary service is not a supported inspection workflow.

What is Railway’s supported method for accessing or exporting the files (v11.db and v11.db-wal) from that restored copy while leaving the production service and its currently attached volume completely untouched?

If Railway currently has no supported method to do this, please confirm that explicitly as well.

I do not want to deploy the restored volume over production at any point.

Confirmed: we don't currently offer a supported way to access or export files directly from a backup, or from an unattached restored volume, while leaving production untouched.

Discarding the staged swap does keep your production service and its current volume unchanged. But it leaves the restored copy unattached, and that doesn't give you any way to download from it. Volume file access through the CLI only works on a volume attached to a service with an active deployment. It can't reach a stored backup or a detached volume by itself.