Skip to main content
Linux · Managed · DE-RZ

BEKOM MANAGEDLinux-Server HostingDedizierte Hardware, freie Distribution

Linux-Server als Managed-Hosting bei BEKOM: dedizierte Hardware, freie Distributionswahl, gepflegte Plattform, wählbare Verfügbarkeitsstufen und schriftliches Angebot.

Basis-Spezifikation ansehen
Dedizierte Hardware
Patch-Disziplin
Monitoring
Deutsches RZ
Einsatz-Szenarien

Wann Linux-Server-Hosting bei BEKOM passt

Linux ist die Plattform der Wahl für ERP-Backends, Datenbanken, Web-Anwendungen, Build-Server, Anwendungs-Container und ETL-Pipelines. Wer einen oder mehrere Linux-Server geschäftskritisch betreibt, aber Hardware-Beschaffung, 24/7-Bereitschaft und Patch-Disziplin nicht intern leisten will, braucht einen Linux-erfahrenen Betriebspartner. BEKOM betreibt Linux-Server als individualisiertes Managed-Hosting im deutschen Rechenzentrum – mit freier Distributionswahl, dedizierter Hardware und auditfähiger Betriebsdokumentation.

Typische Auslöser für Managed-Linux

Drei Konstellationen führen Organisationen erfahrungsgemäß zum Managed-Linux-Hosting bei einem spezialisierten Betreiber statt zum reinen Eigenbetrieb oder Root-Server-Tarif.

Häufige Ausgangslagen:

Ablösung Eigenbetrieb mit Hardware-Lebensende – Bestehende Linux-Server in Server-Räumen oder Rack-Schränken erreichen ihr Hardware-Lebensende; ein erneuter Refresh-Zyklus mit Investitions-, Wartungs- und Personalkosten soll vermieden werden.

Ablösung Root-Server bei Massen-Anbieter – Linux-Server laufen heute bei Hetzner, IONOS, OVH oder Contabo auf Root-Server-Tarifen, doch Patch-Disziplin, Backup-Dokumentation und Notfall-Reaktion fehlen oder müssten kundenseitig nachgezogen werden.

Anwendungs-Plattform mit Architektur-Bedarf – ERP, CRM, Custom-Anwendungen, Containerplattformen oder Datenbank-Server brauchen eine stabile, gepflegte Linux-Basis; Beratung zur Hardware-Klasse, Distributionswahl und Cluster-Auslegung ist gefragt.

Welche Konstellation zutrifft, wird im Anforderungsgespräch geklärt – bevor Hardware-Klassen oder Distributionen festgelegt werden.

Wann sich Linux-Server-Hosting bei BEKOM rechnet

Wenn ERP-, CRM- oder Datenbank-Server eine stabile Linux-Basis verlangen und der bestehende Root-Server-Tarif keine Architektur-Beratung mitliefert, ist ein Betriebspartner mit Linux-Kompetenz gefragt – kein generischer Server-Tarif bei Hetzner, IONOS, OVH, Strato oder Contabo, der zwar eine Linux-Vorinstallation liefert, aber keine Pflege-Verantwortung übernimmt. BEKOM betreibt die Linux-Server als Managed Service im deutschen Rechenzentrum mit klar definierten Service-Bestandteilen.

Was BEKOM im Service-Vertrag liefert:

Distributionswahl nach Anwendungs-Anforderung – Ubuntu LTS, Debian, RHEL, SLES, Rocky Linux oder AlmaLinux je nach Anwendungs-Profil und Subscription-Strategie; keine Vorgabe einer einzigen Distribution.

Definierte Patch-Disziplin – Sicherheits-Updates innerhalb dokumentierter Fristen, größere Updates in geplanten Wartungsfenstern, kritische CVEs außerplanmäßig nach abgekürztem Verfahren.

Verfügbarkeitsstufe nach Workload-Kritikalität – Pro Server eigene Stufe; produktive ERP- oder Datenbank-Server auf Stufe 2 oder 3, Test- und Build-Systeme auf Stufe 1.

Architekturberatung statt Konfigurator – Hardware-Klasse, Speicher-Profil, Cluster-Auslegung und Anwendungs-Stack werden im Anforderungsgespräch festgelegt – nicht aus einem Online-Konfigurator entnommen.

BEKOM klärt mit dem Kundenteam Distribution, Hardware-Klasse und Verfügbarkeitsanspruch – das Ergebnis ist ein schriftliches Angebot mit dokumentiertem Leistungsumfang. → Managed Server

Kostenstruktur des Linux-Server-Hostings im Überblick

