Your server's world — warehouse, connections, installed recipes, audit history, stored files — exports as a single encrypted archive and comes back onto any server, entirely from the webclient. Neither direction requires a terminal on the server box.
#Back up
Settings → Backup & Recovery exports the whole server — database,
configuration, credentials, and stored files — into one .recued.archive
file you download through the browser. The export streams, so a
multi-gigabyte warehouse backs up on a small machine without running out of
memory. The server CLI can also write the archive to a path, for scripted
backups.
The archive is encrypted, and your recovery key is what opens it. Keep the archive file and the recovery key — separately — and you hold a complete restore. The archive carries the server's state at export time; anything that happened after is not in it, so back up on a rhythm that matches what you are willing to lose.
#Restore onto a fresh server
Restoring is the webclient's first action on a new server — there is no pair-first-then-restore dance:
- Install a fresh server and open the webclient's pair form.
- Choose Restore a backup and provide four things: the server address, the fresh server's pairing code, the backup's 24-word recovery key, and the archive file.
- The archive uploads and is validated in a dry run. Nothing commits yet — a wrong recovery key simply bounces back for another try, with the server still pristine.
- Review the preview of what the archive contains, and confirm.
- The restore commits, the server restarts into the restored data, and your webclient reconnects — already paired.
Supervised installs — a container, the one-click image, a service manager — come back from that restart automatically. A server running in a plain foreground terminal needs starting again by hand.
#Restore onto a running server
An existing, paired server can also import an archive from Settings → Backup & Recovery. Two guards apply:
- An archive from a different server identity does not silently replace this server's data: it additionally requires this server's own current recovery key plus an explicit confirmation.
- An archive made by a newer server version is refused with instructions to update first; same-or-older archives migrate forward automatically on the restart.
#Built not to corrupt
- Validation comes before anything irreversible: the archive key is proven in the dry run before any commit.
- The restored database is staged beside the live one and swapped atomically at restart. An interrupted restore reboots on the original, untouched data.
- Uploads and the commit survive a dropped connection without corruption and without forcing a re-upload.
#Related
- Install the server — where the data directory lives.
- Pairing and devices — the recovery key this flow depends on.