Andreas Voss

I've Decided to Stop Trusting Big Tech With My Data

2026-03-30T08:37:00+0000

Alright. In hindsight I might’ve been a bit too optimistic committing to publishing a post every few weeks. How long has it been at this point? Five months. Time really does fly by, but better late than never I suppose. I really want to write quality posts for you, but that takes time, effort, and the right motivation. I finally found all three and here I am again, writing about something as interesting as backups. No, please don’t leave. I swear it’ll be good!

Whom would you entrust with your deepest thoughts

For as long as I can remember, I’ve been concerned about privacy. Not for any particular reason, I just believe that it’s a basic right for everyone and the European Convention on Human Rights backs me up (pun intended). Data has become a highly valued commodity used for everything from advertising and training large language models to oppression by nation states. It seems like anyone who can get their hands on my data will try to monetise it or otherwise abuse it.

All these seemingly free services I’ve enjoyed for years have notoriously exploited my data to make money. While I acknowledge that I’ve gained some value from these services, it’s likely that I got the short end of the stick. Given the current political situation, with wannabe dictators rising to power and corporations finding new ways to monetise my data, I think it’s due time I did something about it, and I’ll start by bringing my data home and hosting it myself.

That doesn’t sound too difficult. I’ll just download all my data, delete my accounts, and slam bam, job done. Well, not quite. One thing these cloud services have provided me was the peace of mind that if I were to lose my laptop or phone, the data I care about, such as pictures or source code would not be lost. So I need a way to back up my data without giving large tech companies any control over it. That’s the goal of today’s post.

Narrowing down the options

Before this, I’d never really thought of backing up my data explicitly. I’d used one service for synchronising important files on my desktop, another one for keeping my photo library safe and a third one for hosting source code. I had no control over these services. I didn’t know how they were implemented, and I couldn’t verify that they would actually keep my data safe and private. In order to remedy this, I’ll have to find a backup solution I can trust or verify - preferably both.

Since I’m already using Proton for e-mail, I first considered just using Proton Drive which is their cloud storage product. However, a few things deterred me. Mainly the fact that their SDK is not ready for production and that I couldn’t get the Rclone Proton Drive backend to work properly, which would be important for automating the process. The steep price of €10 for 500 GB also didn’t help. Then I started considering what I actually needed:

a vendor agnostic solution
that I can easily automate
which encrypts my data
with no proprietary client
that supports incremental backups

With those requirements in mind, I had another look at Rclone. It supports lots of providers and protocols, and it even has virtual providers for encryption and compression, which seemed really promising. Unfortunately it’s not designed for backups. While I could probably make it work with a bit of hacking and scripting, I would rather not have a fragile and potentially complicated backup solution to maintain. That meant going back to the drawing board and researching alternatives. I found a few tools that looked promising like rsnapshot but the one that really caught my eye was the purpose-built and modern backup program Restic. It ticked off all the boxes and is highly configurable while still looking quite simple to use, so I decided to evaluate whether it could work for me.

Restic supports a bunch of different storage options including using a local directory. This meant I could play around with it without needing any cloud storage. I’ll go through the process in more detail in the next section. For now, I installed the binary, ran a few commands, and ended up with an encrypted backup stored locally. Being able to create a local backup repository means that even if Restic doesn’t support the storage medium I want, I can just copy the repository anywhere.

With that in mind, I proceeded to look at hosting options. I just wanted something cheap, hosted in the EU. It didn’t take long before I stumpled upon Hetzner’s Storage Box, a simple storage server that supports a few different modes of transfer including SFTP, which provides me with 1 TB for €4 per month - a much better deal than what I would get from Proton. I’m not affiliated with Hetzner, I chose it because it seemed like a decent, cheap option that satisfied my requirements.

Restic in practice

Once the restic binary is installed on the system I want to back up, I can either initialise a new repository or execute commands on an existing one. I’ll go through the entire flow of setting up a new repository for the sake of completeness.

Since I’ve decided on using SFTP for my backup I’ll add the public part of my SSH key for authenticating to the server, then initialise my repository. When initialising the repository I’m prompted to enter a password. This password is used to encrypt my data and will be required for any subsequent commands. I need to keep the password safe. If I were to lose it, I wouldn’t be able to access my backup again. Ever.

# For an SFTP server - more connectors available here: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
➜ restic init -r sftp:user@server.com:/backup

# Alternative: for a simple directory repository
➜ restic init -r ~/backup