Ein Managed-Linux-Server-Hosting wirkt auf drei Kostenebenen, die im Assessment gegen die heutige Bestandssituation gerechnet werden – ohne pauschale Einsparversprechen.

Drei Kostenebenen im Vergleich:

Bestandsseite (heute Eigenbetrieb oder Root-Server-Tarif) – Hardware-Refresh, Subscription-Verträge bei kommerziellen Distributionen, USV/Klima, Wartung und Personalanteile für Patch-Disziplin sowie Bereitschaft.

Hosting-Seite (laufender Service) – Monatliche Service-Pauschale abhängig von Hardware-Klasse, Anzahl Server, Distribution-Wahl, Verfügbarkeitsstufe und Pflege-Tiefe.

Migrations-Einmalkosten – Inventarisierung der Quell-Systeme, Datentransfer, Image-Konvertierung bei VM-basierten Quellen und Cutover mit definiertem Rückfall-Pfad.

Differenzierung

Unterschied zu Root-Server-Tarifen

Im Linux-Hosting-Markt gibt es zwei Modell-Klassen: Massen-Anbieter mit Root-Server-Tarifen (definierte Hardware-Klasse, Self-Service-Provisionierung, Kunde administriert selbst, Anbieter haftet nur für Hardware) und individualisiertes Managed-Hosting bei einem spezialisierten Betreiber. BEKOM steht in der zweiten Klasse: jede Linux-Plattform wird im Anforderungsgespräch ausgelegt, dediziert betrieben und mit auditfähiger Dokumentation begleitet.

Beratung zur Anwendungs-Architektur

Vor dem Aufbau wird die Anwendungs-Architektur im Anforderungsgespräch zwischen Linux-Verantwortlichen aufseiten des Kunden und einem BEKOM-Architekten geklärt – nicht im Online-Konfigurator. Linux-Architektur ist selten generisch: Last-Profile, Speicher-Anforderungen und Cluster-Auslegung prägen die Hardware-Entscheidung.

Geklärt im Anforderungsgespräch:

Anwendungs-Inventar und Last-Profile – Welche Anwendungen laufen sollen, mit welchen Spitzenlasten, mit welcher Concurrent-User-Zahl und welchen Datenbank-Anforderungen.

Performance-Anforderungen – CPU-, RAM-, IOPS- und Netzwerk-Bedarf pro Server; Differenzierung zwischen Compute-, Memory- und I/O-intensiven Workloads.

Compliance-Vorgaben – ISO 27001, TISAX, BSI-Grundschutz, KRITIS oder branchenspezifisch (KHZG, regulierte Branchen) mit dokumentierter Härtungs-Linie.

Aufteilung der Betriebs-Verantwortung – Fully Managed durch BEKOM, Co-Managed mit RACI-Schnitt für interne Linux-Admins oder beratungsbegleiteter Eigenbetrieb mit primärem Zugriff beim Kunden.

Das Anforderungsgespräch ist unverbindlich und löst keine Folgeverpflichtung aus.

Distributionsfreiheit mit Pflege-Verantwortung

Anders als manche Tarife gibt es bei BEKOM keine Vorgabe einer bestimmten Distribution. Die Wahl folgt der Anwendungs-Anforderung und dem Subscription-Modell. BEKOM übernimmt die Pflege auf der gewählten Distribution mit dokumentiertem Patch-Zyklus und Major-Version-Begleitung.

Häufig genutzte Distributionen:

Ubuntu LTS – Long-Term-Support-Branch (5 Jahre Standard, 10 Jahre mit Pro-Subscription); breit unterstützt für Web-Anwendungen, Container-Hosts und ETL-Workloads.

Debian Stable – Konservativer Release-Zyklus, sehr stabile Paket-Basis; geeignet für langfristig stabile Anwendungs-Server ohne häufige Major-Sprünge.

RHEL und SLES (Subscription) – Enterprise-Distributionen mit kommerzieller Subscription; etabliert für SAP-Workloads, Oracle-Datenbanken und Anwendungen mit Hersteller-Zertifizierung.

Rocky Linux und AlmaLinux – RHEL-Derivate ohne Subscription-Pflicht; geeignet, wenn RHEL-Kompatibilität ohne kommerzielle Subscription gewünscht ist.

Welche Distribution für welchen Anwendungsfall passt, wird im Anforderungsgespräch geklärt – inklusive Subscription-Strategie (Bring Your Own oder über BEKOM beziehen).

Aktive Patch-Disziplin

