Serving a Kloset Store over the Network

Plakar can expose a Kloset Store over HTTP using the plakar server command. This allows other machines to access the store over the network.

There are two main reasons to use plakar server:

• Accessing a store over HTTP. Some environments only expose storage over HTTP. For example, a NAS that is reachable over HTTP but not over SSH. In these cases, plakar server lets you bridge the gap by re-exposing a store through HTTP.

• Protection against destructive maintenance operations. By default, plakar server refuses to delete the underlying objects (states, packfiles, and locks) stored inside a store. This is useful when multiple machines push backups to a shared store: if one of those machines is compromised, an attacker cannot use it to permanently erase backup data.

  Note that this does not prevent a client from marking a snapshot as deleted. In Plakar’s model, deleting a snapshot doesn’t remove anything by itself. It only pushes a new state that marks the snapshot as deleted, which from the store’s point of view is an addition, not a removal. The actual data is only reclaimed later, when plakar maintenance runs. It’s this reclamation step that plakar server blocks by default. If you need to stop a machine from even marking snapshots as deleted, don’t push backups from it directly; instead pull the data from that machine using a trusted server (for example over SFTP). See Should you push or pull backups for more on this tradeoff, and How Maintenance Works for the full picture of how deletion and reclamation work.

In all cases, clients still need the repository passphrase to access the store, and all snapshot data remains fully encrypted in transit.

Assume you have a Kloset Store located at /var/backups. To expose it over HTTP, run:

$ plakar at /var/backups server

By default, plakar server listens on http://localhost:9876. You can then access the store from any Plakar client:

$ plakar at http://localhost:9876 ls

Use the -listen flag to change the listening address and port. To listen on all interfaces on port 12345:

$ plakar at /var/backups server -listen :12345

To listen on a specific address, for example 192.168.1.10:

$ plakar at /var/backups server -listen 192.168.1.10:12345

Remote clients on the same network can then reach the store using:

$ plakar at http://192.168.1.10:12345 ls

By default, plakar server refuses to delete the underlying objects (states, packfiles, and locks) stored inside a store. This is what happens during plakar maintenance. To allow these destructive operations through the server explicitly:

$ plakar at /var/backups server -allow-delete

plakar server can serve the store over HTTPS using a TLS certificate and private key:

$ plakar at /var/backups server \
  -listen :443 \
  -cert fullchain.pem \
  -key privkey.pem

Clients connect using:

$ plakar at https://backup.example.com ls

If either -cert or -key is missing, the server falls back to plain HTTP.

plakar server can also expose non-local stores. For example, to expose an SFTP-backed store over HTTP:

$ plakar at sftp://example.org server

• TLS certificates are not generated automatically. You must provide your own certificate and private key when enabling HTTPS.
• The server’s delete protection guards against object-level removal (states, packfiles, locks) during maintenance. It does not prevent a client from marking snapshots as deleted, and there is currently no CLI-level way to restrict that. If a client must be prevented from doing even that, pull backups from it via a trusted machine instead of letting it push directly. See How Maintenance Works for details on the grace period, packfile-level garbage collection, and checkpoints that govern when reclamation actually happens.