2 months ago
Our production PostgreSQL data appears to have been reset or recreated on August 16, 2026.
The current production database is nearly empty:
- operator_users: 0
- authentication/audit records: 0
- no previous operator or session records were restored
A new PostgreSQL volume was created around 2026-08-16 08:23 UTC, and the backend reapplied migrations 001–183 around 08:28 UTC.
Please help us verify whether the previous production volume still exists internally, is detached, queued for deletion, or is otherwise recoverable.
IMPORTANT:
Please do not overwrite, restore into, or mutate the current production database.
If recovery is possible, please restore the previous volume into a NEW ISOLATED PostgreSQL service or volume first so we can inspect and verify the data safely.
Railway project:
- Project name: ai-growth-saas-platform
- Project ID: 2c38cc02-f9c9-46a7-820b-3ec9e7201982
- Environment: production
PostgreSQL service:
- Service name: Postgres-production
- Service ID: 4a1ca22c-05e1-4009-a170-4c31f2064c6e
Previous deployment:
- Deployment ID: 86a2fe3e-5290-403a-bf72-43cde31c813b
- Status: REMOVED
Current deployment:
- Deployment ID: ab21e32c-7e79-4370-90e1-58263a730052
Current volume:
- Volume ID: 641ada9e-8e22-4d7b-9954-06e6e71a4e66
- Created at: 2026-08-16 08:23:09 UTC
Current recovery status:
- Visible volume backups: 0
- Backup schedule: not configured
- PITR: disabled
- No verified external production database backup was found
Please confirm:
- The ID and deletion timestamp of the previous production volume.
- Whether the previous volume is still retained, detached, queued for deletion, recoverable, or permanently deleted.
- Whether any platform-side snapshot or hidden backup exists.
- Whether it can be restored into a separate isolated PostgreSQL service for inspection.
- Whether a volume restoration email or restoration link was generated for this workspace.
Preferred restore point:
Immediately before 2026-08-16 08:22:00 UTC.
This is a production data recovery incident. Please preserve any remaining recoverable storage while investigating.
1 Replies
2 months ago
The Postgres-production service in the production environment has a volume attached and that volume is still present with ~232 MB used. There is no detached or orphaned volume in the project, and no deleted volume appears in recent records, so there is no previous volume to restore from. The data loss was in-place on the current volume. Our databases are unmanaged, so automatic snapshots, WAL recovery, and PITR are not available to restore your data unless you had enabled them on the service. We do not recover data lost to in-place changes on a volume that still exists. Going forward, upgrading to Pro unlocks native volume backups and point-in-time recovery, which would let you self-restore after this kind of in-place loss.
Status changed to Awaiting User Response Railway • about 2 months ago
a month ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • about 1 month ago