In Root-Server-Tarifen liegt das Patchen typischerweise beim Kunden – mit dem Risiko vergessener Sicherheits-Aktualisierungen. BEKOM betreibt einen dokumentierten Patch-Prozess mit nachvollziehbarer Audit-Spur.

Bestandteile des Patch-Prozesses:

Sicherheits-Updates innerhalb definierter Fristen – Reguläre Sicherheits-Patches im wöchentlichen oder monatlichen Zyklus; Frist abhängig von CVE-Schweregrad und Anwendungs-Kritikalität.

Größere Updates in geplanten Wartungsfenstern – Kernel-Updates, Service-Restart-relevante Pakete und Distributions-Upgrades nach abgestimmtem Zeitplan.

Kritische CVEs außerplanmäßig – Abgekürztes Verfahren mit unmittelbarer Information an den Kunden, Risiko-Bewertung und Roll-out im Notfallfenster.

Vorher-/Nachher-Zustand im Reporting – Konfigurations-Snapshots vor jedem Eingriff, Patch-Historie mit Wartungsfenster-Bezug und Audit-Spur über die Vertragslaufzeit.

Damit wird der Patch-Stand jederzeit gegenüber Sicherheitsverantwortlichen oder Auditoren belegbar – nicht erst kurz vor der nächsten Prüfung rekonstruiert.

Auditfähige Dokumentation

Eine Linux-Server-Plattform lässt sich mit auditfähiger Betriebsdokumentation begleiten – je nach Compliance-Profil und Vereinbarung. Welche Artefakte vorgehalten werden und mit welcher Aufbewahrungsfrist, wird im Service-Vertrag vereinbart.

Mögliche Audit-Artefakte:

Konfigurations-Stände und Change-Log – Vollständige Versions-Spur über die Vertragslaufzeit; nachvollziehbar bis zum initialen Setup-Tag pro Server.

Patch-Historie pro Server – Welche Pakete wann aktualisiert wurden, mit Vorher-/Nachher-Zustand, Wartungsfenster-Bezug und Genehmigungspfad.

Backup-Reports und Restore-Nachweise – Backup-Status mit Aufbewahrungsfristen; protokollierte Restore-Tests in vereinbartem Turnus als Audit-Nachweis.

Zugriffsprotokolle – Administrative SSH-Zugriffe mit Nutzer-Identität und Zeitstempel; auf Wunsch ergänzt um auditd-Logs für tiefere forensische Auswertung.

Für ISO 27001-, TISAX- oder BSI-Grundschutz-Audits ist diese Dokumentations-Tiefe ein häufig dokumentierbar geforderter Bestandteil.

Leistungsumfang

Basis-Spezifikation als Ausgangspunkt

Die folgende Beschreibung dient als Showcase einer typischen Basis-Konfiguration für Linux-Server-Hosting bei BEKOM: vier Bausteine, die im Angebot durchgängig adressiert werden – Hardware und Plattform, Distribution und Stack, inkludierte Services und individualisierte Bereiche. Sie ist Ausgangspunkt für das Anforderungsgespräch, nicht fertiges Produktpaket – konkrete Preise stehen ausschließlich im individuellen Angebot. Distribution, Anwendungs-Stack, Performance-Profil, Backup-Strategie und Verantwortungsteilung werden gemeinsam mit dem Kundenteam festgelegt.

Hardware und Plattform

Die Plattform-Ebene umfasst Compute, Speicher und Netzwerk-Anbindung. Diese Bausteine werden bei jedem Setup an Anwendungs-Profil und Verfügbarkeitsanspruch angepasst – generische Mittelwert-Auslegungen werden vermieden.

Typische Bausteine im Angebot:

Dedizierte Hardware oder dedizierter VM-Pool – Im BEKOM-Rechenzentrum, ohne Multi-Tenancy auf gemeinsam genutzten Compute-Ressourcen.

CPU-Klasse nach Workload-Profil – Compute-, Memory- oder I/O-intensiv mit eigener Dimensionierung pro Anwendungsklasse.

Lokale Speicherung mit redundanter Konfiguration – RAID oder ZFS je nach Plattform; Storage-Profile nach Performance- und Aufbewahrungs-Anforderung getrennt.

Separates Backup-Netz – Datenstrom-Trennung zwischen Produktiv- und Backup-Verkehr; Backup-Spitzen beeinflussen die Anwendungs-Latenz nicht.

Redundante Netzwerk-Anbindung – Mehrere Switch-Pfade und USV-Absicherung im Rechenzentrum als Grundlage jeder Verfügbarkeitsstufe.