The largest annoyance I found when using Restic, and especially when using a non-local repository, is the fact that I have to provide the repository and password for every single command. Luckily, this can be remedied by setting a few environment variables, and as long as you don’t have a lot of different repositories to manage, this makes everything extremely simple. Since I’m using Nix I’ll use sops-nix to create two files, one with the repository path and one with the repository password and set the following environment variables.

➜ export RESTIC_REPOSITORY_FILE='/run/secrets/restic-repo'
➜ export RESTIC_PASSWORD_FILE='/run/secrets/restic-pass'

Now I can just issue the commands without thinking about the repository or the password.

There are other ways to resolve the password including providing Restic with a command it will run instead of asking for the password. It will then use the stdout from that command to authenticate. That means you could get the password straight from your password manager if it has a CLI. I’m using Bitwarden so something like this would resolve the password directly from there

➜ export RESTIC_PASSWORD_COMMAND='bw get password 00000000-0000-0000-0000-000000000000'

That’s pretty cool.

There are a more options for passing the parameters to Restic, so you’re not limited to what I’ve covered. Run restic --help to explore the alternatives.

I think that’s enough plumbing for now, let’s start backing something up. One of my most precious directories is ~/photos, so let’s back it up.

➜ restic backup ~/photos

Wait, what? Is it that simple? Yes it is! I now have a snapshot I can view using restic snapshots.

➜ restic snapshots
ID        Time                 Host        Tags        Paths                     Size
------------------------------------------------------------------------------------------
36b31249  2026-03-30 10:17:16  argon                   /home/andreasvoss/photos  4.716 GiB
------------------------------------------------------------------------------------------
1 snapshots

In case I were to accidentally delete some files in the ~/photos directory, I would be able to recover them from the snapshot using the restic restore command providing it with a snapshot ID along with a target. So let’s delete some files then restore them from the snapshot!

➜ ls ~/photos
birthday-party  wildflower-ultra
➜ rm -rf ~/photos/wildflower-ultra
➜ ls ~/photos
birthday-party

I’ve deleted one of my valued photo albums, so I really hope restoring it from the snapshot is going to work. In this case I just want to place the files where they were originally, so I’ll give the / directory as my target. Depending on the situation, you might not want to restore in place though.

➜ restic restore 36b31249 --target /
➜ ls ~/photos
birthday-party  wildflower-ultra

That’s it. Simple. Elegant. I have only just scratched the surface of the possibilities you have when using restic, so I encourage you to dive into their documentation and give it a whirl. Here are a few commands I’ve found really useful

restic diff - get the difference between two snapshots, useful if you notice a significant change in snapshot size
restic forget - delete snapshots and can be used to delete snapshots that are older than a specified age
restic check - check the backup repository for errors to ensure you’ll be able to restore from your snapshots
restic ls - list the files in the given snapshot

Now that I’ve set up my backup repository I just need to automate it.

Reducing the cognitive load through automation

Backing up files manually isn’t ideal, and since I’m only human, I might forget. There are a couple of options to choose from when looking to automate the process, mainly using either crontab or systemd-timers. When using Nix, it’s recommended to use systemd-timers, so that’s what I’ll do. I’m pretty sure that most of you won’t be using Nix, so here’s an example you can use without it. It’s not too bad. It’s just a couple of simple unit files and an executable script, let’s walk through it.

The backup.service unit file is just a oneshot service that points to the script I’ve made to execute the restic backup command.

[Unit]
Description=Backup

[Service]
ExecStart=%h/backup-service/backup.sh
Type=oneshot
User=andreasvoss

The backup.timer will start the backup.service on the schedule defined by the OnCalendar. I’m interested in a daily backup, so I’ve set this value to daily. You can make pretty advanced schedules with systemd-timers. In case you need that the ArchWiki is a great resource for learning about the options.

[Unit]
Description=Backup

[Timer]
OnCalendar=daily
Persistent=true
Unit=backup.service

[Install]
WantedBy=timers.target

Finally backup.sh will do the actual work using Restic. There is not much to explain that I haven’t already covered , with the exception of the --tag flag I am passing. I want to be able to differentiate between manual backups and automatic ones, so I’ve added a couple to tags my automatic backups. You can use these tags to filter snapshots when listing them, which is pretty neat.

#!/bin/sh

restic backup /home/andreasvoss/photos \
    --tag daily,automatic \
    --repository-file /run/secrets/restic-repo \
    --password-file /run/secrets/restic-pass

