Every backup tool has to run something on the machine that holds the data. The question is whether that something is a long-running agent you install and keep updated on every server, or a set of commands the backup server runs over a connection when a backup is due. Both work. They put risk and effort in different places.
What an agent gives you
An agent is a service on each server, usually running as root and talking to a central server — often over a port the agent opens or a connection it keeps alive.
- Local knowledge. It can watch the filesystem, track changed blocks and run without a central server reaching in.
- Offline operation. Schedules can keep running when the central server is down.
- Platform reach. Agents are the natural fit for operating systems where remote shells are not the norm.
The cost is that you now operate one more privileged service on every machine: it has to be installed, upgraded in step with the server, monitored, and trusted with root on hosts that may also hold your most sensitive data.
What agentless changes
An agentless tool connects when it needs to — for Linux, over SSH — runs the work and disconnects.
- Nothing to install or upgrade on the servers. Upgrading the backup system means upgrading one server.
- No listening service. The protected servers do not expose anything new; the backup server initiates every connection.
- Native tools. Database backups run with the engine’s own tools at the version that matches the server, instead of a plug-in compiled into an agent.
The trade-offs are real too: the backup server needs SSH reachability to every host (directly or through a jump host), and the access it holds has to be scoped carefully — an SSH key with root access everywhere would be worse than an agent.
How Xtic scopes agentless access
Xtic is agentless, and most of its security design is about keeping that access narrow:
- Pinned host keys. A server’s SSH host key is approved once; if it changes, every plan for that server stops until an administrator re-pins it.
- One key per server or environment. Credentials can be restricted to the servers they are meant for.
- A dedicated backup user set up by an onboarding script that your administrator reads and runs — Xtic never needs a root password.
- A least-privilege helper. The backup user may run exactly one thing as root: a small helper that accepts a fixed set of verbs, validates its input and builds the command line itself. See the security model for the verbs.
- No secrets on command lines. Database passwords reach the tools through the environment, a file descriptor or a short-lived file in memory.
Network and load
With an agentless design the data usually flows through the backup server: Xtic streams each dump from the server, then
packages, compresses and encrypts it before storing it. Plan for that bandwidth between the Xtic server, your servers and
your storage. The dump itself still runs on the database host — pg_dump or mysqldump uses CPU and I/O there exactly as it
would under an agent — so schedule large databases outside your busiest hours.
Which one should you choose?
If you manage Linux servers and containers, already reach them over SSH and would rather not run another privileged daemon on each of them, agentless is the simpler system to operate and to reason about. If you need continuous, block-level change tracking on every host, an agent-based product is the better fit.
Xtic made its choice deliberately: one server to run, nothing on yours, and a design you can read before you trust it.
Try it on your own servers: the Free edition covers 3 servers, forever.