Accidental prisma migrate reset on production DB - any PITR or snapshot recovery possible?
jersonch1
HOBBYOP

23 days ago

## Summary

Accidentally ran prisma migrate reset --force --skip-seed against my production PostgreSQL database while configuring a separate demo environment. I copied what I believed was the demo DATABASE_PUBLIC_URL but it actually pointed to production. All real customer data was lost.

This is a real production system used by a paying client (a salon business in Peru). I am NOT asking Railway to perform recovery on my behalf. I just need a definitive yes/no on whether ANY infra-level recovery is technically possible for this volume before I declare the data permanently lost and move on to external-source reconstruction.

## Specific questions

1. Are there any volume snapshots retained at the infrastructure level (even non-user-facing) for this Postgres service?

2. Are WAL segments still on disk that could enable a point-in-time recovery to a moment before the reset?

3. Any internal block-level backup retained for the volume?

If the answer to all three is no, please confirm so I can close this and proceed with external reconstruction (SUNAT records, Cloudinary assets, payment processor history, etc.).

## Timeline (UTC)

- 2026-04-29 ~23:00 UTC - Created a new "demo" project + new Postgres service

- 2026-04-29 ~23:15 UTC - Copied what I thought was the demo DATABASE_PUBLIC_URL (actually production)

- 2026-04-29 ~23:20 UTC - Ran prisma migrate reset --force --skip-seed

- 2026-04-29 ~23:25 UTC - Ran prisma db push --accept-data-loss

- 2026-04-29 ~23:30 UTC - Ran node prisma/seed.demo.js (wrote demo data on top of the wiped schema)

- After that I paused writes to the database

## Project info

- Production Postgres host: metro.proxy.rlwy.net:22323

- Database name: railway

- ORM: Prisma 5.7.0

- Plan: Hobby

- I did NOT have the volume Backups feature scheduled (lesson learned, will be enabling immediately across all my projects)

If you need exact Project ID and Service ID I can provide them - just let me know.

## What I have already done

- Stopped writes to the database (paused backend service)

- Documented full timeline

- Identified external sources for partial reconstruction

- Reviewed local git history and disk for any local pg_dump (none found)

## What was lost

Customer records, all appointments, SUNAT receipt DB references (receipts themselves safe at SUNAT), WhatsApp campaign data, Cloudinary image references (files themselves safe in Cloudinary), and owner-customized site settings.

Thank you for any clarity you can provide. Even a definitive "no" lets me move forward with reconstruction work.

Solved

1 Replies

Railway
BOT

23 days ago

To answer your three questions definitively: no, we do not retain hidden volume snapshots, WAL segments, or block-level backups at the infrastructure level beyond what is available through the user-facing Backups feature. Since no backup schedule or manual backup was configured for that volume, there is no recovery path on our side. The data on the volume reflects its current state after the reset and seed operations. We're sorry about the situation, and it sounds like you have a solid plan for reconstruction from external sources.


Status changed to Awaiting User Response Railway 23 days ago


Status changed to Solved Railway 23 days ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...