Out-of-Band-Management – Über separates Management-Netz mit MFA-Bastion; öffentliche SSH-Endpoints sind nicht vorgesehen.

Distribution und Stack

Über der Hardware-Ebene liegt die Distribution mit Härtung, Konfigurations-Versionierung und Anwendungs-Stack. Diese Schicht macht die Linux-Server administrierbar und in die bestehende IT-Landschaft integrierbar.

Typische Stack-Bausteine:

Distribution nach Wahl – Ubuntu LTS, Debian, RHEL, SLES, Rocky Linux oder AlmaLinux; Subscription über BEKOM oder Bring Your Own.

Standard-Härtung nach CIS Benchmark oder BSI – Restriktive Firewall-Regeln, SSH-Zugang nur über Schlüssel mit MFA-Bastion, file-permission-Härtung als Standard.

Konfigurations-Versionierung – Zustand der Server in Versionskontrolle (z. B. Ansible-Playbooks); Audit-Spur und Wiederherstellbarkeit nach Hardware-Tausch.

Anwendungs-Stack nach Bedarf – Datenbank-Server (PostgreSQL, MariaDB), Web-Server (nginx, Apache), Container-Plattform (Docker, Podman) oder ERP-Backend.

Inkludierte Services

Im Unterschied zu reinen Root-Server-Tarifen sind operative Services bereits enthalten – als Bestandteil des Service-Vertrags. Damit liegt der laufende Plattform-Betrieb bei BEKOM, nicht in einer Grauzone zwischen Hardware-Anbieter und interner IT.

Typisch im Service-Vertrag enthalten:

Plattform-Monitoring auf allen Ebenen – Hardware (Disk, Memory, CPU, Netzwerk), OS (Last, Patches, Logs) und Anwendung (Service-Status, Antwortzeiten); Alarmierung an das BEKOM-Betriebsteam.

Patch-Management mit Change-Prozess – Sicherheits-Updates, größere Updates und CVE-Notfälle nach dokumentiertem Verfahren mit Eskalations-Pfaden.

Backup-Strategie mit Restore-Tests – Tägliches inkrementelles Backup, wöchentliches Vollbackup, monatlicher Archiv-Stand mit definierten Aufbewahrungsfristen und protokollierten Restore-Tests.

Incident-Response mit Eskalationskette – Definierte Rollen (1st-/2nd-/3rd-Level), Reaktionspfade und Kommunikationswege; quartalsweise Service-Reviews mit Wachstums-Planung.

Was BEKOM mit Ihnen individualisiert

Über die typischen Bausteine hinaus gibt es Bereiche, die erst aus konkreten Anforderungen heraus festgelegt werden. Diese vier Felder sind im Anforderungsgespräch der eigentliche Hebel: Sie entscheiden über Wirtschaftlichkeit, Auditfähigkeit, Anwendungs-Tiefe und Verantwortungsschnitt.

Individuell pro Setup ausgelegt:

Distribution und Versionsstand – Welche LTS-Version, welcher Support-Zeitraum, welches Subscription-Modell, welche Major-Version-Strategie.

Anwendungs-Architektur – Single-Server, HA-Cluster mit Pacemaker/Corosync, anwendungs-eigene Cluster-Mechanismen oder Container-Plattform.

Compliance-Profil – DSGVO, ISO 27001, TISAX, KRITIS, KHZG oder branchenspezifisch; mit zugeschnittenen Härtungs-Vorgaben und Reporting-Tiefe.

Verantwortungsteilung – Vollständig BEKOM (Fully Managed), Co-Managed mit eigener IT (RACI-Schnitt pro Funktionsbereich) oder beratungsbegleiteter Eigenbetrieb.

Verfügbarkeitsstufen

Verfügbarkeit und Wiederanlauf

Linux-Server tragen häufig Anwendungen, deren Ausfall direkt geschäftliche Folgen hat – ERP-Backends, Datenbanken, Build-Pipelines oder Web-Anwendungen. Die drei Verfügbarkeitsstufen orientieren sich an der Geschäftskritikalität und am tolerierbaren Wiederanlauf-Zeitfenster. Konkrete Verfügbarkeits-Werte werden ausschließlich im individuellen Service-Vertrag dokumentiert und für jede Konstellation einzeln vereinbart.

Stufe 1: Einfache Verfügbarkeit

Ein Linux-Server mit Tagesbackup, dokumentiertem Wiederanlauf-Verfahren bei Hardware-Defekt und definierter Reaktionskette für den Vorfallsfall. Geeignet, wenn ein toleranzfähiges Ausfallzeitfenster akzeptabel ist.

