a day ago
Deployment that caused data loss: d494210f-4481-4fb7-a800-2181e4a5c65c (Sep 5 23:16:43 UTC)
Data lost: from April sales, products, inventory, appointments
Database file: /app/Wellness Center/database/wellness_center.db
requesto to know if have volume snapshots or backups from before the redeploy
3 Replies
a day ago
Our databases are unmanaged, so automatic snapshots, WAL recovery, and PITR aren't available to restore your data unless you've enabled them on the service. Volume backups and point-in-time recovery are both native Railway features on Pro. We don't recover data lost to user-initiated actions. Going forward, enable volume backups on your stateful services so you can self-restore if this happens again.
Status changed to Awaiting User Response Railway • 1 day ago
Railway
Our databases are unmanaged, so automatic snapshots, WAL recovery, and PITR aren't available to restore your data unless you've enabled them on the service. Volume backups and point-in-time recovery are both native Railway features on Pro. We don't recover data lost to user-initiated actions. Going forward, enable volume backups on your stateful services so you can self-restore if this happens again.
a day ago
so whats the way forward
Status changed to Awaiting Railway Response Railway • 1 day ago
a day ago
To correct our earlier message, your service does have a volume attached at the database path, and it survived the redeploy with ~60 MB of data on it. The data loss was in-place, meaning something in the application overwrote or re-initialized the database file during the redeploy rather than the storage being discarded. We don't recover data lost to user-initiated actions, so restoring the previous database contents is not available. The way forward is to re-enter the lost records and, to protect against this in the future, upgrade to Pro and enable native volume backups on the service so you can self-restore from a snapshot if it happens again.
Status changed to Awaiting User Response Railway • 1 day ago