Backups and Moving Hosts
Because your records live in one Vault file and uploads live beside it, backups are ordinary file copies — here's what that means for you.
Updated
The question behind "what if something breaks?" is usually "how hard is it to get my data back, and how locked in am I?" With Railbase the honest answer is short: your records live in a single Vault file, and uploaded file blobs live in the storage directory beside it.
A backup is a file copy
Railbase stores operating records — finance ledgers, document metadata, procurement, tasks, and plugin data — in one Vault file (a single-file NoSQL store, not a SQL database spread across tables and services). Uploaded file blobs live in <data-dir>/storage by default. So a backup is not an export job you have to babysit: copy the Vault snapshot, the storage directory if you use file fields, and the secrets described in Backups and restore.
For a clean copy while the system is live, Vault's single-file, copy-on-write design means a point-in-time snapshot is internally consistent — you get a coherent copy of that one file rather than a fragile mid-write grab. That snapshot is a normal file you can move anywhere.
Backups on a schedule, off the box
You do not want your only copy sitting next to the original. Your IT partner can automate consistent snapshots on a schedule and push them to off-box storage — another server, object storage, or an offline drive — using the same tools they already use for backups. Railbase is simple to operate, and it works with the IT partner you already trust; there is no proprietary backup appliance to learn.
Restoring is copying the file back
If you ever need to roll back, you restore the Vault snapshot and the matching storage directory, then start Railbase against them. There is no vendor database to import into and no reconstruction step.
Moving to a new host is one binary and one file
Changing servers, providers, or countries is deliberately boring: copy the single Railbase binary, your Vault file, storage directory, and required secrets to the new machine, install your business modules from the marketplace, and run. Because railbase.app only handles the catalog, licenses, and signed artifacts — never your data — moving hosts never involves us touching your records.
FAQ
How often should we back up?
As often as your business can afford to lose work — daily is common, hourly is easy to schedule. Your IT partner sets the cadence; consistent snapshots make frequent copies cheap.
Can we test a restore without risking production?
Yes. Copy a snapshot, storage directory, and required secrets to a separate machine and start Railbase against them. A restore drill is just running a spare copy.
Are we locked in if we leave?
No. You always hold the binary and your data files. There is no vendor database to export from and no data held on railbase.app to retrieve.
For the step-by-step commands your IT partner will run, see Backups and restore. Ready to move? Browse business modules or plan an implementation.