It sounds like you’re trying to learn but have an “all or nothing” mentality to going about it. Nothing is mastered all of a sudden and expecting mastery out the gate is a recipe for burn out. If you’re goal is absolute perfection then you’ll never even start.

Go through the online docs and training resources first to gain an understanding of how to assemble playbooks without a direct implementation target attached.

Once you have a sense of what Ansible is and what it can do for you, pick something small to do for yourself. For example, create a playbook that sets up nginx for a single purpose.  When there are a 100 different ways to do something, you’ll never do it right. You’ll do it acceptably, then you’ll do it again better and then you’ll do it again more flexibly, etc.  If you know or pick up Python then you’ll start being able to dive into custom modules and plugins.

A toolkit is something you build over time. You build it over time because it’s impossible to know what you’ll need before you start. If you do end up pulling together a toolkit that you think it appropriate and complete before you start working then you’ll have a mess of configurations that are not applicable and mostly inappropriate that you’ll end up debugging forever.

Start small. Start where you are.

• how do you use ansible? Is there a good source for roles or playbooks to set up services? I feel like ansible is 30% more headache right now during config.

I write my own playbooks and roles, but often I can just copy paste an existing setup and use it for a new service. For example containers, you can probably write one role once, copy it and modify some variables to set up another container service.
For stuff where there are well maintained community roles (e.g. community.zabbix) just use those and configure with variables.

• how do you deal with motivation loss?

I just don’t work on a part I don’t want to do atm. It’s supposed to mostly be a hobby and as long as my services I care about are running it’s fine.

• how do you deal with the overwhelming amount of choices and information and disciplines (networking, storage, VMS, Linux…) that comes with selfhosting?

I’m on my 2.5th setup now, just choose something and see if it works. If not, see how much it bothers you and what parts you want to migrate.
I’m a big fan of VMs, so I’m using XCP-ng. IMO this makes testing and backups very easy, I just take a snapshot and figure stuff out, no big deal if it breaks.

• how do you find the sweetspot between ease of use, ease of set up, security, redundancy? I feel like I am maybe too pranaoid to loose my data again (dropped a hard drive many years back, I lost all of my projects)

You’re better than 95% of people just by thinking about this. For backups, identify which data you want to back up and do that. If you don’t want to deal with Ansible right now, just set something up manually and automate it later (paste your commands into a readme for reference)
For me, I make sure to backup my Nextcloud data. That included personal photos, files and other hard to replace stuff. Other than that I have daily VM backups to a Hetzner storage box and my NAS. I don’t backup my media on Jellyfin, that’s just not as important.
VMs also make it easy to replace your host. Just install the hypervisor on a new server and restore VMs to it.

• maybe overall, how do you manage your perfectionism?

I guess I’m not a perfectionist. It took me multiple months and monetary incentive (avoid renting two servers) to migrate from my Debian single host setup to VMs years ago.
Some of my Ansible playbooks are “version 1”, where I didn’t know what I was doing. I’m on version 3 now. They still work, I even use some of them occasionally, just haven’t taken the time to migrate them yet.
Maybe you can take a similar approach with some of your services that aren’t that essential and spread out the work more so you can enjoy it when you want to.

My fear is, that if i don’t document well or not use ansible, I will be hating my life once my server dies and I have to restore my data and also set um my services again in a few years.

I’ve been there plenty of times, you’re not alone. There are two solutions to that problem, really, and it boils down to the classic pet vs cattle.

1. Everything is a pet

Pets mean you care about every server. If it breaks, it’s cheaper for you to fix it than redeploy. The overwhelming majority of your setup will be pets. Why? It’s simpler. Things don’t break that often, and when they do, it’s okay to be low-effort in fixing them.

Write docs for yourself, even if it’s just notes on the sequences of commands to run to redeploy things. You will thank yourself when the server finally dies in two years and you have notes on how to bring everything back.

1. Everything is a cattle

Cattle means there’s no difference between server A and B. Everything is replaceable. Ultimately, whatever you run can run to the same extent in AWS, your basement NAS, or on your desk PC.

Cattle is also a lot of work. You will learn an excruciating amount of things about storage, networking, visualisation, workload scheduling, and such. And it’s easy to be demotivated because of how much there is to learn.

So take it easy. Concur that your hobby world is full of pets, but learn how to do the cattle approach at your leisure. You’ll realise that in every practical cattle setup, there are still pets, and that automating yourself from complexity only means you add layers of somewhere else.

I’ve just been using debian with docker compose for over two years, and everything just works. The only reason I would have to use ansible at this point would be if I wanted to replicate the setup.

My successful path for homelab stuff is to use kubernetes (k3s locally and digital ocean DOKS for cloud resources) with argocd and gitops. Everything I change is via a git commit+push so I can always rollback, and if this machine dies, once I replace/repair the hardware I can pull all backed up content from object storage, install K3s again, reconfigure the authentication for Argocd, and it will repopulate all the running services.

I am absolutely not saying this is the right path for you as I came into nearly all my modern knowledge through my career, but it is a path

Don’t use Ansible and use Nix instead.

Seriously though give yourself time and a solid goals you want to achieve, it’ll take time and it’ll be worth it as

I just aim for “good enough”. Does it work, does it meet my needs? That’s good enough, even if it isn’t exactly the right way.

Like right now I have a system that needs manual intervention if I shut it down, or it’ll come back up non-functional. But it works well enough so I’ll just fix that eventually. I like to spend my free time doing more social or productive stuff.

ditch ansible

learn nixos

be motivated

My motivation to use Ansible is fueled by disdain for manual non-scriptable configuration. I’ve had to use Windows for a couple years lately, and the absence of programmatic access to many things annoyed me to no end.

Now, I get up in the morning and look to the east. I salute the sun and thank the fate for the chance to do proper configuration again. I don’t wade through dialogs for hours anymore. I don’t lose track of things that I’ve changed somewhere sometime. I’ll learn what the hell the difference between dconf and gsettings is, just to use one of them for all my desktop settings forever. I will have this config for years to come, and I will put more things in it bit by bit.

Now, if Ansible’s config language wasn’t a naive reinvention of Lisp, that would be great.