Learn Borg Backup - Repository Security

#Introduction

A backup is the last line of defense when a server is attacked — but if the backup repository is attacked too, that line disappears. Modern ransomware no longer targets just data; it targets backups so the victim has no way out. Episode 13 turns your repository from an easy target into a fortress: authenticated encryption, append-only mode, and strict access control.

#Layer 1: Authenticated Encryption

#repokey and authenticated

Two modes from episodes 3 and 7 are relevant here:

• repokey-blake2: data is encrypted. An attacker who steals the repository cannot read its contents without the passphrase.
• authenticated: data is not encrypted but every change is detected. Suitable if the storage is already encrypted at a lower layer.

Both modes provide integrity: an altered chunk will not pass verification. This matters because it ensures that the backup you restore is truly the backup you made.

#Layer 2: Append-only Mode

#The Concept

An append-only repository only allows adding (appending) new data — no modification or deletion of existing segments. This counters the classic ransomware scenario: an attacker who gains client access to the repo (e.g. through the backed-up host) cannot delete the backup history to force a restore from an already-damaged version.

Borg 1.2 brought a significant improvement to append-only: repositories can now run in this mode more strictly, and server-side append-only (borg serve --append-only) became the primary recommendation — not just a client flag that can be worked around.

#Enabling Append-only

At initialization:

borg init --encryption=repokey-blake2 --append-only /backup/borg

Or set it on an existing repository:

borg config /backup/borg append_only 1

For a remote repo, lock append-only on the server side so the client cannot turn it off:

command="borg serve --restrict-to-path /srv/borg --restrict-to-repository /srv/borg/backup --append-only",restrict,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... borg-backup

With this pattern, the client cannot run prune/delete — it can only add. If you use borgmatic, prune exceptions must be arranged on the server side by temporarily removing --append-only from authorized_keys (or via a dedicated maintenance repo).

#The Trade-off

• Advantage: backup history cannot be deleted, even by a client controlled by an attacker.
• Drawback: prune/delete do not run in append-only mode — the repository can grow without control until you do maintenance by safely removing this mode.

#Layer 3: SSH Access Control

#The SSH Lock with a Restricted Command

Episode 11 already introduced command= in authorized_keys. Here we see it as a repository security component, not just convenience:

command="borg serve --restrict-to-path /srv/borg --restrict-to-repository /srv/borg/backup",restrict,no-pty ssh-ed25519 AAAA... borg-backup

• --restrict-to-path: borg serve cannot read files outside /srv/borg.
• --restrict-to-repository: only one repository is served.
• restrict: disables any SSH forwarding.
• A different key per host → revocable individually.

#Storage Quota

To limit the damage if the repository is flooded with data (malicious or accidental), set a per-repo quota:

borg config /backup/borg storage_quota 500G

When the quota is reached, create is rejected — backups do not silently stop, but there is a clear, alertable limit.

#Common Pitfalls

• Append-only only on the client side: if the --append-only flag is only used at borg create time, another client (or an attacker with access) can still prune. Lock it on the server with borg serve --append-only.
• Forgetting the impact on prune: append-only + borgmatic = prune fails. Plan a maintenance window and a safe way to remove this mode.
• Quota without monitoring: an always-full quota means backups have stopped — pair it with alerting (episode 20).
• An SSH key without restrict: one key with a full shell cancels all the layers above.

#Closing

• Authenticated encryption (repokey/authenticated) protects confidentiality and integrity.
• Append-only mode prevents history deletion — lock it on the server side with borg serve --append-only.
• Borg 1.2+ made append-only stronger and a production recommendation.
• The SSH lock: command="borg serve --restrict-to-path ..." limits the blast radius.
• A storage quota limits uncontrolled growth.

In episode 14 we apply all of this at a larger scale: hardening & multi-host — one repository per host/team, key isolation, access monitoring, off-site backups on different hosts, and restore-test rituals.