# Offline backup and restore

Stop the server, then run the following commands in a private directory. Use the actual path printed by `ratdb init` for the source. Replace the example paths with unused destination names.

```sh
ratdb backup ./instance.ratdb ./nightly.ratdb
ratdb check ./nightly.ratdb
ratdb restore ./nightly.ratdb ./restored.ratdb
ratdb check ./restored.ratdb
ratdb setup ./restored.ratdb admin
ratdb serve ./restored.ratdb
```

The commands copy the complete database file, including inactive bank and unused bytes that may contain previously deleted data. The administrator credential registry stays with the original instance. Run setup to choose credentials for a restored instance. Protect backup files like the original database.

RatDB takes the same exclusive file lock as the server and validates the source's active snapshot, document keys, matching string IDs and explicit namespace markers before copying. It streams the database into a new staging file with a 64 KiB buffer, syncs it, reopens it through the engine, and compares every byte against the still-locked source using a second 64 KiB buffer. It publishes the verified file by creating a hard link at the destination, removes the staging link, then syncs the containing directory on Unix. The new file is independent of the source. An existing destination or an existing destination credential registry causes an error.

Both operations support document instances using the CLI's default bank size and record limits. Allow space for the entire logical file at the destination and use a filesystem with hard-link support. The host adapter needs write access to lock and validate the source. Windows inherits the directory ACL. Unix staging files use mode 0600 subject to the process umask. A private destination directory protects the staging name while the copy is underway.

A process interruption may leave a `.ratdb-copy-*.tmp` file. The destination name appears only after verification. If an error occurs after publication, inspect the destination with `ratdb check` and compare it to the known backup before using it. Windows directory-entry durability across machine power failure remains unverified. Offline backup reads through the filesystem cache and provides no evidence of recovery from physical device failure.