Architektur – Single-Server mit Tagesbackup auf separat verwaltetes Speicherziel; konsistente Sicherung von OS, Konfiguration und Datenbeständen.

Typische Workloads – Test- und Entwicklungsumgebungen, Build-Server, sekundäre Anwendungen ohne direkte Auswirkung auf Geschäftsabläufe oder Kunden-Erreichbarkeit.

Ausfallverhalten – Bei Hardware-Defekt erfolgt Wiederanlauf nach dokumentiertem Verfahren mit definierter Reaktionskette und protokolliertem Restore-Pfad.

Wartung – Updates und Patches im vereinbarten Wartungsfenster mit kurzem geplantem Ausfallfenster für Kernel-Updates.

Stufe 2: Erweiterte Verfügbarkeit

Hochverfügbarkeits-Cluster aus mehreren Linux-Knoten mit gemeinsamem Storage und automatischer Service-Übernahme. Geeignet für produktive Anwendungen mit höheren Verfügbarkeitsansprüchen und täglicher Geschäftskritikalität.

Architektur – Mehr-Knoten-Cluster mit gemeinsamem Storage; Cluster-Mechanik über Pacemaker/Corosync oder anwendungs-eigene Cluster-Mechanismen (etwa für Datenbank-Server mit Streaming-Replikation).

Wartung – Knoten-Updates erfolgen rolling über die Cluster-Mitglieder, ohne Service-Unterbrechung; Patches werden je Knoten validiert.

Ausfallverhalten – Automatische Service-Übernahme bei Knoten- oder Pfad-Ausfall, ohne manuellen Eingriff; aktive Verbindungen werden auf gesunde Knoten umgeleitet.

Typische Workloads – Produktive ERP-Backends, Datenbank-Cluster, Anwendungs-Server mit täglicher Geschäftskritikalität und Web-Anwendungen mit moderatem Verkehr.

Stufe 3: Multi-Site-Redundanz

Linux-Plattform über zwei räumlich getrennte BEKOM-Standorte. Geeignet für geschäftskritische Anwendungen mit BCM-Anforderung, KRITIS-Klassifizierung oder Versicherungs-Anforderungen mit dokumentiertem Standort-Failover.

Architektur – Daten-Replikation zwischen Standorten mit konsistenter Anwendungs-Stage; getrennte Strom-, Klima- und Netzdomänen je Standort.

Failover – Definierte Failover-Strategie mit dokumentiertem Runbook, regelmäßige Übungs-Failover in vereinbartem Turnus und protokollierte Wiederanlauf-Übungen.

Schutzziel – Toleranz gegen Standort-Komplettausfall (Strom, Brand, Netz, regionale Störung) sowie gegen geplante Großwartungen am primären Standort.

Typische Workloads – KRITIS-relevante Anwendungs-Plattformen, Konzern-Kernsysteme mit BCM-Auflagen und produktive Datenbanken mit Erreichbarkeits-Zusagen rund um die Uhr.

BEKOM-Ansatz

BEKOM-Ansatz und Kostenstruktur

Über die Verfügbarkeitsstufen hinaus entscheidet das Betriebsmodell, wie eine Linux-Plattform langfristig wirkt. Der BEKOM-Ansatz setzt auf einen festen Ansprechpartner mit Linux-Expertise, ein Hosting in zertifizierten deutschen Rechenzentren mit deutschsprachiger Betreuung und eine Kostenstruktur, die variable Eigenbetriebs-Aufwände in eine planbare Monatspauschale überführt.

Fester Ansprechpartner mit Linux-Expertise

Jede Linux-Installation wird einem festen Ansprechpartner mit Linux-Administrations-Erfahrung zugeordnet, der Distributions-Fragen, Kernel- und Service-Themen sowie Vorfälle an systemd-Units direkt bearbeitet. Reaktionspfade und Eskalationsstufen sind je Linux-Installation im Service-Vertrag dokumentiert — statt anonymer Ticket-Queues oder rotierender Bereitschaft.

Aufgaben des festen Ansprechpartners:

Pflege von Distribution und Kernel-Linie (Ubuntu LTS, Debian, RHEL, SLES, Rocky Linux, AlmaLinux)

Patch-Disziplin entlang der Distribution-Release-Linie mit dokumentiertem Test-Stage

Härtung und Pflege von systemd-Units, SSH-Konfiguration und Firewall-Regeln

Konfiguration von Monitoring-Sonden, Log-Forwarding und Cron- bzw. systemd-Timern

