The backup key

When a registry takes its first backup, sloop makes it an age keypair. Every backup that registry takes from then on is encrypted to it — and the two halves of that pair live in completely different places, for completely different reasons.

Showing Linux. Change it in the strip above and every path and store name follows.

The asymmetry is the point

A symmetric key would mean the secret has to be present to write an encrypted backup — so a nightly job would need it unlocked, sitting somewhere a scheduler can reach, at three in the morning, unattended. That is the thing worth avoiding, and splitting the pair is what avoids it.

So a scheduled backup holds nothing you would mind it holding, and the one thing worth protecting is read by exactly one command. That is the design, and everything below is a consequence of it.

The first backup will not run until you have a copy

A key that exists only inside one machine is not a backup strategy — it is a machine you cannot afford to lose. So sloop says this once, hard, and refuses rather than warning:

On a terminal it asks and will take no for an answer — declining explicitly is a decision, and it only has to be made once. With no terminal to ask at, as above, it exits 2 and names the command that settles it. Nothing was dumped, nothing was written.

Exporting it

The private key goes to standard output, deliberately, so that sloop key export > backup-key.txt is the whole of writing it down and the shell decides where it lands. Everything else on that block — the heading, the public key, the warning — goes to standard error, so the redirect captures the key and nothing else.

Running it again does not make a second key. The first word is the whole difference — a new backup key on the run that created one, the backup key every time after:

Moving to another machine

This is the whole reason export and import exist, and it is worth walking through in order — because the step in the middle is the one that surprises people.

Copy that backups directory to the new machine — any way you like, it is ordinary files — into the registry there. sloop finds it immediately and reads it perfectly:

Size, timestamp, row count, all of it. That is the manifest talking, which is plain JSON and not encrypted. The dump beside it is another matter:

It names the public key the backup was encrypted to, so you can tell which key you are looking for rather than guessing. This is what losing the key looks like from the inside: a listing that reads perfectly and a dump that opens for nobody.

Nothing about the backup changed between step 3 and step 5. The only difference is the Secret Service.

One key per registry, and sloop keeps it that way

Importing the key that is already there is a no-op, and it says so rather than pretending to work:

Importing a different key into a registry that already has one is refused. Accepting it would silently make every backup already taken unreadable — the registry would encrypt new ones to the new key and have nothing left that opens the old ones:

The way out is deliberately manual, because it should be: take the [encryption] block out of the registry by hand, keep the old key, and let sloop make or take a new one. A flag for this would be a flag whose worst case is losing every backup you have, and --force is not offered here.

What you lose, and to what

Two different losses, and the page is only worth reading if you leave able to tell them apart.

Losing the machine

Nothing, if you exported the key. The backups are ordinary files — copy them wherever they need to go. A new machine, sloop key import, and sloop restore works exactly as it did. That is steps 1 to 5 above, and it is the case sloop is built for.

Losing the key

Every backup it ever encrypted. Not damaged, not partially readable — the dumps are age ciphertext and nothing opens them. sloop cannot help, there is no recovery path, and there is nobody to ask: the private half was never anywhere but that one machine's keyring, which is the property that made the scheduled backup safe in the first place.

Which is why the refusal at the top of this page exists, why it is a refusal and not a warning, and why it fires before the first encrypted backup rather than after it.

The backups page is what those encrypted files are and how they are taken, pruned and put back. Every flag both pages mention is on the command reference.