Home
Docs
Disaster recovery

Disaster recovery

When the machine is gone, the first thing you need to know is what was on it. A bucket full of encrypted archives cannot tell you, so KLYRN writes a manifest beside them.

Why a manifest

The SQLite file on the dead disk knew which accounts existed and which domains pointed where. It knew which PHP version each site ran and which database belonged to which site. All of that is needed before anything can be restored. None of it is inside an encrypted archive named after a timestamp.

KLYRN writes that knowledge to the same bucket, as a small versioned document. A freshly built machine with the destination credentials and the backup key reads it before restoring anything. It lists your sites, the accounts they belong to, the most recent copy of each, and what restoring them onto this machine will do.

What it holds

<prefix>/_server/recovery.json.enc   the manifest, encrypted
<prefix>/_server/keyinfo.json        a key fingerprint, in the clear

The manifest carries the format version and the KLYRN and database schema versions that wrote it. A server block identifies the install, so a recovery can tell "restore onto new metal" from "roll this same machine back". Then:

Accounts: Name, uid, home, owner's email, disk limit, whether suspended.
Sites: Domain, type, account, PHP version, document root, www handling and certificate state. Every alias and redirect, database names and their users, cron entries, and whether the site is a staging copy of another.
Copies: Up to twenty verified remote backups per site, newest first, named by object prefix.

What it deliberately does not hold: database passwords, API tokens, sessions, panel credentials, TLS private keys, and any file or database content. Certificates are re-issued once DNS points at the new machine, so no private key moves through object storage.

It is rewritten after every successful remote backup, so it never lags the copies it describes by more than one backup cycle.

Recovering a server

klyrn recover discover     # what was on the lost server, and what conflicts here
klyrn recover run          # restore every site that has a copy
klyrn recover run --only example.com,shop.example.com
klyrn recover run --overwrite   # replace sites that already exist here

The panel has the same flow under Backups, then Recover a server.

Install KLYRN on the new machineThe ordinary one-command install.
Give it the destination and the keyThe same bucket credentials, then klyrn backup key import. If the key is wrong, keyinfo.json names the fingerprint you need.
DiscoverReads the manifest and lists every account and site. Each is marked restorable or not, and each name that already exists here is marked as a conflict.
RunOne fetch-and-restore per site, using the same code path as a single-site restore.
Point DNS at the new server, then issue certificatesklyrn dns point <domain> if the provider is connected, then klyrn site ssl <domain>.

What it refuses, and why

No destination configured: There is nothing to read. Configure the backup destination first.
No manifest in the bucket: The server that wrote these backups predates the manifest. The message says so, and says the individual site copies can still be restored one at a time.
Not decryptable: None of this server's keys opens it. The message says to import the key from the old server.
A newer format version: Refused, naming both versions and saying to update KLYRN.
A name that already exists here: Skipped as a conflict unless you ask for overwrite. Nothing on the new machine is replaced by accident.