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.
Which keys are needed
| Key | How many | What it can do |
|---|---|---|
| Panel key | One per storage | List objects with versions and read bucket settings. No writing, deleting or reading data |
| Server key | One per server in each storage | Write, read and delete only in its folder. Deleting old versions and changing protection settings is not allowed |
The panel key is entered when connecting the storage. Server keys — once the storage is in a server's plan.
Create a server key at the provider
- Storage → “Connection” tab → “Server keys” card.
- At the server, click “Set key” and expand “Server policy for the provider”. It is an IAM policy for this exact server: its folder is already filled in.
- Create a key at the provider and apply the policy to it — as a key, user or bucket policy, depending on the provider.
The policy explicitly denies deleting old versions and changing versioning, lifecycle, Object Lock and the bucket policy. So a compromised server can't remove the deletion protection.
Enter the key
Two ways — pick one.
In the panel. In the same form, enter the access key and secret key and click “Encrypt and hand over”. The browser encrypts the key with this server's agent public key; the panel passes only the ciphertext to the agent. The agent decrypts the key, checks it in its folder and reports back — the server's row in “Server keys” updates.
On the server itself. Then 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).
If the key doesn't work in the server's folder, it isn't saved: the previous one stays.
What the agent checks
The agent checks its key when it's entered and every 6 hours:
- in its folder — list, write, read and delete must pass;
- outside its folder — write, list and delete must be refused. Not refused — “reaches other folders”;
- in its folder — deleting an old version and writing the versioning and lifecycle settings must be refused. Not refused — “can delete old versions”.
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
Then enter the same key for all servers of the storage. It works, but a compromised server could delete the backups of all servers here: in “Server keys” the servers show “reaches other folders”, and the storage gets a warning. The panel doesn't get this key either.
Some providers set per-prefix keys only through the bucket policy, Timeweb for example: apply the server policy to the bucket with a condition on this key.
Old agent
The agent needs its own encryption key — it exists since version 0.4. For an old agent “Server keys” shows “The agent is old”: update it or enter the key on the server with the command above.
The same article is in the panel, under “Help”.