Leaving sysadmin for SRE, what should I lab?

I have ten years in traditional infrastructure, now targeting an SRE role at a mid-size SaaS firm in Amsterdam. My concern: the interview loops I have seen emphasize "building" over "operating." I need projects that demonstrate I understand failure modes, not just how to follow a tutorial.

Current home setup: three Intel NUCs, 32GB RAM each, running Proxmox. I have built Kubernetes clusters before (kubeadm, mostly), but it feels like checking a box. What actually translates to a hiring signal? I am especially wary of GDPR implications if I mirror production traffic patterns at home; even synthetic data carries obligations under Article 5 principles.

Specifically seeking: projects that show incident response discipline, observability thinking, and cost-awareness. Not another "I installed ArgoCD" thread.

Wesh @brusselsdzire1

Le cluster حلو but have you broke it on purpose ? Incha'allah your etcd quorum dies at 3am and you have no snapshot. That is the lab. The hard-way is not the install; it is the 4h outage you give yourself.

French punctuation : I do not trust a candidate who never lost data .

Actually this is the correct approach, mark my words. I have interviewed actually dozens of SRE candidates and the ones who get offers are never the ones with the perfect Terraform modulesfusedtogether in a pristine GitRepository; they are the ones who can explain actually how they deleted a Production namespace at 2am and which Runbooks failed and why the OnCallRotation did not catch it in time, or? The KubernetesTheHardWay tutorial is actually useful exactly once, to understand what the KubeadmTool hides from you, but after that you should actually spend your time on Chaos engineering: kill your CNIPlugin, fill your DiskPartition, expire your Certificates manually. Document the Fix in an Incident report with Timestamps and Blameless analysis. That Document is your Interview portfolio, actually.

@rudi3 has the right idea, but I'm going to ask what I always ask: did you test your restore?

Before you break anything, make sure you can get back to working. 3-2-1 rule applies to your lab too:
- 3 copies of any config you care about
- 2 different media (git + local zfs snapshot)
- 1 offsite (encrypt and push to cold storage)

Your "I broke it" story falls flat if you admit you rebuilt from scratch because your backup was six months stale.

Checklist for a strong interview narrative:
[ ] Broke it deliberately (document the fault injection)
[ ] Discovered the gap in monitoring/alerting
[ ] Restored from backup and timed it
[ ] Wrote the fix AND the prevention

The prevention piece is what separates sysadmin from SRE mindset.

Which Proxmox version? 7 or 8

The restore test is what separates candidates. Mark my words.