# Backups and Moving Hosts

> Because your whole business runs on one Vault file, a backup is a file copy and moving servers is copying one binary plus one file — here's what that means for you.

_Updated: 2026-07-02_

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, because everything your business runs on lives in a single Vault file.

## A backup is a file copy

Railbase stores all your operating data — finance ledgers, documents, procurement, tasks, everything — in one Vault file (a single-file NoSQL store, not a SQL database spread across tables and services). So a backup is not an export job you have to babysit. It is a copy of that one file.

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 copy a snapshot file into place and start Railbase against it. There is no vendor database to import into and no reconstruction step — the file *is* the database.

## Moving to a new host is one binary and one file

Changing servers, providers, or countries is deliberately boring: copy the single Railbase binary and your Vault file 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 to a separate machine and start Railbase against it. It is an ordinary file, so a restore drill is just running a spare copy.

### Are we locked in if we leave?

No. You always hold the binary and the file. 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](../learn/backups-and-restore). Ready to move? [Browse business modules](../plugins) or [plan an implementation](../develop).