Reaktionspfade und Eskalation:

  • Service-Levels und Reaktionspfade je Linux-Installation im Vertrag fixiert
  • Definierte Eskalation an 2nd- und 3rd-Level-Linux-Spezialisten im Störungsfall
  • Quartalsweise Service-Reviews mit Patch-Stand, Kapazitäts- und Subscription-Hinweisen
  • Reporting in Abstimmung mit Geschäftsleitung und Compliance-Stellen

Hosting und Betrieb im DACH-Raum

BEKOM nutzt für Linux-Server-Installationen zertifizierte Rechenzentren in Deutschland. Konfigurations- und Wartungs-Tätigkeiten erfolgen durch deutschsprachige Linux-Administratoren; die Konfiguration bleibt nahe am Distributions-Standard, sodass ein Wechsel zu einem anderen Linux-Hoster jederzeit möglich bleibt.

Betriebsumgebung:

Hosting in zertifizierten deutschen Rechenzentren (BEKOM als Nutzer)

Deutschsprachige Linux-Administratoren für Pflege und Incident-Response

Patch-Management entlang der offiziellen Distribution-Release-Linie

Monitoring von systemd-Services, journalctl-Auswertung und Anwendungs-Endpunkten

Portabilität und Exit:

  • Standard-Distribution ohne proprietäre BEKOM-Anpassungen an Kernel oder Init-System
  • root-Zugriff bzw. Snapshot- und Image-Export auf Anfrage übergebbar
  • Wechsel zu einem anderen Linux-Hoster jederzeit technisch möglich
  • Übergabe-Dokumentation (Paketstand, Konfigurationen, Cron- und systemd-Timer) als Bestandteil des Service-Vertrags

Planbare Kostenstruktur statt variabler Aufwände

Im Eigenbetrieb fallen Kostentreiber an, die in der internen Kalkulation oft unterschätzt werden — von der laufenden Patch-Disziplin bis zur Subscription-Pflege bei kommerziellen Distributionen. BEKOM überführt diese Aufwände in eine monatliche Pauschale je Linux-Installation; ein vorgelagertes Assessment klärt den konkreten Betriebsumfang und die zugehörige Kostenstruktur.

Typische Kostentreiber im Eigenbetrieb:

Kontinuierliche Sicherheits-Patches je Distribution mit Test- und Produktiv-Stage

Kernel- und Major-Version-Upgrades mit dokumentiertem Upgrade-Pfad je Distribution

Subscription-Pflege bei kommerziellen Distributionen wie RHEL oder SLES (Entitlements, Channels)

Performance-Tuning unter Last (Filesystem-Wahl, I/O-Scheduler, Kernel-Parameter)

Inhalte der Monatspauschale je Linux-Installation:

  • Kernel- und Distribution-Patches sowie Paket-Pflege im definierten Zyklus
  • Monitoring von systemd-Services, Logs und Anwendungs-Endpunkten
  • Incident-Response über die im Vertrag fixierten Reaktionspfade
  • Quartalsweise Service-Reviews und Reporting für Geschäftsleitung und Compliance

Häufige Fragen zum Linux-Server-Hosting

Worin unterscheidet sich BEKOM-Linux-Hosting von Root-Server-Tarifen oder Massen-Hostern?

Root-Server-Tarife liefern Hardware mit Linux-Vorinstallation und überlassen Administration, Pflege, Backup und Sicherheit dem Kunden. BEKOM betreibt die Linux-Plattform aktiv: Patch-Management, Backup, Monitoring, Incident-Response und Architektur-Beratung sind durchgehend Service-Bestandteile. Beide Modelle haben ihre Berechtigung — BEKOM ist die richtige Wahl, wenn Pflege-Verantwortung ausgelagert werden soll und Compliance-Nachweise gegenüber Auditoren gefragt sind.

Welche Distributionen werden unterstützt, und wer wählt sie aus?

Ubuntu LTS, Debian, RHEL, SLES sowie die freien Enterprise-Derivate Rocky Linux und AlmaLinux gehören zum Standard-Angebot. Für andere Distributionen (etwa OpenSUSE Leap, Fedora Server) wird im Einzelfall geprüft, ob sie zum Anwendungs- und Pflege-Profil passen. Die Distributionswahl folgt der Anwendungs-Anforderung — BEKOM gibt keine Distribution vor, sondern berät zur passenden Wahl inklusive Subscription-Modell.

Wer hat root-Zugriff auf die gehosteten Linux-Server — BEKOM oder das interne Team?

