Volume backup restores are self-serve on Pro. Open your Grist service's Backups tab, locate a backup dated before 2026-07-28, and click Restore. This stages the change for review, mounting a new volume from the backup at /persist while retaining the current (corrupted) volume as a detached copy. Click Deploy to apply and redeploy the service with the restored data.

No backups available

Your volume has no backups because none were created (manually or via a scheduled backup) before the corruption occurred, so there is no prior snapshot to restore from. For the corrupted .grist file itself, you may be able to recover it using SQLite recovery tools since Grist documents are SQLite databases. Going forward, you can set up daily, weekly, or monthly backup schedules from the service's Backups tab so a restore point is available if this happens again.

Recommend SQLite recovery tools?

Having looked into this, the issue appears to be in your application code or configuration rather than the Railway platform itself, which puts it outside what Railway support can resolve directly.

This is exactly the kind of problem the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

• Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
• Keep it private and close the thread - Nothing becomes public. The thread closes, since this isn't something Railway support can take further.

Opening the .grist document in "BD Browser for SQLite" and it seems to be fine.

Thank you for your help. Where do I run -sqlite3 broken.grist ".recover"- ? Within BD Browser, or in a terminal?

Great. Thanks. I apologize for asking you to explain the alphabet to me, but I'm still lost.

I copied the .grist file and named it broken.grist

I ran sqlite3 broken.grist ".recover" and the terminal lists out the contents and then finishes with:

CREATE INDEX _grist_Attachments_fileIdent ON _grist_Attachments(fileIdent);

PRAGMA writable_schema = off;

COMMIT;

How I find what the recovered file is called?

You're amazing. Thank you so much.

However, do you also happen to know anything about Grist? I imported the "recovered" file but Grist still won't load it.

Should I just remove the container and re-deploy at this stage?

Integrity check returned "ok"

Still won't load. By the way, I only had the one singular document in Grist, if that helps the decision easier to scratch and re-build

So I don't know what happened but now both my original file and the "recovered" file will load into Grist....