Distributionen & Auswahl

Welche Linux-Distribution passt zu deinem Server?

Technisch nehmen sich RHEL, SLES, Ubuntu LTS und Debian erstaunlich wenig. Die Entscheidung fällt über Supportdauer, Herstellerzertifizierung und Betriebskosten, und genau dort liegen die Unterschiede, die im Betrieb tatsächlich weh tun.

5 Kapitel mit allen Befehlen
Zwei IT-Fachleute vergleichen Optionen an mehreren Bildschirmen
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Die Auswahl fällt schnell, sie hält aber ein Jahrzehnt

Auf Paketebene nehmen sich die großen Server-Distributionen wenig. Der Kernel ist derselbe, systemd steuert überall die Dienste, LVM verwaltet die Volumes, nftables filtert den Verkehr. Wer einen Server administrieren kann, findet sich auf jedem dieser Systeme in kurzer Zeit zurecht. Genau deshalb wird die Auswahl oft nebenbei getroffen, meist so, wie der erste Server im Haus eben aufgesetzt wurde.

Teuer wird das erst später. Eine Distribution bleibt zehn Jahre und länger im Bestand, und mit ihr bleiben Release-Rhythmus, Paketalter, Patch-Fenster und die Frage, ob dein Anwendungshersteller die Plattform überhaupt unterstützt. Das Ende von CentOS 7 hat vielen Häusern vorgeführt, was passiert, wenn diese Fragen nie beantwortet wurden und der Supportzeitraum abläuft, während die Anwendung noch produktiv ist.

Drei Fehler tauchen dabei immer wieder auf. Erstens der ungeplante Wildwuchs, bei dem RHEL, Ubuntu und Debian nebeneinander laufen und jedes Update doppelt getestet werden muss. Zweitens die Annahme, ein kostenloser RHEL-Klon spare einfach nur Subscription-Kosten, obwohl damit auch Herstellersupport und Zertifizierungszusagen entfallen. Drittens die Wahl einer Distribution, deren Werkzeuge im Team niemand beherrscht, also weder dnf und SELinux noch zypper und der Multi-Linux Manager.

Miniatur-Szene: drei Server-Podeste nebeneinander, davor eine Waage zum Vergleich zweier Optionen
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Sechs Kriterien in fester Reihenfolge

  1. 01 Anwendungs- und Herstellersupport
  2. 02 Supportdauer und Lifecycle
  3. 03 Subscription oder Community
  4. 04 Paketaktualität und Release-Takt
  5. 05 Know-how im eigenen Team
  6. 06 Hausstandard und Ausnahmen
Was du mitnimmst

So sortierst du das Feld

Statt einer Rangliste brauchst du eine Reihenfolge von Fragen. Die folgenden Punkte führen dich in der Regel innerhalb eines Workshops zu einer belastbaren Entscheidung, die du auch gegenüber Einkauf und Revision vertreten kannst.

Zuerst die Anwendung fragen, nicht den Geschmack

Wenn SAP, eine Datenbank-Appliance oder eine Branchensoftware im Spiel ist, entscheidet deren Support-Matrix. SLES for SAP und RHEL sind dort meist explizit gelistet, Debian und die RHEL-Klone häufig nicht. Diese Prüfung steht vor jedem technischen Vergleich.

Supportdauer gegen die Lebensdauer der Anwendung legen

RHEL und SLES bieten zehn Jahre Lifecycle mit optionalen Verlängerungen, Ubuntu LTS fünf Jahre plus ESM über Ubuntu Pro, Debian rund fünf Jahre inklusive LTS. Rocky Linux und AlmaLinux folgen dem RHEL-Zyklus. Läuft die Anwendung länger als das System, planst du das Upgrade schon beim Aufsetzen mit ein.

Ehrlich klären, was eine Subscription liefert

Bezahlt wird nicht das Betriebssystem, sondern Zugang zu Errata mit definierter Reaktionszeit, Kernel Live Patching, Werkzeuge wie Satellite oder Multi-Linux Manager, Insights und ein Eskalationsweg im Störfall. Wo dein Team diesen Weg im Ernstfall braucht, lohnt der Vertrag. Wo es selbst repariert, reicht oft ein Klon.

Paketaktualität gegen Planbarkeit abwägen

Enterprise-Distributionen frieren Versionen ein und pflegen Sicherheitsfixes zurück. Das ist gut für stabile Serverdienste und lästig, wenn du eine aktuelle PHP-, Python- oder Container-Toolchain brauchst. Für den zweiten Fall greifst du zu Ubuntu LTS, zu Modulen und Application Streams oder trennst die Laufzeitumgebung sauber im Container ab.

Vorhandenes Wissen im Team als hartes Kriterium behandeln

