On Mon, Jan 12, 2026 at 09:31:39PM +0000, 04-psyche.totter wrote:
> Hi all,
>
> I am looking to implement an OpenBSD server as a backup server.
>
> Critically, it will provide backup to untrusted clients, so I need the
> setup to be robust against an adversary in possession of the access
> codes.
As others have mentioned, it depends on how you define "untrusted". For
my backups my assumptions/rules are as follows:
- Clients do not have login access to the server.
- Any commands executed on the server are at the direction of the
server, never the client.
- Clients still have to trust the server.
> Does anyone have recommendations for a solid setup?
I've used dirvish [1] for the last 20 years, which looks similar to
Nick's IBS. It makes use of rsync's --link-dest to use hard links that
create full backups that only use the space of an incremental system. It
also automatically handles pruning of old (expired) backups based on a
configured schedule. Overall, it's incredibly flexible and robust. Some
may call the project abandoned, but it still works flawlessly and is
essentially a collection of perl scripts. For offsite backups of my
backup server, I have a script that uses rsync to make a copy to another
disk of the most recent successful backup of each client, which then
gets taken offsite. Trying to use rsync to copy all the backups is
impractically slow, probably exacerbated by all the hard links, but my
offsite backups are for disaster recovery, not accidental file deletion.
The server initiates the backups of each client using a cron job, and
ssh keys handle authentication. Clients' sshd limits root logins to
forced commands only via
PermitRootLogin forced-commands-only
with root's authorized_keys file specifying the command to run. A client
could modify that command, but the worst they could do is mess up their
own backup, as the server handles where the incoming data is stored. On
the positive side, I can add to the command to run local commands first,
such as database backups to be run immediately before the file transfer.
All the client gets is the server's ssh public key (which is best as a
different key than root's primary key, due to the forced-commands
restriction on that key), and copies of ssh public keys are not a useful
attack vector.
Because the client doesn't have access to the server's data, the server
admin is going to have to be involved in any recovery process. Assuming
you are backing up clients that you are responsible for, this shouldn't
be an issue. If you are trying to run a cloud backup service for people
who aren't otherwise associated with you, that's a much more complicated
system because by necessity they need access to the data stored on the
server and I'm assuming you're operating on the internet in such a case,
not a local network.
I'm also assuming you are backing up UNIX-like clients. I've only
used this for backing up OpenBSD and Linux clients.
Stuart
[1] https://dirvish.org/
--
Stuart A. McKim, P.E.
Idaho Falls, ID