Das wird im Vertrag geregelt und ist Teil der Verantwortungsteilung. Drei Modelle stehen zur Wahl: vollständiger BEKOM-Betrieb mit Reporting an den Kunden (Fully Managed); geteilter Zugriff mit dokumentierten Rollen für BEKOM und internes Team (Co-Managed); reine BEKOM-Begleitung mit primärem Zugriff beim Kunden (begleiteter Eigenbetrieb). Die Rollen-Matrix wird vor Vertragsschluss schriftlich fixiert mit klar definierten Zugriffsketten.

Wie funktioniert das Patch-Management konkret, und wer entscheidet über Updates?

Sicherheits-Updates werden innerhalb definierter Fristen eingespielt — kritische CVEs außerplanmäßig nach abgekürztem Verfahren, reguläre Sicherheits-Patches im wöchentlichen oder monatlichen Zyklus, größere Updates in geplanten Wartungsfenstern. Für jede produktive Anwendung gibt es Test-Stages, in denen Updates vor dem produktiven Rollout validiert werden. Der Prozess ist dokumentiert, in Audit-Reports nachvollziehbar und mit der Change-Management-Disziplin des Kunden abgestimmt.

Können wir bestehende Linux-Server zu BEKOM migrieren, und wie läuft die Übernahme?

Ja. Migration umfasst Inventarisierung der Quell-Systeme (Distribution, Pakete, Konfigurationen, Datenmenge), Aufbau der Ziel-Systeme im BEKOM-Rechenzentrum, Datentransfer (rsync, Backup-Restore oder Storage-Replikation je nach Volumen), Cutover und Nachbereitung mit Validierungs-Tests. Bei VM-basierten Quellen (VMware, Proxmox, Hyper-V) sind zusätzlich Image-Konvertierungen Bestandteil. Der Migrationsplan wird mit Stufen-Logik, definierten Cutover-Fenstern und Rollback-Optionen im Angebot dokumentiert.

Wie wird die Sicherheit der Linux-Server gewährleistet, und welche Härtung erfolgt?

Standard-Maßnahmen: Härtung nach Industrie-Vorgaben (CIS Benchmark, BSI-Empfehlungen), restriktive Firewall-Regeln, SSH-Zugang nur über Schlüssel mit MFA-Bastion, Zwei-Faktor-Authentifizierung für privilegierte Aktionen, Logging an SIEM, regelmäßige Schwachstellen-Scans und dokumentiertes Vulnerability-Management. Für besonders schutzbedürftige Systeme werden zusätzlich SELinux oder AppArmor, File-Integrity-Monitoring und Audit-Daemon aktiviert, um tiefere forensische Auswertung im Vorfallsfall sowie revisionsfeste Audit-Trails zu ermöglichen.

Wie wird die Performance der Linux-Server überwacht und skaliert?

Performance-Monitoring beobachtet kontinuierlich CPU, RAM, I/O, Netzwerk-Durchsatz und Anwendungs-Metriken je Server. Bei Annäherung an Schwellenwerte werden Kapazitätsanpassungen vorgeschlagen, bevor Engpässe für Anwendungen spürbar werden. Quartalsweise Service-Reviews adressieren Wachstum und planen Skalierungs-Schritte gemeinsam mit dem Kunden — auch für Mehr-Server-Landschaften mit Configuration-Management-Werkzeugen wie Ansible, Salt oder Puppet zur konsistenten Verwaltung über die gesamte Server-Gruppe hinweg.

Was kostet das Linux-Server-Hosting bei BEKOM, und wie wird kalkuliert?

Konkrete Preise stehen nicht auf der Webseite, weil Hardware-Klasse, Anzahl Server, Distribution-Pflegeaufwand, Anwendungs-Komplexität, Verfügbarkeitsstufe und Service-Modell stark variieren. Im Anforderungsgespräch entsteht eine Kosten-Struktur ohne Verbindlichkeit; das schriftliche Angebot enthält dann die transparente Aufschlüsselung pro Service-Bestandteil — getrennt nach Hardware-Anteil, Plattform-Pflege, Monitoring, Backup-Strategie und Subscription-Anteil bei kommerziellen Distributionen, sodass eine spätere interne Budgetbegründung möglich bleibt.

Welche Vertragslaufzeiten und Wechseloptionen gibt es, auch für Subscription-Distributionen?

Übliche Bandbreite reicht von 12 Monaten Mindestlaufzeit bis zu mehrjährigen Verträgen mit dedizierter Hardware. Eine Anpassung der Service-Stufe oder Hardware-Klasse während der Laufzeit ist im Vertrag geregelt. Bei RHEL- oder SLES-Subscriptions sind „Bring Your Own Subscription" oder Subscription über BEKOM möglich. Bei Vertragsende erfolgt eine strukturierte Daten-Übergabe in Standardformaten — es gibt keine technischen Lock-ins.