The files in my example are stored in ~/backup-service so I’ll create symbolic links to ~/.config/systemd/user, make the script executable then enable and start the timer

➜ ln -sf /home/andreasvoss/backup-service/backup.service /home/andreasvoss/.config/systemd/user/backup.service
➜ ln -sf /home/andreasvoss/backup-service/backup.timer /home/andreasvoss/.config/systemd/user/backup.timer

➜ chmod +x /home/andreasvoss/backup-service/backup.sh

➜ systemctl --user daemon-reload
➜ systemctl --user enable backup.timer
➜ systemctl --user start backup.timer

There we go, my backup is now automated and my important data is safely stored.

So what’s next?

Now that I know my data is backed up securely at a secondary location, I can think about how to conveniently access my data like I was able to with cloud services I’ve now replaced. I have looked at a couple of really cool projects I want to self-host like Immich, Gitea and Syncthing. I’m going to explore these further, so stay tuned for more blog posts once I’ve had time to experiment a bit.

]]>

Why in the World Do We Need Another Programming Blog

2025-10-19T12:00:00+0000

Well, the short answer would probably be that we don’t. However, in the era of LLM-slop (you know those uncanny articles that look vaguely helpful but somehow says nothing), it’s sometimes nice to get the perspective from an actual person. I hope I can provide interesting, useful – and occasionally funny – posts about the challenges I face and the solutions I find to solve them. This can hopefully help you with whatever you are struggling with, present you something worth considering or perhaps just give you a brief smile on your face as I wade through yet another ‘great’ (read: frustrating) experience with a Microsoft product wink wink.

Before you expect life-changing productivity tips

First of all I want to say that I don’t believe those even exist. The life-changing productivity tips that is. To truly become good at anything even being productive you just need to work hard at it – that might sound boring, but to me it’s very rewarding working towards something to eventually get to the place you want to be. Whether it’s a video game, an academic or physical accomplishments, learning new programming tools or something completely different, the reward for working at something just feels amazing.

And this blog will definitely not be your “10 productivity tips to boost your performance” kind of place. It’ll be messy, opinionated, and honest — the way programming tends to be. I might write a guide once in a while, but mostly to be able to reproduce something for myself in the future — in case I forget. But hey, if it can help you as well that’d also be a very nice bonus.

Anyway, enough about what this blog isn’t – let me tell you why I decided to start it.

So really, why?

I actually have several reasons for starting this blog. I’ve been thinking about it for a while, and what finally pushed me to do it was an event about a month ago – when I had to deal with managed certificates for Azure App Services. I already know what you are thinking: who in their right mind would work with Azure? Honestly, I have no idea - but that’s where life has taken me for now.

Anyway, one of my co-workers and I made a proof of concept in Bicep - some infrastructure as code that would automatically create a DNS record in a predefined DNS zone, and then request a Microsoft-managed certificate for that address. It actually went very smoothly. Everything seemed to work perfectly, I was able to get a certificate for each of our environments for the application we were testing with, and in case we manually removed the certificate in the portal, we could just run our IaC and it would be fixed.

Great, we thought. So I started rolling it out to all our applications on a Friday (I know - offensive to some people). And then suddenly, my pipeline failed with some obtuse error that I can’t quite remember, but it was something along the lines of

{
  "code": "ResourceDeploymentFailure",
  "details": [
    {
      "code": "BadRequest",
      "message": "Pending managed certificate failed: Pending certificate expired. Please try again. Refer to the documentation for more info ..."
    }
  ]
}

However, the certificate resource just kept spinning in the Azure portal for hours before finally failing to be created there. Weird.

Meanwhile when trying to stop the deployment and create the certificate through the az CLI, we got an entirely different error about the certificate already existing. Alright I thought, if there is a conflict I might be able to fetch it or delete it through the CLI. Once again I was left disappointed with a ‘Not found’ error.

# Real parameters anonymized
az webapp config ssl create --hostname sub.webapp-host.com -n webapp-name -g webapp-resource-group 
# Operation returned an invalid status 'Conflict'

az webapp config ssl show -g webapp-resource-group --certificate-name sub.webapp-host.com
# Operation returned an invalid status 'Not found'

We spent hours trying to figure out if we’d hit some undocumented limit, or if there were outages at Azure or DigiCert - the entity that provides the certificates. Nothing. In desperation, we even asked an LLM for help - only to have it confidently hallucinate a completely imaginary limit of custom domain certificates for app services (we knew it was imaginary because we can count – and we’d already exceeded that limit).

