Connect
Choose what to protect
The protection plan is what to protect on a server, by which method, how often and to which storages. The panel suggests it based on what the agent found, and you confirm it. How the plan works — in Protection plan; copy methods — in Backup methods.
Where to open it
- New server: “Confirm plan” in the server's row or on its page.
- Current plan: server → “Protection settings” → “Edit plan”.
- Something unprotected: server → “Overview” → “Not in the backup” → “Decide in the protection plan”.
At the top of the page — when the agent last scanned the server, and the plan revision number. If something appeared, disappeared or changed on the server since the last plan, the panel shows how many.
Application data
Databases, directories, Docker volumes and everything else the agent recognized, in groups. Each row has:
- a checkbox — protect or not;
- “Size”;
- “How to copy” — the backup method;
- “Why” — the resource key, what signs the agent used to find it, and which method it suggests.
Labels next to the name: “assumed” or “not identified” — how sure the agent is; “new” — appeared after the last plan.
By default everything that has a method is checked. Logs and cache aren't: “usually not needed”. Uncheck a box and a “why not protected” field appears: the reason will be shown in “Not in the backup”. A group of several rows has “protect” and “don't protect” buttons for all rows at once, and a shared reason field.
Directories are shown as a tree. A nested directory is copied in its own row. An unchecked nested directory is also left out of the parent's copy.
“Server settings” — users, systemd services, cron, Docker config, Caddy, nginx, Let's Encrypt. They're needed to rebuild the server.
Needs a decision
This is what the agent found but didn't recognize: volumes and directories with unknown data, stopped containers with data, data in external storage, paths without read access. Each item has a choice:
- “decide later” — not in the backup; the server keeps a warning;
- “protect — file copy” — available for a named volume and for a directory;
- “don't protect” — with a reason in the “why” field.
A file copy is not consistent. For the volume of a live database that's not enough: it's more reliable to have the agent recognize the service. A stopped container, external data and a path without access can only be marked “don't protect”. For a group of items there are “for all” buttons.
The agent finds new things on the server by itself — every 6 hours by default. Recognized items appear in “Application data” with the “new” label, unrecognized ones in “Needs a decision”. New items go into the backup only when you save the plan. To scan the server now: server → “Protection settings” → “Discover now”.
Gone from the server
A resource is in the plan, but the agent no longer finds it on the server — it's in the “Gone from the server” card. There's nothing to copy. When you save the plan, the resource leaves it.
How to copy
arcula picks the method itself by resource type: PostgreSQL dump, Redis snapshot, consistent SQLite copy, Prometheus snapshot, gitlab-backup, host settings, file copy.
Two lines deserve attention:
- “… — the agent can't do this yet (update it); file copy without consistency for now” — the agent on the server is old. See Update agents.
- “no adapter: don't protect, or copy as files” — there's no consistent method for this resource. If you check it, you get “file copy of a live database — not consistent”.
Snapshot by choice: Vault
For Vault on Raft, “How to copy” is a list:
- “file copy — default”;
- “Vault snapshot (raft) — needs setup on the server”.
The snapshot is consistent, but first you need to run sudo arcula vault setup on the server. How — in Vault: Raft snapshots.
How often
The profile sets the backup schedule and the freshness target.
| Profile | Backup | Target — no older than |
|---|---|---|
| “Critical” | every 30 min | 1 h |
| “Standard” | every 6 h | 12 h |
| “Rarely changes” | daily | 36 h |
The schedule uses the panel time zone. The target is not a promise: it includes the time to collect and upload.
Where to store
Check the storages to send backups to. The first checked one is “primary”; the others have a “make primary” button. A backup goes to each checked storage in its own queue.
At the top of the card — how many independent copies there are. The panel counts two storages in the same account as one copy and warns about it. A storage without access can't be checked. No storages yet — “Connect a storage”, then come back to the plan.
The upload window and speed are on the storage page, “Servers” tab. How long to keep — there too, on the “Cleanup” tab: while cleanup is off, backups aren't deleted.
Agent on the server
- “Discovery” — how often the agent scans the server: every hour, every 6 hours or once a day.
- “Staging” — space on the server's disk for database dumps and host settings while they wait to be sent. At least 1 GB, 40 GB by default. restic reads directories and volumes straight from disk; they need no space there.
Save
At the bottom is the summary: how many resources go into the backup, the size, the profile and the storages. Click “Confirm plan” the first time, or “Save plan” after that.
The button can't be clicked until at least one resource and one storage are selected. The agent gets the plan on its next check-in, usually within a minute. After the first confirmation it makes the first backup right away.
If the plan was changed in another tab, the panel asks you to reopen the page.
The same article is in the panel, under “Help”.