Eine Distribution, die niemand im Haus kennt, kostet dich im Betrieb mehr als jede Lizenz. Prüfe konkret, wer SELinux-Kontexte debuggen, mit dnf und Leapp umgehen oder AutoYaST und den SUSE-Stack bedienen kann, und plane den Kompetenzaufbau als Teil der Migration.

Auf einen Standard konsolidieren und Abweichungen begründen

Ein definierter Hausstandard plus eine dokumentierte Ausnahmeliste ist fast immer billiger als drei gleichberechtigte Plattformen. Automatisierung mit Ansible, Monitoring und Patchmanagement bauen sich dann einmal statt dreimal.

Tutorial

In fünf Schritten zu einer Entscheidung, die du begründen kannst

Hier geht es nicht mehr um Sympathien, sondern um überprüfbare Kriterien. Du nimmst zuerst den Bestand und die Anforderungen auf, schlägst dann Supportfristen und Paketstände der Kandidaten nach, statt sie zu schätzen, und baust einen Testserver aus einer unbeaufsichtigten Installation. Am Ende steht eine Baseline, von der jede Abweichung begründet werden muss.

01

Bestand und Anforderungen aufnehmen

Ohne zwei belastbare Listen ist jeder Vergleich Bauchgefühl. Liste eins beschreibt, was heute läuft. Liste zwei beschreibt, was die Anwendung fordert.

Fang bei den Systemen an, die du schon hast. Interessant sind dabei nicht Name und Version, die kennst du. Interessant sind die Fremdquellen: Jedes Paket, das nicht aus den Basis-Repositories stammt, ist beim nächsten Versionssprung ein potenzieller Blocker, und genau diese Pakete tauchen in keiner Entscheidungsvorlage auf.

Inventar je Host
# Grunddaten
cat /etc/os-release        # ID, VERSION_ID, PRETTY_NAME
hostnamectl                # Kernel, Architektur, Virtualisierung

# RHEL/Rocky/Alma: aus welchem Repo stammt jedes installierte Paket?
dnf repoquery --installed --qf '%{from_repo}' | sort | uniq -c | sort -rn
dnf repolist --enabled

# Debian/Ubuntu: welche Quellen sind überhaupt konfiguriert?
grep -rhE '^(deb |Types:)' /etc/apt/sources.list /etc/apt/sources.list.d/
apt-cache policy | head -40

Die Ausgabe von dnf repoquery --installed ist der wichtigste Teil: Alles, was nicht aus baseos, appstream oder anaconda kommt, gehört auf die Risikoliste. Auf Debian und Ubuntu liefert apt-cache policy dieselbe Information über die Prioritäten der Quellen.

Den gesamten Bestand in einem Rutsch erfassen
# Verteilung über alle Hosts
ansible all -m setup -a 'filter=ansible_distribution*'

# Kompakt als CSV für die Entscheidungsvorlage
ansible all -m shell --one-line \
  -a '. /etc/os-release; echo "$(hostname -s);$ID;$VERSION_ID;$(uname -r)"'

Wenn es kein Ansible gibt, tut es auch eine Schleife über ssh. Wichtig ist nur, dass die Liste vollständig ist. Erfahrungsgemäß tauchen dabei zwei bis drei Systeme auf, die niemand mehr auf dem Schirm hatte, und genau die sind später das Problem.

Was in die Anforderungsliste gehört

  • Freigabeerklärung des Anwendungsherstellers, nicht nur die mündliche Aussage läuft auch
  • Geforderte Laufzeitumgebung mit Mindest- und Höchstversion, also Java, PHP, Python, PostgreSQL oder .NET
  • Treiber und Kernelmodule für Storage-Controller, HBA, Netzwerkkarten und GPU
  • Hardware-Support-Matrix des Serverherstellers für genau dieses Modell, nicht für die Baureihe
  • Agenten, die mitkommen müssen: Backup, Virenschutz, EDR, Monitoring, Patchmanagement
  • Vorgaben aus Audits, etwa Bausteine des BSI IT-Grundschutz oder Nachweispflichten nach NIS2
02

Supportfristen nachschlagen statt schätzen

Die Supportdauer ist das Kriterium mit der längsten Wirkung, und zugleich das, bei dem am meisten aus dem Gedächtnis behauptet wird. Frag die Daten ab.

Support-Enddaten maschinenlesbar abfragen
for p in rhel rocky-linux almalinux debian ubuntu sles; do
  echo "== $p"
  curl -s "https://endoflife.date/api/$p.json" \
    | jq -r '.[:4][] | "\(.cycle)\tEOL: \(.eol)\tErweitert: \(.extendedSupport // "-")"'
done

Die Ausgabe legst du in die Entscheidungsvorlage, samt Abrufdatum. Danach machst du die einzige Rechnung, auf die es ankommt: Enddatum minus geplante Lebensdauer der Anwendung. Bleibt weniger als ein Jahr Puffer, hast du den Migrationsaufwand bereits mitgekauft.