Eventually, we gave up for the day. Luckily it wasn’t critical and could easily wait until Monday. Of course, I couldn’t wait. I ran the pipeline a few times Friday night, a few more on Saturday, and finally – on Sunday morning – I saw the green bliss of a pipeline that hadn’t failed. Our solution worked, the one we also thought worked a few days earlier. Our cloud provider and a chatbot had just successfully convinced us that we were the problem. That whole ordeal wasted a significant amount of time – and caused more than a little frustration.

The episode also made me realise I wanted (or maybe even needed) a place to vent, reflect and maybe laugh about it later – hence, this blog.

A professional procrastinator looking for purpose

A few weeks later, I finally had the time – and excuse – to get started. I had three weeks of vacation without anything particular planned. I figured it would be nice to work on a project instead of just endlessly procrastinating by scrolling Reddit, or watching an absurd number of videos on everything from how a dehumidifier works (in excruciating detail, I might add) to urban planning. Since I had just gone through that Azure experience, it was the perfect opportunity to get started on my blog.

I didn’t feel like just creating a generic Wordpress site – not that there is anything wrong with that, I’m just a control-freak. I wanted to build my own site from scratch and preferably learn something along the way.

I started looking into React and Next.js for my stack, mostly because I was vaguely familiar with those already. But I quickly realised working with those JavaScript frameworks just isn’t fun. There are so many dependencies for even the simplest things – and the recent supply-chain attack on npm didn’t exactly boost my confidence in that ecosystem.

So instead, I started looking for alternatives and soon stumbled upon Elixir and Phoenix. I’d heard really great things about Elixir, and getting some more hands-on experience with a functional programming language seemed like a fun challenge – especially since I’ve barely touched functional programming since coding in SML and Scheme back in university.

I started small – solving a few programming exercises to get my hands dirty while going through the Getting Started section of the Elixir hexdocs. The documentation is genuinely excellent, I rarely needed to look anything up elsewhere.

I wrote a few scripts, some modules to play with functions and structs, experimented with maps and collections and the Elixir concurrency model. Before long, I found myself remembering both the excitement and confusion of functional programming from back in the day – especially when diving back into recursion.

After a few days, I’d built up some familiarity with this (to me) new and exciting language, Elixir. I know it takes a long time to really get good at a new language, but in my opinion, there’s no better way to learn than by building something real.

So I decided to jump into the deep end and try my hand at the Phoenix Framework - a web framework for Elixir. The very first thing you’ll see when you go to their website is a bold tagline promising

Peace of mind from prototype to production

That’s exactly what I needed – a framework that is stable, opinionated, and fun to build with! A few weeks (and an undisclosed number of coffees) later, this blog was up and running.

I don’t want to go into too much technical detail in this post, since I might write another one about it, but I drew a lot of inspiration from this post by Sebastian Seilund from 2016. It really helped me kick-start my development and have a solid foundation to keep building on.

Of course, there were other technologies I had to brush up on as well. I really hadn’t touched HTML and CSS in any meaningful way for years. I’d of course heard of Tailwind, but never actually used it to style anything properly. And even though I said I don’t really enjoy working with the JavaScript ecosystem, I still ended up installing highlight.js through npm in order to have nice looking code blocks in my blog posts – and some JavaScript will be required if I ever want to work with the Phoenix JavaScript interoperability.

So, everything isn’t always quite so clean-cut.

Wrapping up (before I break something)

This site is my playground, and from time to time I’ll probably break it (by accident) – but that’s alright. It’ll just give me something to write about, and let’s be honest, development horror stories are always the most entertaining ones. On a serious note, I’ll do my best to post once every couple of weeks for a start, while also continuing to tinker with and improve the site along the way. I’m not exactly where this little project will go yet, but I’m excited to work on it nonetheless – and to bring you along for the ride.

My excursion into Elixir gave me quite a few ideas, and right now I am going through the book ‘Writing An Interpreter In Go’ by Thorsten Ball – except I am not writing it in Go, I am however having a go at implementing it using Elixir (sorry not sorry).

Please don’t hesitate to get in touch with me – either in case you want us to work together, or you have a suggestion for something you’d just love to see me dive into (or just want to say hi), I’d love to hear from you. You can find my contact information here.

So, do we really need another programming blog? Probably not. But this one exists – and that’s good enough for me.

]]>