Homelab backup strategie visualisatie

Backup Strategie voor je Homelab: De 3-2-1 Regel in de Praktijk

Je homelab draait je GitLab, je wachtwoorden, je foto’s, je home automation. Wat gebeurt er als de disk faalt? Als je die vraag niet met vertrouwen kunt beantwoorden, heb je geen backups. Je hebt hoop. De 3-2-1 regel bestaat al decennia omdat hij werkt. Drie kopieën, twee verschillende media, één offsite. Hier is hoe je het daadwerkelijk implementeert. De 3-2-1 Regel Uitgelegd flowchart TD subgraph rule["3-2-1 Backup Regel"] Data["Originele Data"] subgraph three["3 Kopieën"] C1["Kopie 1<br/>(Origineel)"] C2["Kopie 2<br/>(Lokale Backup)"] C3["Kopie 3<br/>(Offsite)"] end subgraph two["2 Media Types"] M1["NVMe/SSD"] M2["HDD/NAS"] end subgraph one["1 Offsite"] Off["Cloud/Remote"] end end Data --> C1 Data --> C2 Data --> C3 C1 --> M1 C2 --> M2 C3 --> Off Waarom Drie Kopieën? Kopie 1: Je live data (origineel) Kopie 2: Lokale backup (snelle restore) Kopie 3: Offsite backup (disaster recovery) Eén kopie is geen backup. Twee kopieën kunnen allebei falen in dezelfde ramp (brand, overstroming, ransomware). Drie kopieën met separatie geeft je echte resilience. ...

18 mei 2026 · 7 min leestijd · Tom Meurs
Goed ontworpen Grafana dashboard

Grafana Dashboards Die Daadwerkelijk Gebruikt Worden

Je hebt Grafana. Je hebt Prometheus metrics. Je hebt logs in Loki en traces in Tempo. Je hebt ook 47 dashboards waar niemand naar kijkt. Dashboard rot is echt. Teams maken dashboards voor elke mogelijke metric, elke service, elk potentieel probleem. Zes maanden later weet niemand meer wat de helft ervan toont of waarom ze bestaan. Goede dashboards zijn anders. Ze worden dagelijks geopend. Ze beantwoorden vragen voor je ze stelt. Ze helpen je je systeem te begrijpen, niet alleen nummers te tonen. ...

2 mei 2026 · 7 min leestijd · Tom Meurs
K3s cluster draaiend op mini-PCs

K3s Cluster Setup op Refurbished Mini-PCs

Je hebt geen cloud provider nodig om Kubernetes te draaien. Je hebt geen dure servers nodig. Je hebt drie mini-PCs en een middag nodig. Dit is hoe ik mijn homelab cluster bouwde — hetzelfde cluster dat mijn GitLab, monitoring, home automation, en alles wat ik weiger toe te vertrouwen aan andermans computer draait. Waarom K3s? K3s is Kubernetes, vereenvoudigd: Single binary — ~70MB, bevat alles Low resource — Draait op Raspberry Pi, draait geweldig op mini-PCs Production ready — Dezelfde API, dezelfde workloads, minder overhead Batteries included — Ingebouwde ingress, load balancer, storage Het is geen “Kubernetes lite.” Het is Kubernetes zonder de enterprise rommel. ...

24 april 2026 · 6 min leestijd · Tom Meurs
cert-manager automatische TLS certificaat flow

cert-manager: Automatische TLS Certificaten in Kubernetes

Handmatig certificaat management is een recept voor outages. Certificaten verlopen om 3 uur ’s nachts in een feestdagenweekend. Renewal processen leven in tribal knowledge. Teams deployen services zonder HTTPS omdat “het te ingewikkeld is.” cert-manager automatiseert alles. Definieer welke certificaten je nodig hebt, en cert-manager regelt uitgifte, vernieuwing en Kubernetes Secret management. Voor altijd. Dit is een van de eerste dingen die ik installeer in elk cluster. Hoe cert-manager Werkt flowchart TD subgraph cluster["Kubernetes Cluster"] CM["cert-manager"] CERT["Certificate<br/>Resource"] SECRET["TLS Secret"] INGRESS["Ingress"] end subgraph external["Extern"] LE["Let's Encrypt<br/>ACME Server"] DNS["DNS Provider"] end CERT -->|"watched"| CM CM -->|"maakt"| SECRET CM <-->|"ACME protocol"| LE CM <-->|"DNS challenge"| DNS SECRET -->|"mount"| INGRESS Je maakt een Certificate resource cert-manager vraagt een certificaat aan bij de issuer (Let’s Encrypt, Vault, etc.) cert-manager voltooit de challenge (HTTP-01 of DNS-01) cert-manager slaat het certificaat op in een Kubernetes Secret Je Ingress/Gateway gebruikt de Secret voor TLS Vernieuwing gebeurt automatisch 30 dagen voor expiratie. ...

12 april 2026 · 7 min leestijd · Tom Meurs
Distributed tracing visualisatie met Tempo

Distributed Tracing met Tempo en OpenTelemetry

Je hebt metrics die je vertellen dat iets traag is. Je hebt logs die vertellen dat er errors waren. Maar welke request faalde? Waar kwam de latency vandaan? Welke service in de keten veroorzaakte de timeout? Dit is waar distributed tracing om de hoek komt kijken. Het volgt individuele requests terwijl ze door je microservices stromen, en toont je precies wat er gebeurde en waar. De Observability Driehoek flowchart TD subgraph observability["Complete Observability"] M["Metrics<br/>(Prometheus/Thanos)<br/>WAT gebeurt er"] L["Logs<br/>(Loki)<br/>WAAROM gebeurde het"] T["Traces<br/>(Tempo)<br/>WAAR gebeurde het"] end M <--> L L <--> T T <--> M G["Grafana"] --> M G --> L G --> T Metrics beantwoorden: “Wat is de error rate? Wat is de latency?” Logs beantwoorden: “Welke error message? Wat was de context?” Traces beantwoorden: “Welke service? Welke call? Wat was het pad?” Samen geven ze je volledig begrip. ...

4 april 2026 · 7 min leestijd · Tom Meurs