Learn Borg Backup - Borg on a Remote Server (SSH)

#Introduction

So far the repository has always been local, on the same server as the data. That protects against human error, but not against a server room fire — the 3-2-1 principle demands one copy off-site. Episode 11 moves the repository to a separate host over SSH. This is where security becomes the focus: you will not be giving full shell access to the backup host.

#Remote Repository: Basic Concepts

#The Address Format

A remote repository is written as user@host:path:

borg@backup-host:/srv/borg/backup

Borg detects the user@host: pattern and automatically uses SSH. On the server side, Borg calls borg serve — a daemon opened over SSH to serve backup requests. Client and server do not copy raw files; they exchange chunks over the Borg protocol.

#Server Setup

On the backup host, create a dedicated user and install borg:

sudo useradd -m -s /usr/bin/bash borg
sudo apt install -y borgbackup
sudo mkdir -p /srv/borg
sudo chown borg: /srv/borg

Note: the borg user is not a superuser and only controls /srv/borg. The principle: keep backup access separate from administrative access.

#SSH Key Setup with a Restricted Command

#Creating and Sending the Key

From the client side:

ssh-keygen -t ed25519 -f ~/.ssh/id_borg -N "" -C "borg-backup"
ssh-copy-id -i ~/.ssh/id_borg.pub borg@backup-host

However, ssh-copy-id adds the key with full access. We replace it with a restricted command.

#Restricted Command in authorized_keys

A restricted command limits SSH to running only a specific command — here borg serve with path restrictions:

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

Let us break down the options:

• command="borg serve ..." — SSH will only run borg serve, whatever the client requests. No shell.
• --restrict-to-path /srv/borg — borg serve can only access /srv/borg; it cannot touch any other files on the system.
• --restrict-to-repository /srv/borg/backup — only one repository can be served.
• restrict — disables port forwarding, agent forwarding, and X11 forwarding.
• no-pty — no pseudo-terminal (irrelevant for borg serve, but a good security principle).

#Initializing and Backing Up to a Remote Repository

#Init a Remote Repo

export BORG_REPO='borg@backup-host:/srv/borg/backup'
export BORG_RSH='ssh -i ~/.ssh/id_borg'
export BORG_PASSCOMMAND='cat /root/.borg-passphrase'
 
borg init --encryption=repokey-blake2

Note BORG_RSH: it tells Borg which SSH command to use, including the key file. Without it, Borg uses the default ssh, which may not use id_borg.

#Remote Backup

borg create --stats "$BORG_REPO"::"{hostname}-{now}" /home /etc

Since BORG_REPO is already exported, the command above does not need to write out the full path. Borg will open SSH, the server runs borg serve, and the chunks are sent.

#Security: Dedicated User, Passwordless, seccomp

#Dedicated User

Use a dedicated user (borg) — not root, not an application user. If the backup host is compromised through this path, the impact is limited to the repository.

#Passwordless and No Shell Access

• Make sure the borg user has no password: sudo passwd -l borg.
• The user's shell is only as limited as needed. The main restriction is not the shell, but the command= in authorized_keys.
• Never add another host's key to the same authorized_keys without a restricted command.

#Borg's Built-in seccomp Sandbox

When borg serve runs, Borg leverages seccomp (Secure Computing Mode) on Linux to sandbox which syscalls the server process may make. This is a defense layer in case borg serve is attacked through malicious repo data — its capabilities are limited to the syscalls backup actually needs. You do not need to do anything: it is active by default on supported platforms.

#Common Pitfalls

• An SSH key without a restricted command: full shell access to the backup host — fix it immediately.
• Forgetting BORG_RSH: Borg uses the default SSH, which fails because the key is not found or a different key is used.
• Repo path not matching the restriction: a repo initialized outside the allowed path — borg serve refuses access.
• Root user on the backup host: every file on the backup host could be read/deleted. A dedicated user limits the blast radius.
• Not testing from a clean environment: test borg list from another host to confirm the restricted command works as expected.

#Closing

• A remote repository is written user@host:path and served by borg serve.
• The SSH key pair is restricted with command="borg serve --restrict-to-path ..." in authorized_keys.
• restrict, no-pty disable unneeded SSH features.
• A dedicated passwordless borg user limits the impact of a breach.
• The seccomp sandbox is active by default on the server side.
• Always verify: borg list succeeds, ssh ... id is rejected.

In episode 12 we maintain long-term health: check & maintenance — borg check for consistency, borg check --verify-data for content verification, a monthly schedule, borg compact, log reviews, and disk health monitoring.