Was die Kandidaten technisch mitbringen

DistributionPaketeFirewallPflichtsystemVerlängerung über
RHELdnf, RPMfirewalld auf nftablesSELinux, standardmäßig enforcingSubscription mit Extended Update Support
Rocky, AlmaLinuxdnf, RPMfirewalld auf nftablesSELinux, standardmäßig enforcingkeinen Herstellervertrag, nur Dienstleister
SLES 15zypper, RPMfirewalldAppArmorSubscription mit LTSS
Debianapt, dpkgnftables, ohne aktive RegelnAppArmorDebian LTS, danach ELTS durch Dritte
Ubuntu LTSapt, dpkgufw, standardmäßig inaktivAppArmorUbuntu Pro
03

Paketstände der Kandidaten prüfen, ohne zu installieren

Die Frage lautet nie welche Distribution ist moderner, sondern welche Version genau dieses einen Pakets liegt bei. Das beantwortest du in fünf Minuten mit Containern.

Versionen gegenprüfen
podman run --rm almalinux:9 dnf -q info --available postgresql-server
podman run --rm almalinux:9 dnf -q module list nodejs    # Streams der RHEL-Familie

podman run --rm debian:12 bash -c 'apt-get -qq update && apt-cache policy postgresql'
podman run --rm ubuntu:24.04 bash -c 'apt-get -qq update && apt-cache policy nodejs'

# Gegen RHEL selbst prüfen, ohne Subscription
podman run --rm registry.access.redhat.com/ubi9/ubi dnf -q module list nodejs

Das UBI-Image sieht nur einen Ausschnitt der RHEL-Repositories, für Pakete außerhalb der UBI-Kanäle brauchst du ein registriertes System. Für die Frage, welcher Stream beiliegt, reicht es trotzdem. Die AlmaLinux- und Rocky-Images beantworten dieselbe Frage für die kostenfreien Klone.

04

Testserver aus einer unbeaufsichtigten Installation bauen

Wer einen Kandidaten per Installer durchklickt, testet den Installer. Interessant ist die automatisierte Installation, denn genau so werden die Server später ausgerollt.

/var/lib/libvirt/ks/rocky9.ks (Auszug)
text
lang de_DE.UTF-8
keyboard de
timezone Europe/Berlin --utc
network --bootproto=dhcp --device=link --activate
rootpw --lock
bootloader --location=mbr
clearpart --all --initlabel
autopart --type=lvm --nohome
selinux --enforcing
firewall --enabled --service=ssh
services --enabled=chronyd,sshd
reboot

%packages
@^minimal-environment
chrony
%end

Bei Debian heißt das Gegenstück Preseed, bei Ubuntu Server ist es die autoinstall-Sektion in der cloud-init-Datei user-data. Der Inhalt ist derselbe Gedanke: Partitionierung, Sprache, Paketauswahl und Dienste stehen in einer Datei, die in der Versionsverwaltung liegt.

Prüfen und damit installieren
ksvalidator /var/lib/libvirt/ks/rocky9.ks      # Paket pykickstart

sudo virt-install --name test-rocky9 --memory 4096 --vcpus 2 \
  --disk size=30 --osinfo rocky9 --graphics none \
  --location /var/lib/libvirt/images/Rocky-9-dvd.iso \
  --initrd-inject /var/lib/libvirt/ks/rocky9.ks \
  --extra-args 'inst.ks=file:/rocky9.ks console=ttyS0'

# Prüfschritt nach dem ersten Start
sudo virsh console test-rocky9
getenforce && firewall-cmd --list-all && systemctl is-enabled chronyd

ksvalidator fängt Syntaxfehler ab, bevor du zwanzig Minuten auf einen abgebrochenen Installationslauf wartest. Die drei Prüfbefehle am Ende sind die Kontrolle, ob die Vorgaben aus der Datei wirklich angekommen sind, denn ein ignorierter Abschnitt bricht die Installation nicht ab.

05

Baseline festschreiben und Abweichungen begründen

