Back up and restore

A backup is not trusted because a command returned zero. Nautilo writes the bundle manifest last and provides a separate read-only verifier for structure, checksums, database dumps, image identity, and restrictive permissions.

This page is for local or SSH Docker Compose profiles. Railway uses protected upgrade and resume, with its own receipt and recovery configuration. Do not run these Compose commands against a Railway deployment or infer a standalone Railway restore command.

Create and verify a full bundle

Replace circle-local below with the exact deployment profile from your deployment receipt, and choose an off-host bundle destination. Do not rely on whichever profile happens to be active.

export NAUTILO_PROFILE=circle-local
export NAUTILO_RECOVERY_BUNDLE=/path/to/off-host-storage/circle-YYYYMMDD-HHMMSS

nautilo backup "$NAUTILO_RECOVERY_BUNDLE" --profile "$NAUTILO_PROFILE"
nautilo backup verify "$NAUTILO_RECOVERY_BUNDLE" --profile "$NAUTILO_PROFILE"

Supplying a path creates the self-contained bundle. The no-path single-database dump is deprecated and is not the public disaster-recovery path. --stream is a disk-constrained remote fallback and is not resumable.

Expected verification ends with result: OK and reports the bundle's profile, instanceId, and composeProject. The report is secret-redacting, but the bundle itself can contain databases, operator files, configuration, and persistent artifacts. Store it accordingly and copy it away from the host whose loss it must survive.

Restore deliberately

: "${NAUTILO_PROFILE:?Set the exact destination profile first}"
: "${NAUTILO_RECOVERY_BUNDLE:?Set the verified recovery bundle path first}"
nautilo backup verify "$NAUTILO_RECOVERY_BUNDLE" --profile "$NAUTILO_PROFILE"
nautilo whoami --profile "$NAUTILO_PROFILE" --format json

Before restore, compare the verifier's bundle instanceId with whoami's live instanceId, and confirm that whoami reports the expected profile and server URL. The selected profile, live destination, and bundle must all be the intended logical Server. If the target is unavailable and cannot answer whoami, independently inspect the named profile's instance ID and exact local or SSH destination; do not restore until you can establish that identity.

Only after those checks pass, run the separate destructive step:

: "${NAUTILO_PROFILE:?Set the exact destination profile first}"
: "${NAUTILO_RECOVERY_BUNDLE:?Set the verified recovery bundle path first}"
nautilo restore "$NAUTILO_RECOVERY_BUNDLE" --profile "$NAUTILO_PROFILE"

A healthy setupState=ready target requires --force, appended to the same explicitly profiled restore command. That flag authorizes overwrite; it does not make the chosen bundle correct. Also verify bundle provenance, available space, and the recovery goal before using it.

Mandatory dump validation occurs before destructive reset. Database reset and load share one transaction. After restore, Nautilo reconciles credentials, starts the Server, and health-polls it. That is not full application acceptance. Explicitly confirm the intended instance and setup state, load the SPA, sign in as the owner, and complete one model-backed turn.

What backups do not provide

Backups do not provide automatic high availability or failover. Same-host rollback depends on the retained prior image and verified bundle. Host-loss recovery also depends on independent retention and access to the recorded image identity.