Wie sieht der Backup-Prozess konkret aus, und wie wird die Wiederherstellbarkeit nachgewiesen?

Backups erfolgen je Server nach klar definierter Strategie: tägliches inkrementelles Backup, wöchentliches Vollbackup, monatlicher Archiv-Stand mit definierten Aufbewahrungsfristen. Die Wiederherstellbarkeit wird in regelmäßigen Restore-Tests validiert und protokolliert. Bei besonders schutzbedürftigen Daten erfolgt zusätzlich eine geografisch getrennte Backup-Spiegelung. Aufbewahrungsfristen werden nach Compliance-Profil, Branchen-Anforderung und gesetzlichen Vorgaben gewählt und im Vertrag fixiert mit transparenter Lösch-Logik nach Ablauf.

Welche Kosten entstehen beim Wechsel von Root-Servern zu BEKOM Managed Linux?

Die Kosten richten sich nach Anzahl der Linux-Server, gewählter Distribution, RAM-Ausstattung und Speicherkonfiguration. Migration bestehender Linux-Systeme ist meist ohne Anwendungs-Downtime möglich. BEKOM analysiert die aktuelle Server-Landschaft und erstellt ein Angebot basierend auf dokumentierten Service-Levels statt versteckter Zusatzkosten bei Hyperscalern. Vertragslaufzeiten beginnen ab 12 Monaten für planbare Budgetierung ohne Hardware-Investitionen.

Kann man später wieder zum Eigenbetrieb zurückkehren?

Linux-Server bei BEKOM laufen auf Standard-Hardware ohne proprietäre Konfigurationen oder Vendor-Lock-in. Die komplette Server-Dokumentation, OS-Konfiguration und Anwendungs-Setup bleiben transparent und auditfähig verfügbar. Bei Bedarf erfolgt die Rückführung durch Image-Export oder Migrations-Unterstützung zum neuen Betreiber. BEKOM dokumentiert alle Systemkonfigurationen fortlaufend, sodass ein Betreiberwechsel oder Rückkehr zum Eigenbetrieb jederzeit technisch umsetzbar bleibt.

Nächster Schritt: Hosting-Angebot anfragen

Den Einstieg bildet ein unverbindliches Anforderungsgespräch zur geplanten Linux-Landschaft. Auf Basis der besprochenen Eckpunkte entsteht ein schriftliches Angebot mit individualisierter Spezifikation, dokumentierter Verfügbarkeitsstufe und transparent ausgewiesenem Service-Umfang inklusive Pflege- und Backup-Verantwortung.

Das Linux-Server-Assessment liefert eine detaillierte Bestandsaufnahme der aktuellen Server-Landschaft mit Distribution-Analyse, Hardware-Dimensionierung und Anwendungs-Dependencies. BEKOM erstellt eine konkrete Architektur-Empfehlung für die Managed-Linux-Migration inklusive Betriebsumfang, Patch-Zyklen und Backup-Konzept. Das Service-Design-Dokument definiert SLA-Parameter, Monitoring-Umfang und Eskalations-Wege für den künftigen 24/7-Betrieb der Linux-Server.

1

Linux-Bedarf gemeinsam strukturieren

Im Anforderungsgespräch klären BEKOM-Linux-Spezialisten mit Ihrem Team die wesentlichen Eckpunkte: geplante Anwendungen, Distribution-Präferenz, Performance-Profil, Compliance-Anforderungen, Backup-Erwartungen und gewünschte Aufgabenteilung. Das Gespräch ist unverbindlich und löst keine Folgeverpflichtung aus.

2

Spezifikation auf Ihre Anforderungen anpassen

Auf Basis des geführten Gesprächs entsteht eine angepasste Spezifikation mit Hardware-Dimensionierung, Distribution, Stack-Konfiguration, Verfügbarkeitsstufe und Migrations-Plan, falls eine Bestandsmigration vorgesehen ist.

3

Schriftliches Angebot mit dokumentiertem Leistungsumfang

Das Angebot dokumentiert vollständig den Leistungsumfang, alle Migrations-Schritte, SLA-Profil, Verfügbarkeitsstufe, Patch-Zyklen, Backup-Strategie, Vertragsbedingungen, Kündigungsregelungen und Kostenstruktur. Es bildet die transparente Grundlage für die Vertragsverhandlung – ohne versteckte Bestandteile oder nachgereichte Aufpreise nach Vertragsschluss.