Damit die Entscheidung ein Jahrzehnt trägt

  • Eine Standarddistribution je Einsatzzweck festlegen und die Begründung schriftlich ablegenOhne festgehaltene Begründung wird die Entscheidung beim nächsten Personalwechsel neu aufgerollt, und du hast wieder drei Paketwelten im Haus, die alle gepatcht werden wollen.
  • Für jede Ausnahme den Auslöser und ein Enddatum notierenAusnahmen ohne Enddatum werden zum Dauerzustand. Der eine SLES-Host für die zertifizierte Fachanwendung ist eine begründete Ausnahme, der eine Debian-Host, weil jemand das lieber mochte, ist keine.
  • Fremdrepositories pinnen und für jedes eine benannte Zuständigkeit vergebenEin Hersteller-Repo, das ungefragt eine Hauptversion nachzieht, kippt dir die Anwendung im laufenden Betrieb. Mit dnf versionlock oder apt-mark hold passiert das nur, wenn jemand es entscheidet.
  • Support-Enddaten als Ticket mit Vorlaufzeit in den Bestand eintragenDer Wechsel muss rund ein Jahr vor dem Enddatum beginnen. Erinnert dich niemand daran, merkst du es am ersten CVE, für das kein Update mehr kommt, und dann bist du im Krisenmodus statt im Projekt.
  • Die unbeaufsichtigte Installation in der Versionsverwaltung halten und regelmäßig ausführenEin Kickstart, den ein halbes Jahr niemand ausgeführt hat, funktioniert im Ernstfall nicht mehr, weil sich Repo-URLs, Paketnamen oder das Installationsmedium geändert haben.
  • Das vorhandene Wissen im Team gegen die Wahl prüfen und Lücken benennenEine technisch saubere Entscheidung fällt im Betrieb durch, wenn niemand SELinux-Meldungen lesen, zypper bedienen oder ein AppStream-Modul umschalten kann. Die Lücke schließt du vor dem Rollout, nicht im ersten Störfall.
Gut zu wissen

Häufige Fragen zu Distributionsauswahl für Server

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Gibt es die beste Linux-Distribution für Server?
Nein, und jede Quelle, die eine nennt, blendet Kriterien aus. Sinnvoll ist die Frage nur mit Kontext: Für zertifizierte Unternehmensanwendungen führt der Weg meist zu RHEL oder SLES, für generische Serverdienste ohne Herstellervorgabe reichen Debian, Ubuntu LTS, Rocky Linux oder AlmaLinux vollständig aus.
Sind Rocky Linux und AlmaLinux für den Produktivbetrieb geeignet?
Ja, beide sind auf RHEL abgestimmt und lassen sich identisch administrieren, dieselben Kommandos, dieselben Pfade, dasselbe SELinux-Verhalten. Was fehlt, ist der Herstellersupport mit zugesicherter Reaktionszeit und die formale Zertifizierung durch Softwarehersteller. Wenn dein Team Störungen selbst löst und keine Zertifizierung braucht, ist das ein tragfähiger Weg.
Ubuntu LTS oder Debian für neue Server?
Debian ist konservativer, komplett community-getragen und gut für Systeme, die lange unverändert laufen sollen. Ubuntu LTS bringt aktuellere Pakete, einen festen Zwei-Jahres-Takt und mit Ubuntu Pro einen kaufbaren Support samt ESM bis zehn Jahre. Wer Herstellersupport einkaufen können muss, greift zu Ubuntu, wer maximale Neutralität will, zu Debian.
Ist CentOS Stream ein Ersatz für CentOS 7?
Nicht im gleichen Sinn. CentOS Stream läuft dem jeweiligen RHEL-Release voraus und ist damit eine rollende Vorabversion statt eines nachgebauten Klons. Für Entwicklung, Tests und frühe Kompatibilitätsprüfungen ist das nützlich, als stabile Basis für Produktionsserver wählst du besser RHEL, Rocky Linux oder AlmaLinux.
Wie viele Distributionen sollte ein Team parallel betreiben?
In der Regel eine als Standard und höchstens eine zweite für begründete Sonderfälle wie eine zertifizierte Appliance. Jede zusätzliche Plattform verdoppelt Patch-Tests, Hardening-Vorgaben, Automatisierungsrollen und Bereitschaftswissen, ohne dass ein technischer Vorteil dagegensteht.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Guter Einstieg, der alle wichtigen Vokabeln aus dem Themenbereich erklärt, um "Fachchinesisch" zu verstehen und gleichzeitig Lust auf mehr Linux macht.
Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“
Die Schulung war genau das richtige, um mein Verständnis zu erweitern. Vielen Dank an den Trainer!
Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Entscheidung getroffen, jetzt das Wissen dazu

Wenn dein Ziel feststeht, holst du das passende Handwerkszeug bei uns: Der Linux Grundkurs (LPI01) und der Aufbaukurs (LPI02) machen dich distributionsunabhängig sicher, RH124 deckt die Red-Hat-Welt ab, SLE201v15 die SUSE-Seite und das Debian Administration Training den Debian-Zweig. Wer schnell breit aufgestellt sein will, nimmt den Kompaktkurs Linux Systemadministration und Shell-Scripting. Alle Kurse gibt es als Präsenztermin und Live-Online, auf Wunsch auch inhouse mit deinem eigenen Standard. Sprich uns an, wenn du vorher über die Plattformwahl reden möchtest.