# Backup and recovery

> What a private Railbase estate must protect and test.

_Updated: 2026-09-22_

A recoverable company-Vault installation uses a complete encrypted bundle of
System, every company Vault, local files, local audit archives and installation
identity material. Keep external unlock material and operating configuration
separately protected. A copy of System alone cannot recover the companies.
Native capture briefly fences writes so all files agree; native restore verifies
the inventory, hashes and identity before publishing a new generation.
Older single-Vault estates still require separate matching assets and secrets
until migration.

## Minimum practice

- take complete native installation backups on a documented schedule;
- keep secrets and encryption keys in a protected recovery store;
- maintain at least one off-host/off-site copy;
- define retention and deletion periods;
- test restoration on a separate environment;
- record recovery-point and recovery-time results;
- repeat the drill after material changes.

A backup that has never been restored is not verified recovery evidence.

## Shared responsibility

On-premise automatic backup is disabled by default. Enable it deliberately and
verify an off-host recovery drill. Managed Cloud duties and retention follow the
Cloud Schedule.

The customer controls private-estate backups unless an Order explicitly assigns
managed backup duties. railbase.app has its own control-plane backup programme;
that does not replace backup of customer operating data.
