For the longest time I was running borg on my server to do backups. Then one day I changed my destination’s name to something different (different domain name). I know with borg, if the backup destination changes, borg will prompt you on the next run that the destination is different than before, and to confirm the change. I ran my borg backup script, confirmed the destination and all was good…​ until next run. Suddenly, I found my backup script failing. Wondering why, I appended > /root/backup.log 2>&1 to the end of the cron job so I could see why.

Warning: The repository at location ssh:// was previously located at ssh://
Do you want to continue? [yN] Aborting.
Repository access aborted

Obviously since this was a cron job, I wasn’t there and the backup aborted. So, I went in and removed the borg data in $HOME/.cache and $HOME/.config. No dice.

Turns out, I should be a better reader, because as I typed this I thought I came across a hidden "WAT" decision. But if you look at the top of the root user’s crontab (which is the user that ran my backup script) you will see HOME=/var/log. Sure enough, my borg data was showing up in /var/log. So in my backup script I set HOME=/root so I didn’t mess with any defaults.

Now, I’m not sure why the default is /var/log, but if there is one thing I have learned from using OpenBSD is to read carefully and you will get the answer. These days it becomes so easy for me to skim something and look for the quick answer, and then miss out on the important and obvious details. I constantly fall into this trap, but I think over the last year of me using OpenBSD full time in some respect, I have learned about some personal setbacks in how I approach technical problems.

If you are like me and are trying to take a shortcut, maybe invest some time too in learning to take it slower and really think critically about what your problem is, and not be so quick to go to a forum or something. Critical thinking and patience are good traits to have.