Storages
Server keys
Each server has its own S3 key in each storage, limited to its folder arcula/<server id>/. Only the server's agent knows the key; the panel neither stores nor sees it. A compromised server can only damage its own backups, and a leaked panel database opens none. The panel key is a different one: one per storage and read-only — Keys.
Set a key
- Storage → “Connection” tab → “Server keys” card: it lists every server whose plan has this storage.
- At the server, click “Set key” and expand “Server policy for the provider” — this server's IAM policy, with its folder already filled in.
- Create a key at the provider and apply the policy to it — as a key, user or bucket policy, depending on what the provider supports.
- Enter the key in the panel or on the server, below.
The policy denies deleting old versions and changing versioning, lifecycle, Object Lock and the bucket policy: so a compromised server can't remove the deletion protection.
In the panel — the access key, the secret key and “Encrypt and hand over”. The browser encrypts the key for this server's agent; the panel passes only the ciphertext.
On the server — the key goes through neither the browser nor the panel:
sudo arcula storage key "Primary"The command asks for the access key and secret key. In scripts — --access-key-id and --secret-file (the secret on the first line of the file).
The agent checks the key in its folder. If it doesn't work, the key isn't saved and the previous one stays.
What the server's row shows
| In the panel | What it means |
|---|---|
| “no key — backups don't go here” | Set a key |
| “handed over, waiting for the agent” | The agent picks up the key as soon as it's online |
| “the agent rejected the key: 403 AccessDenied” | The key doesn't let it into the server's folder. The previous key stays |
| “refused in the folder: 403 AccessDenied” | The saved key stopped working: revoked, or the policy changed |
What the agent checks
The agent checks its key when it's entered and every 6 hours:
| Where | What it tries | Expected | Otherwise |
|---|---|---|---|
| In its folder | List, write, read, delete | Passes | “refused in the folder” |
| Outside its folder | List, write, delete | Refused | The “whole bucket” tag |
| In its folder | Delete an old version, write the versioning and lifecycle settings | Refused | The “deletes versions” tag |
Both tags are notices: the storage status stays “OK”. The agent doesn't try Object Lock settings: a mistake there can't be undone. The policy denies them.
The provider can't issue per-folder keys
Set the same key for all servers of the storage. It works, but a compromised server could delete the backups of all servers here — the servers get the “whole bucket” tag. Most providers are like this, so it's a notice, not a warning. The panel doesn't get this key either.
Some providers, Timeweb for example, set per-folder keys only through the bucket policy: apply the server policy to the bucket with a condition on this key.
“The agent is old”
An old agent has no encryption key of its own — a key can't be handed to it from the panel. Update the agent or set the key on the server with the command above.
The same article is in the panel, under “Help”.