Backup and restore

Not the RDB file. A snapshot is the server writing its own memory to its own disk, inside its own container, and Keydra has no filesystem there — the Snapshot now button on the server settings page asks the server to do it, and the file stays where the server put it.

What Keydra can back up is what it can read: the keys, their values and their expiries, written in the same shape the import reads. That is portable across Redis, Valkey and anything else behind the same engine, and it restores through a path that already exists.

The export is streamed and compressed. A keyspace as JSON is large, and every destination is billed or throttled by the byte.

A destination is a thing, not a string: a name, a kind, a location and credentials, configured once and pointed at by any number of schedules. Otherwise every schedule carries its own copy of a bucket name and a secret key, and rotating the key means editing all of them.

Somewhere else is write-only, and says so — on the form, in the list, and in the refusal if something asks it to list. Which components can also be read from is a property of each one, and an address that is arbitrary cannot be promised more than the one operation every sender has.

A destination can be reached through an SSH tunnel, for a drop or a store on the far side of a jump host. Not the public clouds: a forwarded port reaches a host and a port, and AWS, Azure and Google are named by an address inside a certificate.

An export job carries a Keep the last count: keep the last n, delete what falls off the end. A backup job that never deletes is a bucket that grows until somebody notices the bill.

A list rather than one key, because one recipient means the person holding that private half is the only person in the world who can read a year of backups. They leave, they lose the password manager, they are on a plane on the morning the cache is empty — and "encrypted at rest" becomes "gone", which is the failure the encryption exists to prevent, arrived at from the other side.

Sharing the private half is worse than the problem: a secret two people hold is a secret with no owner, and it cannot be taken back from one of them.

Each key on the list has a name — Ada’s key, the safe, offsite — because removing one means knowing which one, and the rest is forty characters of base64.

An encrypted backup only Keydra can read is not a backup, it is a hostage. scripts/keydra-decrypt.py ships in the repository, takes the file and the secret — a passphrase or a private key — and prints the keys, importing nothing from the application.

Encryption is framed rather than one stream, deliberately. A single GCM stream cannot be both memory-bounded and safely readable: Java’s CipherInputStream reports a failed tag as end-of-input, which is a truncated restore that looks like a complete one. Each frame authenticates its own contents and its position, and the file ends with a marker, so a truncated or rearranged backup is refused rather than half-restored.