BEKOM MANAGEDProxmox VirtualisierungAuditfähig aus deutschem Rechenzentrum
Proxmox VE als Managed-Hosting bei BEKOM: dedizierte Ressourcen, wählbare Verfügbarkeitsstufen, individualisierte Architektur und schriftliches Angebot nach Anforderungsgespräch.
Wann Proxmox-Hosting bei BEKOM passt
Der Unterschied zwischen Proxmox im Eigenbetrieb (oder bei einem Massen-Tarif) und dediziertem Managed-Hosting bei BEKOM zeigt sich entlang vier Dimensionen: Hardware, Betrieb, Compliance und Risiko. Drei typische Auslöser führen zur Bewertung – ein auslaufender VMware-Vertrag, ein anstehender Hardware-Refresh oder ein Massen-Hoster, der keine Beratungs-Tiefe liefert.
Eine Proxmox-basierte Managed Virtualisierung trägt geschäftskritische Workloads vom ERP-System bis zur Auftragsverarbeitung und erfordert daher eine Verfügbarkeit, die zur Betriebsvoraussetzung für operative Geschäftsprozesse wird. Regulatorische Anforderungen an Datenstandort und Audit-Fähigkeit der Virtualisierungs-Plattform betreffen dabei sowohl Compliance-relevante Anwendungen als auch die standortübergreifende Bereitstellung von IT-Services.
Status quo: Eigenbetrieb oder Massen-Tarif
- Hardware — Refresh-Zyklen alle 4–5 Jahre, USV/Klima/Switches binden Kapital, Skalierung gebunden an Beschaffungs-Lead-Time
- Betrieb — 24/7-Bereitschaft intern oder offen, Backup-Strategie als Personalaufgabe, Patch-Disziplin schwankt mit Auslastung
- Compliance — Audit-Doku selbst gepflegt, Change-Prozesse meist informell, Patch-Reporting auf Nachfrage
- Risiko — Ein-Personen-Wissen über Cluster-Konfiguration, Hersteller-Lizenzbindung (z. B. VMware-Bundles), beim Massen-Hoster keine Beratung und keine individuelle Architektur
BEKOM Managed-Hosting: Dediziert im deutschen Rechenzentrum
- Hardware — Aus dem RZ-Pool, ohne CapEx, skaliert nach Workload statt nach Beschaffungs-Lead-Time
- Betrieb — Definiertes Team mit Eskalations-Weg, Backup im Service-Level mit vereinbartem RPO/RTO, dokumentierter Patch-Prozess
- Compliance — Change- und Patch-Reports im Reporting-Zyklus, Betriebsdokumentation auf ISO 27001 / TISAX vorbereitet
- Risiko — Vertraglich abgesicherter Betrieb statt Personenwissen, Open-Source-Plattform ohne Lizenz-Bundle-Risiko, Architekturberatung als Teil des Anforderungsgesprächs
Im Anforderungsgespräch klären wir Cluster-Größe, Verfügbarkeitsstufe und Migrationsweg konkret entlang Ihrer Workloads – Sie erhalten ein schriftliches Angebot mit dokumentiertem Leistungs- und Preisrahmen.
Auf der Kostenseite verschieben sich dabei die Treiber: weg vom Hardware-Refresh-Zyklus, USV-/Klima-Aufwand und 24/7-Personalkosten, hin zu einer monatlichen Service-Pauschale plus einmaligem Migrationsaufwand für Assessment, Pilot und Cutover. Eine pauschale Einsparung versprechen wir nicht – eine belastbare Vergleichsgrundlage liefern wir.
BEKOM ist kein Massen-Hoster
BEKOM legt jeden Proxmox-Cluster individuell aus. Cluster-Größe, CPU-/RAM-Profil, Storage-Konzept und Netzwerk-Topologie werden im Anforderungsgespräch auf Ihre Workload-Mischung zugeschnitten — von der einzelnen Linux-VM für ein ERP-Backend bis zum HA-Cluster für eine geschäftskritische Branchen-Software.
Verfügbarkeitsstufe, Backup-Strategie und Service-Umfang werden auf Ihre Compliance-Anforderungen und Skalierungs-Erwartungen ausgelegt. Das Ergebnis nach dem Anforderungsgespräch ist ein schriftliches Angebot mit Cluster-Spezifikation und Preisrahmen — als Grundlage für Ihre interne Bewertung.
Was „dediziert" konkret heißt: Auf der Ressourcen-Achse bedeutet es, dass CPU-, RAM- und Storage-Kapazität pro Cluster reserviert wird, ohne Überzeichnung gegen andere Kunden. Auf der Hardware-Achse bedeutet es, dass die physische Plattform exklusiv genutzt wird statt mit anderen Kunden geteilt. Beide Achsen sind getrennt wählbar — ein Cluster mit reservierten Ressourcen kann auf eigener Hardware oder auf einer geteilten Plattform laufen, je nach Wirtschaftlichkeit und Compliance-Schnitt.
Beratung statt Konfigurator
Die Spezifikation entsteht im Anforderungsgespräch, nicht im Online-Konfigurator. Vor dem Angebot werden die tragenden Randbedingungen gemeinsam geklärt — bevor eine Architektur vorgeschlagen wird. Das Gespräch findet zwischen Ihren fachlichen Verantwortlichen und einem BEKOM-Architekten statt, nicht über ein Ticket-Formular.
Geklärt im Anforderungsgespräch:
Workload-Profil und Performance-Erwartung
Compliance-Vorgaben und auditpflichtige Prozesse
Backup-Strategie und Wiederanlauf-Anforderung
Skalierungs-Pfad über die Vertragslaufzeit
Auf Basis Ihrer Anforderungen schlagen wir die wirtschaftlich tragfähigste Auslegung vor — auch dann, wenn das ein kleinerer Cluster, ein Hybrid-Setup mit Bestandshardware oder eine schrittweise Migration statt einer Neuanlage in voller Größe bedeutet.
Individuelle Architektur statt Standardpaket
Self-Service-Plattformen bieten standardisierte VM-Pakete (z. B. „CX-21 / CX-31 / CX-41"). BEKOM entwickelt die Architektur entlang Ihrer Anforderung statt aus einem festen Katalog. Welche Knoten-, Storage- und Netzwerk-Topologie passt, hängt von Workload-Mischung, Compliance-Schnitt und Wachstumshorizont ab — und davon, wie redundant die Plattform über die Vertragslaufzeit getragen werden soll.
Architektur-Entscheidungen pro Cluster:
Dedizierte Knoten oder dedizierter VM-Pool
Lokale oder verteilte Speicherung
Separates Backup-Netz oder gemeinsame Fabric
Eigene Hardware oder gemeinsam genutzte Plattform mit reservierten Ressourcen
Die Basis-Spezifikation weiter unten ist Ausgangspunkt – kein fertiges Produkt. Jede dieser Entscheidungen wird im Architektur-Vorschlag begründet, sodass nachvollziehbar wird, warum für Ihren Fall ein dedizierter Knoten gegenüber einem geteilten Pool — oder umgekehrt — der wirtschaftlich tragfähigere Weg ist.
Compliance-fähige Dokumentation
Im Unterschied zu reinen IaaS-Tarifen liefert BEKOM eine auditfähige Betriebsdokumentation als festen Service-Bestandteil — nicht als nachgereichten Auszug aus einem Self-Service-Portal. Die Dokumentation entsteht laufend aus dem Betrieb heraus und ist für interne wie externe Auditoren ohne längeren Vorlauf einsehbar.
Bestandteile der Betriebsdokumentation:
Change-Prozess für Konfigurationen mit Genehmigungspfad
Patch-Historie mit Vorher-/Nachher-Zustand
Backup-Reports und Restore-Testnachweise
Incident-Logs und Eskalationsverläufe
Für Organisationen mit ISO 27001-, TISAX-, BSI-Grundschutz- oder KRITIS-Anforderungen ist das Pflichtbestandteil. Auf Wunsch ergänzt BEKOM ein abgestimmtes Reporting für Informationssicherheits-Beauftragte oder die Geschäftsführung — in einem Format und Turnus, der zum bestehenden Informationssicherheits-Managementsystem passt.
Deutscher Vertragsraum, deutscher Support
Vertrag, Service-Beschreibung, SLA und Support sind durchgängig in Deutsch. Datenverarbeitung erfolgt in Deutschland, Support-Eskalationen erreichen verantwortliche Rollen ohne Zeitzonenverzug. Der Gerichtsstand liegt im deutschen Rechtsraum, der Vertrag unterliegt deutschem Recht.
Deutscher Vertragsraum bedeutet konkret:
Vertragstexte und SLAs in Deutsch, kein Übersetzungsabgleich nötig
Datenverarbeitung in deutschen BEKOM-Rechenzentren
Support-Eskalation an deutschsprachige Fachrollen
Im Standard keine Weiterreichung an internationale Service-Tiers
Bei Audit oder Vertragsstreit gibt es keine Sprachbarriere zwischen Vertragsdokument und Verantwortungsträger — und keinen Umweg über internationale Kanzleien oder Übersetzungsbüros. Für Familienunternehmen, KRITIS-relevante Betriebe und Organisationen mit Compliance-Aufsicht in Deutschland ist das in der Vergabe ein eigenständiges Kriterium. → Managed Infrastructure-Betrieb bei BEKOM im Überblick
Basis-Spezifikation als Ausgangspunkt
Die folgende Beschreibung zeigt, wie eine typische Proxmox-Hosting-Spezifikation bei BEKOM strukturiert ist: vier Ebenen, die im Angebot durchgängig adressiert werden — Compute und Speicher, Plattform und Lifecycle, inkludierte Services und individuell auszulegende Bereiche. Sie dient als Ausgangspunkt für das Anforderungsgespräch, nicht als fertiges Produktpaket.
Compute und Speicher
Die Compute- und Speicherebene legt fest, wie Workloads aufgeteilt, Performance abgesichert und Backup-Pfade vom produktiven Datenstrom getrennt werden. Diese Trennung ist Voraussetzung dafür, dass eine Wiederherstellung auch dann gelingt, wenn die produktive Speicherebene betroffen ist.
Typische Bausteine im Angebot:
Dedizierte Compute-Ressourcen – CPU- und RAM-Kapazität wird üblicherweise pro Cluster reserviert, statt im Pool mit anderen Kunden zu konkurrieren. Das stützt reproduzierbare Performance und ein sauberes Sizing über die Vertragslaufzeit.
Redundante lokale Speicherung – Produktivdaten liegen im Standard-Profil im redundanten Storage-Verbund; der Backup-Pfad führt physisch und logisch getrennt zu einem unabhängigen Backup-Ziel. Damit wirken Plattenausfall und Backup-Anlauf nicht auf denselben Datenträger.
Separate Netzwerke – Management-, VM-Traffic- und Backup-Verkehr laufen typischerweise über getrennte VLANs oder Fabrics. Wartung am Management-Netz oder hoher Backup-Durchsatz beeinträchtigt den produktiven VM-Betrieb damit nicht.
Skalierbar – Die Auslegung trägt vom Single-Knoten für Test- und Backoffice-Workloads bis zum mehrstufigen Cluster für produktive Anwendungen. Erweiterungen erfolgen innerhalb der bestehenden Architektur, ohne Plattform-Wechsel.
Welche Speicher-Topologie konkret eingesetzt wird — lokal, repliziert oder über Ceph verteilt — hängt vom Verfügbarkeitsanspruch und vom Wachstumspfad ab und wird im Anforderungsgespräch festgelegt.
Plattform und Lifecycle
Die Plattform-Ebene regelt, wie Updates, Major-Versionen und Konfigurationsänderungen über die Vertragslaufzeit behandelt werden. Daraus entsteht eine berechenbare Wartungslinie, die getrennt vom laufenden VM-Betrieb gepflegt wird und Änderungen an der Plattform vom Anwendungsbetrieb entkoppelt.
Typische Bausteine im Angebot:
Proxmox VE Enterprise-Subscription – BEKOM bezieht Updates aus dem Enterprise-Repository der Proxmox Server Solutions GmbH. Korrekturen und Sicherheitspatches durchlaufen damit eine zusätzliche Stabilitätsstufe, bevor sie auf produktive Cluster gelangen.
Patch-Management – Patches werden in einem dokumentierten Change-Prozess geplant, in vereinbarten Wartungsfenstern eingespielt und mit Vorher-/Nachher-Zustand protokolliert. Patch-Vorgänge bleiben damit im Reporting nachvollziehbar.
Major-Version-Begleitung – Major-Upgrades von Proxmox VE sind im Standard Bestandteil des Service-Vertrags, kein nachgelagertes Projekt. Vorbereitung, Testlauf, Wartungsfenster und Rollback-Pfad werden gemeinsam abgestimmt.
Konfigurations-Versionierung – Cluster-, Knoten- und Netzwerk-Konfiguration wird versioniert geführt. Änderungen sind nachvollziehbar — wer hat was wann verändert — und können bei Bedarf auf einen früheren Zustand zurückgespielt werden.
Major-Upgrades laufen nach abgestimmtem Plan in einer geschützten Sequenz: Test im Vorfeld, Wartungsfenster mit Rollback-Pfad, Funktions- und Performance-Nachweis im Anschluss. Sie planen Termin und interne Kommunikation, BEKOM trägt den technischen Ablauf. → Proxmox VE als Plattform im Detail
Inkludierte Services
Im Unterschied zu reinen IaaS-Tarifen sind operative Services bereits enthalten — nicht als Add-on, sondern als Bestandteil des Service-Vertrags. Damit liegt der laufende Betrieb bei BEKOM, nicht in einer Grauzone zwischen Plattform-Anbieter und interner IT.
Typisch im Service-Vertrag enthalten:
Plattform-Monitoring – Auswertung auf Hardware-Ebene (Disk, Memory, Power, Temperatur), Hypervisor-Ebene (Cluster-Status, HA, Storage-Pool) und VM-Ebene (Resource-Sättigung, Antwortzeiten). Auffälligkeiten werden vom BEKOM-Betriebsteam aufgegriffen, nicht erst aus einem Ticket heraus.
Backup-Strategie – Backup-Routinen, Aufbewahrungszeiten und Wiederherstellbarkeit folgen dem im Anforderungsgespräch festgelegten RPO/RTO-Profil. Restore-Tests sind in vereinbartem Turnus Bestandteil des Service-Vertrags und werden protokolliert.
Incident-Response – Bei Störungen greift eine dokumentierte Eskalationskette mit definierten Rollen, Reaktionspfaden und Kommunikationswegen. Rollen und Eskalationsstufen sind vorab schriftlich festgehalten, sodass im Ernstfall klar ist, wer entscheidet und wer informiert wird.
Service-Reviews – Regelmäßiger Termin mit dem BEKOM-Service-Manager: Performance- und Verfügbarkeitsauswertung der zurückliegenden Periode, Capacity-Trends, Incident-Analysen und abgestimmte Maßnahmen für die nächste Periode.
Service-Reviews sind kein reiner Status-Termin, sondern ein strukturiertes Format. Damit bleibt der Betrieb steuerbar — nicht erst dann, wenn etwas eskaliert.
Was BEKOM mit Ihnen individualisiert
Über die Standard-Bausteine hinaus gibt es Bereiche, die erst aus Ihren Anforderungen heraus festgelegt werden — und damit nicht in eine generische Vorlage gehören. Diese vier Felder sind im Anforderungsgespräch der eigentliche Hebel: Sie entscheiden über Wirtschaftlichkeit, Auditfähigkeit, Wiederanlauf und Verantwortungsschnitt.
Individuell pro Cluster ausgelegt:
Dimensionierung – Cluster-Größe, CPU-/RAM-Profil und Storage-Kapazität werden auf Ihr Last-Profil und die Wachstumsprognose über die Vertragslaufzeit ausgelegt. Spitzenlasten, saisonale Effekte und absehbare neue Anwendungen fließen in die Auslegung ein.
Compliance – Auditfähige Prozesse, Dokumentationsgrad und Reporting werden auf Ihren Compliance-Schnitt ausgelegt — von DSGVO als Basis über ISO 27001 und TISAX bis zu KRITIS- oder branchenspezifischen Vorgaben.
Backup-/DR-Strategie – RPO und RTO werden je Anwendungsklasse festgelegt. Aufbewahrungsfristen, Off-Site-Kopien und Multi-Site-Optionen werden so kombiniert, dass Wiederanlauf, Datenschutz und Wirtschaftlichkeit zusammenpassen.
Vertragsmodell – Fully Managed (BEKOM trägt den vollständigen Betrieb), Co-Managed (geteilte Verantwortung mit Ihrer IT) oder beratungsbegleiteter Eigenbetrieb. Die Aufgabenverteilung erfolgt im Vertrag mit RACI-Schnitt — kein impliziter Verantwortungsübergang.
Das Vertragsmodell wird oft unterschätzt: Wer welche Aufgabe trägt, was bei einer Eskalation passiert und wie ein Wechsel zwischen den Modellen ohne Bruch möglich ist, wird vor Vertragsabschluss schriftlich festgehalten.
Drei Verfügbarkeitsstufen im Überblick
Verfügbarkeit und Ausfallsicherheit werden in abgestimmten Stufen angeboten. Welche Stufe pro Kunde passt, wird im Anforderungsgespräch geklärt – abhängig von Geschäftsanforderung, Recovery-Erwartung und Budget.
Konkrete Verfügbarkeits-Werte werden ausschließlich im individuellen Service-Vertrag dokumentiert – nicht auf der Webseite. Allgemeine Werbe-Versprechen ohne Vertragsbezug wären unredlich, weil reale Verfügbarkeit von Architektur, Backup-Strategie und Wartungsfenstern abhängt. Diese Punkte werden für jede Konstellation einzeln vereinbart.
Stufe 1: Einfache Verfügbarkeit (Single-Node mit Backup)
Eine Proxmox-Instanz im BEKOM-Rechenzentrum mit dediziertem Backup. Geeignet, wenn ein toleranzfähiges Ausfallzeitfenster akzeptabel ist.
Architektur – Single-Node-Server mit lokalem Storage; Backup auf ein separates Speicherziel im Rechenzentrum.
Typische Workloads – Test- und Entwicklungsumgebungen, sekundäre Anwendungen, Backoffice-Systeme ohne Echtzeit-Anforderung.
Ausfallverhalten – Bei Hardware-Defekt erfolgt Wiederanlauf aus dem Backup nach dokumentiertem Verfahren.
Stufe 2: Erweiterte Verfügbarkeit (HA-Cluster)
Proxmox-Cluster aus mehreren Knoten mit gemeinsamem Storage. Geeignet für produktive Anwendungen mit höheren Verfügbarkeitsansprüchen.
Architektur – Mehr-Knoten-Cluster mit verteiltem oder repliziertem Storage; Quorum-fähige Auslegung.
Ausfallverhalten – Automatische VM-Übernahme (HA) bei Knotenausfall, ohne manuellen Eingriff.
Wartung – Knoten-Updates und Patches erfolgen über Live-Migration ohne Service-Unterbrechung.
Stufe 3: Multi-Site-Redundanz (Geographisch verteilt)
Proxmox-Plattform über zwei oder mehr räumlich getrennte BEKOM-Standorte. Geeignet, wenn ein Standort-Ausfall keine längere Unterbrechung verursachen darf.
Architektur – Storage-Replikation zwischen Standorten, getrennte Strom-, Klima- und Netzdomänen.
Schutzziel – Toleranz gegen Standort-Ausfall (Strom, Brand, Netz, regionale Störung).
Failover – Definierte Failover-Strategie, dokumentiertes Runbook, regelmäßig getestete Wiederanlauf-Übung.
Kostentreiber Proxmox-Eigenbetrieb versus planbare Betriebskosten
Die Kostentreiber im Proxmox-Eigenbetrieb entstehen durch Hardware-Refresh-Zyklen alle 4–5 Jahre, ungeplante Ausfallzeiten bei fehlendem 24/7-Support und variable Aufwände für Backup-Strategien ohne definierte Recovery-Zeiten.
Besonders bei Cluster-Konfigurationen führt Ein-Personen-Wissen zu Risiko-Aufschlägen in der Personalplanung. BEKOM wandelt diese variablen Kostentreiber in eine planbare Monatspauschale um – von der dedizierten Hardware aus dem Rechenzentrum-Pool über dokumentierte Patch-Prozesse bis zur vertraglich abgesicherten Backup-Strategie mit vereinbartem RPO/RTO. Ein Assessment zeigt die konkrete Kostenstruktur für Ihren Proxmox-Betrieb und identifiziert die größten Kostentreiber in der aktuellen Architektur.
Häufige Fragen zum Proxmox-Hosting
Worin unterscheidet sich BEKOM-Proxmox-Hosting von Massen-Hostern wie Hetzner oder Contabo?
Massen-Hoster bieten standardisierte Tarife mit Self-Service-Konfigurator und niedrigen Einstiegspreisen — sie sind ideal für Einzel-VMs ohne Beratungsbedarf. BEKOM positioniert sich anders: Architektur entsteht im Gespräch, Ressourcen sind dediziert, Dokumentation ist auditfähig, Support deutsch und mit dokumentierter Eskalationsstruktur. Beide Modelle haben ihre Berechtigung — BEKOM passt, wenn die Architektur Beratung verlangt und Compliance-Nachweise gefragt sind.
Können wir eine bestehende Proxmox-Umgebung zu BEKOM migrieren, und wie läuft das ab?
Ja. Bestehende Proxmox-Pools werden über Konfigurations-Export, VM-Backup-Restore oder Live-Replikation migriert — abhängig von Größe, Downtime-Toleranz und Netzwerk-Anbindung. Die Migration läuft in Phasen mit Pilot-VM, Test-Cutover und anschließender Stufenmigration nach Anwendungsgruppen. Der konkrete Plan entsteht im Anforderungsgespräch und wird im schriftlichen Angebot mit Abnahmekriterien je Stufe, Rollback-Optionen und dokumentierter Verantwortungsteilung zwischen Quelle und Ziel fixiert.
Wie entsteht aus dem Anforderungsgespräch ein konkretes, schriftliches Angebot?
Das Anforderungsgespräch klärt Bedarf und Eckpunkte. Daran schließt sich — falls gewünscht — eine technische Bestandsaufnahme an, die Workloads, Topologie und Compliance-Profil erfasst. Auf dieser Basis entsteht ein schriftliches Angebot mit konkreter Spezifikation, Service-Umfang, SLA-Profil, Verfügbarkeitsstufe und Vertragsbedingungen. Die Erstellung erfolgt sorgfältig — konkrete Zeitfenster werden im Vertrag, nicht auf der Webseite zugesagt.
Wer hat Zugriff auf die Proxmox-Konsole — BEKOM oder das interne Team?
Das wird im Vertrag geregelt und ist Teil der Individualisierung. Drei Modelle stehen zur Verfügung: 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, sodass keine Zuständigkeitslücken entstehen.
Was passiert mit unseren VMs und Daten am Vertragsende?
Datenrückgabe und Vertragsende werden vor Unterzeichnung dokumentiert. Standard ist eine strukturierte Übergabe der VM-Images, Konfigurationsdaten, Backup-Archive und Betriebsdokumentation an den Kunden oder einen Folgedienstleister. Aufbewahrungs- und Löschfristen werden im Vertrag fixiert. Es gibt keine technischen Lock-ins — Proxmox VE ist Open Source, Konfigurationen sind portabel und in offenen Formaten dokumentiert, sodass ein späterer Übergang möglich bleibt.
Können einzelne Workloads on-premise bleiben, während andere bei BEKOM laufen?
Ja, hybride Konstellationen sind möglich und häufig der pragmatische Weg. VPN-Anbindung an die On-Premise-Umgebung, getrennte Verantwortungsbereiche pro Standort, gemeinsames Monitoring und einheitliche Backup-Strategie werden im Architektur-Gespräch geklärt. Die Service-Vereinbarung beschreibt explizit, welche Komponenten BEKOM betreibt und welche beim Kunden bleiben — inklusive Schnittstellen-Definition für Datenflüsse, Identity-Provider und Reporting-Pfade zwischen den beiden Welten.
Wie sind Verfügbarkeitsstufen und Notfall-Wiederanlauf vertraglich abgebildet?
Die drei Verfügbarkeitsstufen (Single-Node, HA-Cluster, Multi-Site) werden im Vertrag mit konkreten SLA-Profilen verbunden. Notfall-Wiederanlauf wird in Runbooks mit definierten Rollen, Zeitabläufen und Verantwortlichkeiten dokumentiert; Restore-Tests laufen in vereinbartem Turnus mit dokumentierten Ergebnissen. Bei Multi-Site-Verträgen wird zusätzlich ein dokumentiertes Failover-Verfahren mit regelmäßigen Übungs-Failovern vereinbart, das Bestandteil der Audit-Nachweise gegenüber Compliance-Prüfern und internen Revisionsstellen wird.
Was kostet das Proxmox-Hosting bei BEKOM, und wie wird es kalkuliert?
Konkrete Preise stehen nicht auf der Webseite, weil BEKOM kein Standardtarif-Anbieter ist. Der Preis hängt von Dimensionierung, Verfügbarkeitsstufe, Service-Umfang und Vertragslaufzeit ab. Im Anforderungsgespräch entsteht eine Kosten-Struktur ohne Verbindlichkeit — das schriftliche Angebot enthält dann eine transparente Aufschlüsselung pro Service-Bestandteil (Hardware-Anteil, Service-Anteil, optional Subscription-Anteil), sodass spätere Audit-Prüfungen oder Vergleichs-Bewertungen ohne Black-Box-Effekte möglich sind.
Welche Vertragslaufzeiten sind üblich, und wie flexibel sind Wechsel?
Vertragslaufzeiten orientieren sich am Leistungsumfang und an der Hardware-Lebensdauer. Übliche Bandbreite reicht von 12 Monaten bei kleineren Single-Knoten-Konstellationen bis zu mehrjährigen Verträgen bei Multi-Site-Architekturen mit dedizierter Hardware. Eine Anpassung der Service-Stufe innerhalb der Laufzeit ist im Vertrag geregelt — ein späterer Wechsel von HA auf Multi-Site oder umgekehrt ist vorgesehen, wenn sich die Geschäftsanforderung im Lauf der Zeit nachvollziehbar ändert.
Wie wird die Übergabe einer migrierten Umgebung an den produktiven Betrieb dokumentiert?
Nach Abschluss der Migration übergibt BEKOM ein Betriebshandbuch mit Architektur-Übersicht, Konfigurationsstand, Backup-Strategie, Monitoring-Dashboard, dokumentiertem Change-Prozess und Eskalationswegen. Diese Übergabe ist Bestandteil des Vertrags und enthält die Trennung der Verantwortung zwischen BEKOM und Kunde. Das Dokument bildet die Grundlage für interne Audits und externe Prüfungen, etwa im Rahmen von ISO 27001, TISAX oder branchenspezifischen Compliance-Verfahren.
Kann BEKOM bei Unzufriedenheit die Proxmox-VMs zurück in den Eigenbetrieb migrieren?
BEKOM setzt auf Standard-Proxmox ohne proprietäre Erweiterungen und dokumentiert die komplette Cluster-Architektur transparent. Die VM-Images liegen in Standard-Formaten vor und können bei Bedarf in Ihren eigenen Proxmox-Cluster zurückkehren. Das Service-Design-Dokument enthält alle Konfigurationsparameter, Netzwerk-Segmentierung und Storage-Anbindung, sodass ein Wechsel zurück in den Eigenbetrieb technisch planbar bleibt. Die Daten verbleiben während der gesamten Vertragslaufzeit in deutschen Rechenzentren und unterliegen damit durchgängig deutscher Rechtsprechung.
Nächster Schritt: Hosting-Angebot anfragen
Den Einstieg bildet ein Anforderungsgespräch zur geplanten Proxmox-Umgebung. Daran schließt sich – falls gewünscht – die Bestandsaufnahme an, aus der das schriftliche Angebot mit individualisierter Spezifikation und Verfügbarkeitsstufe entsteht.
Ein Proxmox-Assessment liefert Klarheit über Ihre aktuelle Cluster-Architektur, VM-Verteilung und Storage-Anbindung sowie eine konkrete Empfehlung für die Migration in den BEKOM-Betrieb. Die Bestandsaufnahme umfasst Ihre Proxmox-Konfiguration, Netzwerk-Segmentierung und Backup-Strategien und mündet in ein Service-Design-Dokument mit definiertem Betriebsumfang, SLA-Parametern und einem konkreten Migrationsplan für Ihren dedizierten Proxmox-Cluster im deutschen Rechenzentrum.
Bedarf gemeinsam strukturieren
Im Anforderungsgespräch klären BEKOM-Spezialisten mit Ihrem Team die Eckpunkte: geplante Workloads, Compliance-Anforderungen, Verfügbarkeitsbedarf und Wachstumsprognose. Auf Basis Ihrer Anforderungen bieten wir Ihnen die wirtschaftlich sinnvollste Lösung an.
Spezifikation auf Ihre Anforderungen anpassen
Auf Basis des Gesprächs entsteht eine angepasste Spezifikation – Verfügbarkeitsstufe, Backup-Strategie, Service-Umfang. Die Basis-Spezifikation aus dieser Seite ist Ausgangspunkt, nicht Endpunkt.
Schriftliches Angebot mit dokumentiertem Leistungsumfang
Das Angebot dokumentiert Leistungsumfang, SLA, Vertragsbedingungen und Kostenstruktur in transparenter Form. Es bildet die Grundlage für die Vertragsverhandlung und enthält keine versteckten Bestandteile.