How to secure backup access

Quick answer: Give backups their own credentials: a dedicated user on the storage server, a dedicated SSH key on each source machine, and the narrowest possible permissions. The goal is one-way glass — production can write new backups, but a compromised production server cannot read other machines' data or delete history.

Overview

Your backup server concentrates copies of everything you own, which makes it both a target and a liability. Two failure modes matter: an attacker reaching the storage box directly, and an attacker on a production machine using its backup credentials to destroy the safety net. Both are preventable with boring, standard hygiene.

Before you start

• A working backup flow to a Storage VPS or similar target.
• Basic SSH key management (guide).
• Ten minutes per source server to swap shared credentials for dedicated ones.

Step-by-step guide

1. One user per source machine on the storage server — never a shared account:

   adduser bk-web1
   mkdir -p /srv/backups/web1 && chown bk-web1:bk-web1 /srv/backups/web1
   chmod 700 /srv/backups/web1

2. One key per source, used only for backups, with a restricted command if you can:

   # /home/bk-web1/.ssh/authorized_keys
   command="rrsync /srv/backups/web1",restrict ssh-ed25519 AAAA... backup@web1

   (rrsync ships with rsync and pins the key to one directory.)
3. Harden the storage server itself: key-only SSH, no root login, firewall allowing SSH from your servers' IPs only, fail2ban.
4. Protect history from deletion: pull-style backups, snapshot layouts where sources cannot touch old directories, or append-only repos:

   borg serve --append-only          # in the forced command
   restic ... # with an append-only rest-server

5. Audit quarterly: list authorized_keys, remove servers that no longer exist, and check last-login times for surprises.

Common issues

• Production's root key on the backup box: whoever owns production then owns every backup — invert it with dedicated limited users.
• World-readable backup directories: one leaky account exposes all clients' data — chmod 700 per directory.
• Delete rights everywhere: if the nightly job's key can prune, ransomware can too; separate write and prune credentials.

When to contact support

Security of your OS and keys is customer-side on unmanaged plans, but open a ticket if you suspect the storage server itself was accessed abnormally — network-level logs can help establish what happened.

Frequently asked questions

Why should each server get its own backup user?

Isolation: with one user and directory per source machine (chmod 700), a compromise of any single server exposes only its own backups, never the other machines' data.

What is an append-only backup repository?

A mode where backup credentials can add new data but not delete or overwrite history — borg serve --append-only or a restic rest-server flag — so ransomware cannot erase old snapshots.

How do I restrict an SSH key to backups only?

Prefix it in authorized_keys with a forced command and restrictions, e.g. command="rrsync /srv/backups/web1",restrict — the key then works for that directory and nothing else.

Related articles

• How to encrypt backups
• How to set up SSH keys
• Local backup vs remote backup
• What to do if your server is compromised

Need a hand? Contact Cloud2Y support →