I began recently backing up my OpenBSD configurations in git repositories.

So, why do I do this ?

Remember : back up your shit or your shit will get back at you.

I think this is a way easier backup system compared to Borg backup for example.

This is fully inspired by etckeeper, from the GNU/Linux world, and yet made up to my own sauce to fit better my needs.

That process could actually be used for any Unix-like machine and any configuration directory. This is not limited to OpenBSD nor /etc and you can adapt it to your situation, distribution or preferred version software system. Anoter positive aspect : it works well for a server (permanently connected) as well as a desktop or laptop.

NB : I really wanted to use Got, but I cannot figure out how to make it work. I would like it though because pledge and al of the good OpenBSD coding practices … So if someone figure it out, please send me your article and it will be my pleasure linking it up and trying the method myself.

It also allows me to clone, transfer and and set up a machine quite fast as well as having access to various versions of your configuration and being able to reproduce it, depending on time and expected results (files that were modified at which date…)

What to back up ?

Opposite to etckeeper, I am not backing up the entirety of /etc, I don’t see the point of that. I only backup stuff that I modified myself or that I consider really important to the machine.

These are the files that I include in the first commit in the system.


I also backup all files specific to the machine (the .local) or that I wrote myself, those needed to run softwares, be they in Base or from paquetages or the internet.

So this include /etc/rc.conf.local, the configuration file for daemons specific to the machine, /etc/daily.local and the others.


You need to have a git server installed somewhere safe. You don’t even need that machine to be running OpenBSD or the distro that you might backup. You could almost use Github or Gitlab repositories but I think it’s obvious how a bad idea that is. Ideally, that server does not host any public repository, as it will host your entire network’s configuration.

You can of course strengthen your access control, but the safer, the better, and the safest is a machine that is not accessible to the internet. Then you can fine tune that access within your own team.

You can, on the opposite, make that machine available to your inner network, maybe install something like Gitea to have easy reading access to each machine configuration.

Once again, the choice is yours.



You can actually initiate this process right after the installation of the machine, even before any customization.

I will describe here the process of including a machine that I will call “ex” (for “example”) into that backup system. That machine has been freshly installed. These are the first commands I typed after the first reboot.

First, you need to install git. Then right after that, you need to create the ssh keys needed to connect to the git server.

# pkg_add git
# ssh-kegen

You can then mail the public ssh key (I was able to mail the key as my mail server is in my home network. Might not be so easy for you maybe.). This is going to be important as you need that key to connect safely to the git server.

# cat /root/.ssh/id_ed25519.pub|mail admin@domain

On your personal computer, you’ll read your mail and be able to copy the public key you just sent yourself.

I use gitolite to manage my git repositories. This offers great ways to manage who can access your configuration repositories. This is where you can tune the access to your configurations. Keep the safety in mind.

It is rather important that you have a naming convenion.

I call the repositories $directory-$machine. And I call the keys $user-$machine.

So in conf/gitolite.conf:

repo    etc-ex
    RW+     = stephane
    RW+     = root-ex

You have to create a file root-ex.pub in the keydir directory with the mail you rec .

git add conf/gitolite.conf
git add keydir/root-machine.pub
git commit -m "add machine XYZ"

Voila ! Now you have a repo ready to have your machine configuration


Back on the machine, let’s initialize the git index as well as add all those starting files.

# cd /etc
# git init
# git add ....
# git commit -m "first commit"
# git remote add origin git@server:etc-ex.git
# git push origin master

Keeping the system running.

Now, every time I modify a file in /etc, I will add it to git and comment in the commit message why I did what, then push on the server.

cd /etc
nano ...
doas git add file
doas git commit
doas git push origin master


Now that the system is installed and initialized, you just have to keep it running. For that purpose, I have added these lines to the /etc/daily.local (which is itself in that list of backed up file remember).

cd /etc
git add -u && git commit -m "update"
git push origin master

What that does is update all the files in /etc that are already into the git repo but not up to date, create a commit with a generic “update” message, and send it to the backup server.

So if I modify some files but forget to back them up, that will be done automatically. On a desktop or laptop, that should be done both daily and at shutdown.

Duplicate a machine

To duplicate a machine, you first have to give the destination machine access to the repository you need to clone.

Right after installation of that machine, install git and generate an ssh key like described before and mail that key to the admin. On your personal machine again, copy that key into the keydir (if it’s not present already) and add it to the gitolite.conf file.

So if you need to copy the configuration from your super server called “Einstein”

repo    etc-einstein
    RW+     = stephane
    R       = root-ex

Then push that up. Fine, you can now fetch your configuration on your new machine.

You cannot import your configuration directly into /etc as the directory is not empty. So I clone the repo in /tmp and copy its content into /etc.

# cd /tmp
# git clone git@server:etc-einstein.git
# cd etc-einstein
# doas cp -a * /etc

Voila. Should be good. Of course, you have to edit and tune your configuration to fit what you want in the end. After all, the whole idea of cloning the machine was to start from a known base. Now you need the actual ip addresses, etc.

And you need to give it a hostname, because it now has taken the name of the cloned machine !

As soon as all is in place, you also need to create a git repo also on this machine as described earlier in the initialisation phase in order to start again the backup system.

Generating and sending the ssh key itself is useless as you have already done it but the rest is the same.