IT-Glossar für Managed Services

Debian ist eine seit 1993 entwickelte, rein community-getragene Linux-Distribution — ohne Commercial-Background. Die aktuelle Stable-Version Debian 12 „bookworm" erhält Security-Updates für fünf Jahre. In unseren Managed-Server-Setups ist Debian die häufigste Wahl für Webserver, Datenbank-Systeme und Container-Hosts, weil es konservativ, vorhersehbar und nahezu wartungsfrei ist.

Debian zeichnet sich durch ein besonders rigoroses Paket-Review-Verfahren aus. Pakete laufen durch „unstable" → „testing" → „stable" — das bedeutet für den Produktivbetrieb: selten Überraschungen.

Ubuntu ist eine Debian-basierte Distribution mit Fokus auf Benutzerfreundlichkeit und einem kommerziellen Support-Angebot durch Canonical. Die LTS-Versionen (Long Term Support) erscheinen alle zwei Jahre und werden fünf Jahre lang gepflegt — optional sogar zehn mit „Ubuntu Pro".

In Serverumgebungen bevorzugen wir Ubuntu 24.04 LTS („Noble Numbat"), weil es neuere Kernels und aktuellere Software als Debian Stable bringt, während Stabilität erhalten bleibt. Typische Einsatzfälle: Docker-Hosts, Kubernetes-Worker, GPU-Server für KI-Workloads.

Red Hat Enterprise Linux (RHEL) ist die kommerzielle Enterprise-Linux-Distribution mit bis zu zehn Jahren Support und Zertifizierungen für SAP, Oracle, VMware und viele Enterprise-Anwendungen. Subscription-Modell — pro Host jährlich zu lizenzieren.

Rocky Linux ist der kostenfreie, binär-kompatible Klon von RHEL, entstanden nach dem Strategie-Wechsel von CentOS durch IBM/Red Hat 2020. Für Organisationen, die die Stabilität und Kompatibilität von RHEL brauchen, aber keine Subscription zahlen wollen.

Wir setzen RHEL/Rocky ein für SAP-Landschaften, Oracle-Datenbanken und Kunden mit strengen Compliance-Vorgaben (BSI-Grundschutz, ISO 27001-Audits).

AlmaLinux ist — wie Rocky Linux — ein kostenfreier RHEL-Klon, entwickelt von der AlmaLinux OS Foundation. Unterschied zu Rocky: AlmaLinux hat früher auf das CIQ-Changes-Modell gewechselt und patcht Sicherheitslücken schneller unabhängig von Red Hat. In der Praxis ist die Wahl zwischen Rocky und AlmaLinux Geschmackssache — beide sind RHEL-binär-kompatibel und werden von uns gleichwertig betreut.

Microsoft Windows Server ist die kommerzielle Server-Version von Windows. Aktuelle LTS-Version ist Windows Server 2025 (veröffentlicht November 2024), die Vorgänger 2022 und 2019 werden noch im Extended Support gepflegt. Zentrale Rolle in den meisten Mittelstands-IT-Landschaften für Active Directory, Datei-Freigaben (SMB), Exchange, Microsoft SQL Server und Remote Desktop Services.

Wir betreuen Windows Server inkl. Active Directory, Gruppenrichtlinien, Failover-Cluster, IIS und Hyper-V. Migration von alten 2012/2016-Instanzen auf 2025 ist eines unserer häufigsten Projektfelder.

Active Directory ist Microsofts Verzeichnisdienst für Windows-Netzwerke. Er speichert Benutzer, Computer, Gruppen und Richtlinien zentral und ist damit das Herzstück jedes Windows-basierten Mittelstands-Setups. Gruppenrichtlinien (GPO) sorgen für einheitliche Konfigurationen über hunderte Geräte hinweg.

Aus Security-Sicht ist AD oft das Hauptangriffsziel — Kompromittierung eines Domain-Controllers bedeutet faktisch Kompromittierung des gesamten Netzwerks. Wir empfehlen dringend Tiered-Admin-Modelle, Kerberos-Härtung (RC4 deaktivieren), LAPS für lokale Admin-Passwörter und regelmäßige Pentests speziell gegen AD.

Linux bezeichnet den 1991 von Linus Torvalds begonnenen Betriebssystem-Kern, der heute über 80 % aller Internet-Server antreibt. Er ist keine Distribution, sondern der Kern, den Distributionen wie Debian, Ubuntu, RHEL oder Rocky Linux ergänzen. Alle Android-Smartphones und die meisten Cloud-Workloads laufen auf Linux-Kernels.

Für einen professionellen Managed-Server-Provider wie uns ist Linux-Kompetenz unverzichtbar: Fast jede Spezial-Anwendung (Datenbanken, Container, Monitoring-Stacks, Security-Tools) hat ihre primäre Heimat auf Linux.

Proxmox Virtual Environment (VE) ist eine österreichische Open-Source-Virtualisierungsplattform, die KVM (für VMs) und LXC (für Container) in einem gemeinsamen Management-Interface bündelt. Seit der Broadcom-Übernahme von VMware und den massiven Lizenzänderungen 2024/25 hat Proxmox erheblichen Aufwind: viele unserer Kunden migrieren aktuell von vSphere zu Proxmox VE.

Proxmox unterstützt Cluster aus bis zu 32 Nodes, Ceph-basierte Hyperconverged-Storage, ZFS, Live-Migration und granulare Berechtigungen. Kostenlos nutzbar, Subscription nur für Enterprise-Repository und Support.

VMware vSphere ist seit über 20 Jahren der dominierende Enterprise-Hypervisor. Besteht aus ESXi (dem bare-metal Hypervisor, der direkt auf der Hardware läuft) und vCenter (dem zentralen Management-Server). Nach der Broadcom-Übernahme 2023/24 sind die Lizenzkosten teilweise verfünffacht worden — was viele Mittelständler zum Wechsel auf Alternativen bewegt.

Wir betreiben weiterhin vSphere für Kunden mit großen bestehenden Investments oder spezifischen Abhängigkeiten (z.B. Horizon VDI). Bei Neu-Setups empfehlen wir aber meist Proxmox VE oder Hyper-V.

Hyper-V ist der Microsoft-eigene Hypervisor, der in jeder Windows-Server-Lizenz bereits enthalten ist. Kostenmäßig damit besonders attraktiv für Unternehmen, die ohnehin Windows-Lizenzen betreiben. Integration mit System Center, Active Directory und Azure Arc.

Wir setzen Hyper-V typischerweise in Windows-dominierten Umgebungen ein (z.B. File-Server-Cluster, SQL-Server-Konsolidierung). Für Linux-VMs leisten sich die meisten Kunden allerdings eher Proxmox, weil Hyper-V bei Linux-Workloads nicht immer die beste Performance liefert.

KVM (Kernel-based Virtual Machine) ist der im Linux-Kernel eingebaute Hypervisor seit 2007. Technische Basis für Proxmox VE, Red Hat Virtualization, OpenStack und die meisten Cloud-Provider (u.a. AWS Nitro, Google Cloud Compute).

LXC (Linux Containers) sind System-Container — leichter als VMs, schwerer als Docker-Container. Sie teilen sich den Kernel des Host, sind aber ansonsten isoliert. Ideal für klassische Anwendungen, die nicht als Docker-Container verfügbar sind, aber Ressourcen-Effizienz bringen sollen.

Kubernetes — ursprünglich von Google entwickelt und 2014 als Open-Source-Projekt gespendet — ist heute der De-facto-Standard für Container-Orchestrierung. Es verwaltet Deployments, Skalierung, Load-Balancing, Secrets und Netzwerk über verteilte Container-Cluster. Die deklarative API („wie soll der Zustand sein") trennt „Was will ich?" von „Wie erreiche ich das?".

In der Mittelstands-Realität ist Kubernetes oft Over-Engineering — für weniger als 20 Services lohnt sich der Komplexitäts-Aufschlag meist nicht. Wir empfehlen K8s dann, wenn mehrere Entwicklungs-Teams autonom deployen müssen, oder wenn Stateless-Services elastisch skalieren sollen. On-Premise setzen wir K3s oder RKE2 ein, für minimalere Footprints.

Docker ist seit 2013 die Standard-Container-Runtime auf Linux. Seine Image-Spezifikation (OCI) wurde zum offenen Standard, auf dem auch Kubernetes basiert. Für einfache Container-Setups ohne K8s-Overhead eignet sich Docker Compose — die Datei docker-compose.yml beschreibt mehrere Container + ihre Netzwerke und Volumes.

Docker Swarm war der eingebaute Orchestrator, wurde aber von Kubernetes verdrängt. Wir nutzen Docker vor allem bei Einzel-Host-Setups: Selfhosted-Apps wie Nextcloud, Matomo, Mailcow, oder Reverse-Proxies mit Traefik.

Ein Container ist eine in sich abgeschlossene Laufzeitumgebung für Anwendungen, die sich den Kernel des Hosts teilt, aber ansonsten isoliert ist (eigenes Dateisystem, eigene Netzwerk-Namespace, eigene Prozess-IDs). Container sind schneller zu starten und ressourcen-effizienter als VMs — dafür sind sie nicht ganz so stark isoliert (Shared-Kernel-Risiko).

Container sind das Fundament moderner Cloud-Native-Architekturen, werden aber zunehmend auch im klassischen Betrieb eingesetzt, um Deployment-Komplexität zu reduzieren. Wichtig: Container-Images müssen regelmäßig aktualisiert werden — „ich habe einen Container vor 2 Jahren gebaut" ist der Anfang eines Security-Incidents.

XCP-ng ist eine Community-Fortsetzung von Citrix XenServer, nachdem Citrix 2018 das Open-Source-Model aufgegeben hat. Nutzt den Xen-Hypervisor. In der Praxis weniger verbreitet als Proxmox, aber für spezifische Anwendungsfälle (z.B. XenCenter-vertraute Admins, spezifische Enterprise-Features) relevant.

Zero Trust ist ein Sicherheits-Paradigma, das den traditionellen „Burg-mit-Wassergraben"-Ansatz ersetzt. Statt dem internen Netzwerk zu vertrauen und nur außen zu schützen, wird jeder Zugriff — auch intern — authentifiziert, autorisiert und verschlüsselt. Grundlage: „never trust, always verify".

Konkrete Bausteine: MFA überall, kontinuierliche Session-Verifikation, Micro-Segmentierung des Netzes, Identity-zentrische Zugriffskontrolle (nicht mehr IP-basiert), ZTNA statt klassischem VPN. Ein vollständiges Zero-Trust-Modell ist ein Projekt von 2–3 Jahren, aber schon kleine Schritte (MFA, Least-Privilege) liefern große Sicherheits-Gewinne.

Ein SIEM sammelt Logs aus allen Systemen einer Organisation — Server, Firewalls, Active Directory, Anwendungen — und korreliert Events, um Angriffe zu erkennen. Klassische SIEMs waren lange schwer zu betreiben und hatten hohe Lizenzkosten. Open-Source-Alternativen wie Wazuh haben das Feld demokratisiert.

Ohne SIEM haben Sie keine Chance, einen Angriff zu bemerken, der länger als einen Tag dauert — Forensik wird zur Archäologie. Wir betreiben SIEMs sowohl als Dedicated-Installation beim Kunden als auch als geteilte Plattform für kleinere Organisationen.

Ein Security Operations Center ist die Kombination aus Menschen, Tools und Prozessen, die rund um die Uhr die Sicherheit einer Organisation überwacht. Ein SIEM ist das Tool, aber ein SOC ist das Team, das die Alerts tatsächlich analysiert und auf sie reagiert. Eigenes SOC aufzubauen kostet Millionen — Managed SOCs sind der Standard für Mittelstand.

Wazuh ist eine Open-Source-Security-Plattform, die SIEM-, HIDS- (Host-based Intrusion Detection) und XDR-Funktionen kombiniert. Agents auf den Servern sammeln Logs, Dateiintegrität, Vulnerabilities und verhaltensbasierte Events, zentrale Dashboards liefern Korrelationen und Alerts. Kostenfrei verfügbar, kommerzieller Support durch Wazuh Inc. oder Partner wie uns.

Wir haben Wazuh in über 20 Kundenprojekten implementiert und sehen es als beste Option für mittelständische Organisationen, die nicht die Budget-Dimension eines Splunk oder QRadar haben, aber trotzdem echte Security-Visibility brauchen.

Die CIS Benchmarks sind detaillierte Konfigurationsrichtlinien, die das Center for Internet Security (eine US-Non-Profit) für hunderte von Technologien herausgibt — von Windows 10 über Debian 12 bis Kubernetes. Sie konkretisieren „Sicherheit" in umsetzbare, auditierbare Schritte: „SSH Protocol 2 only", „Passwordless sudo disabled", „Fail2Ban aktiv".

Wir nutzen CIS Benchmarks als Checkliste beim Server-Onboarding. Compliance-Auditoren (ISO 27001, BSI) akzeptieren sie als Stand der Technik. Die Benchmarks sind kostenlos in der PDF-Version, das Tooling zur automatisierten Prüfung ist teilweise kostenpflichtig.

Fail2Ban ist ein einfaches, aber wirkungsvolles Python-Tool, das Log-Dateien beobachtet und bei verdächtigen Mustern (z.B. 5 fehlgeschlagene SSH-Logins innerhalb von 2 Minuten) automatisch IP-Adressen per iptables/nftables blockiert. Gehört bei uns zum Standard-Build jedes Linux-Servers — verhindert zuverlässig automatisierte Brute-Force-Angriffe.

Ransomware ist Schadsoftware, die Daten und Systeme verschlüsselt, um Lösegeld zu erpressen. Aktuelle Varianten kombinieren Verschlüsselung mit Datendiebstahl („Double Extortion"): Zahlung wird nicht nur für die Entschlüsselung erpresst, sondern auch dafür, dass kopierte Daten nicht veröffentlicht werden.

Einfallswege sind meist ähnlich: Phishing-E-Mails mit Office-Makros, kompromittierte RDP-Zugänge, ungepatchte Exchange- oder VPN-Systeme. Die Verteidigung ist nicht ein einzelnes Tool, sondern eine Kette: MFA, Patching, Segmentierung, EDR, immutable Backups, Awareness-Trainings und ein getesteter Notfallplan.

Ein Penetration Test (Pentest) ist ein kontrollierter Angriff auf Ihre eigene IT durch ein beauftragtes Security-Team. Ziel: konkrete Schwachstellen finden, die reale Angreifer ausnutzen würden. Unterschied zum Vulnerability Scan: ein Pentest kombiniert automatisierte Tools mit manuellen, kreativen Angriffs-Techniken.

Wir empfehlen einen jährlichen Pentest für alle Kunden mit Internet-exponierten Systemen — mindestens für Kronjuwelen (Kundendaten, Patientendaten, Finanzsysteme). NIS2 und die ISO 27001 machen regelmäßige Tests zunehmend zur Pflicht.

ISO/IEC 27001 ist die international anerkannte Norm für Informationssicherheits-Management-Systeme (ISMS). Sie schreibt keine konkreten Technologien vor, sondern einen risikobasierten Prozess: Assets identifizieren, Risiken bewerten, Maßnahmen ableiten, kontinuierlich verbessern. Die Zertifizierung nach ISO 27001 ist oft Voraussetzung für Großkunden, Versicherungen oder Ausschreibungen.

Die letzte große Revision 2022 („Annex A rework") brachte neue Controls für Cloud-Sicherheit, Threat Intelligence und ICT Readiness. Wir arbeiten nach ISO 27001-Prozessen — ohne eigene Zertifizierung zu sein, können wir Kunden in ihrem Zertifizierungs-Prozess unterstützen.

Der BSI IT-Grundschutz ist die vom Bundesamt für Sicherheit in der Informationstechnik (BSI) herausgegebene Methodik zur Absicherung von IT-Systemen. Konkreter als ISO 27001 — mit detaillierten Bausteinen für typische Szenarien (Webserver, VPN-Gateway, AD-Server, mobile Geräte). Pflicht für Bundesbehörden, Empfehlung für KRITIS-Betreiber.

Grundschutz und ISO 27001 sind gegenseitig kompatibel — eine BSI-Grundschutz-Zertifizierung ist gleichzeitig eine ISO 27001-Zertifizierung. Für mittelständische Organisationen ist der „Basis-Schutz" eine gute Einstiegsvariante ohne das volle Prozess-Overhead.

Die Nachfolgerin der NIS-Richtlinie von 2016. NIS2 trat offiziell am 17. Oktober 2024 in Kraft und erweitert den Scope erheblich: Nicht mehr nur „Betreiber wesentlicher Dienste" sind betroffen, sondern alle mittleren und großen Unternehmen in 18 Sektoren — darunter Energie, Gesundheit, Transport, Lebensmittel, Banken, aber auch IT-Dienstleister, Rechenzentren und Hersteller.

Neue Pflichten: Risikomanagement, Incident-Meldepflicht innerhalb von 24h, Lieferkettensicherheit, Geschäftsführer-Haftung. Die deutsche Umsetzung erfolgte mit einiger Verzögerung — dennoch sind Unternehmen seit 2024 formal in der Pflicht. Bei Verstößen drohen Bußgelder bis 10 Mio. € oder 2 % des Jahresumsatzes.

KRITIS-Betreiber sind Organisationen, deren Ausfall erhebliche gesamtwirtschaftliche oder gesellschaftliche Auswirkungen hätte — Krankenhäuser, Energieversorger, Wasserwerke, Finanzdienstleister. Sie unterliegen besonderen Schutzpflichten nach dem BSI-Gesetz (§8a): angemessene Sicherheitsmaßnahmen, Nachweis alle zwei Jahre, Meldepflicht bei Störungen.

KRITIS und NIS2 überschneiden sich, sind aber nicht deckungsgleich — KRITIS ist ein deutsches Konzept, NIS2 ein europäisches. Viele KRITIS-Betreiber sind gleichzeitig von NIS2 erfasst.

Die Datenschutz-Grundverordnung regelt seit 2018 EU-weit den Umgang mit personenbezogenen Daten. Für Managed-Services relevant: Art. 28 regelt die Auftragsverarbeitung — wann immer wir als Dienstleister auf Server zugreifen, auf denen personenbezogene Daten liegen, wird ein Auftragsverarbeitungsvertrag (AVV) fällig.

Ein professioneller Managed-Server-Vertrag enthält den AVV als Anlage, mit klaren Regeln zu Weisungsgebundenheit, technischen-organisatorischen Maßnahmen (TOM) und Subunternehmer-Nutzung. Wir nutzen ausschließlich deutsche Rechenzentren — das schließt Datentransfer in Nicht-EU-Länder aus.

TISAX (Trusted Information Security Assessment Exchange) ist der Branchen-Standard für Informationssicherheit in der Automobil-Industrie. Entwickelt vom Verband ENX auf Basis von ISO 27001, mit Automotive-spezifischen Ergänzungen (z.B. Prototypenschutz). Pflicht für Zulieferer, die mit VW-, BMW-, Mercedes-, Audi-Daten arbeiten.

Wann immer ein IT-Dienstleister auf Systeme zugreift, auf denen personenbezogene Daten liegen, muss ein AVV vorhanden sein. Er regelt, dass der Dienstleister nur auf Weisung des Kunden handelt, welche TOMs (technisch-organisatorische Maßnahmen) gelten und welche Subunternehmer einbezogen werden dürfen.

Ein SLA definiert präzise, was „Service" bedeutet: Welche Verfügbarkeit (z.B. 99,9 %)? Welche Reaktionszeit bei Incidents (z.B. < 30 Min bei P1)? Welche Öffnungszeiten? Wie werden Messungen durchgeführt? Welche Konsequenzen bei Nicht-Erreichen?

99,9 % Verfügbarkeit klingt gut — heißt aber „bis zu 43 Minuten Ausfall pro Monat". 99,99 % („Four Nines") erlaubt nur 4,3 Minuten. Wir empfehlen, nicht blind 99,9 % zu akzeptieren, sondern zu fragen: „Wie wird Verfügbarkeit gemessen? Was zählt als Ausfall?" — hier versteckt sich oft der Teufel im Detail.

MTTR (Mean Time to Recovery) ist die durchschnittliche Zeit von Störungs-Beginn bis Wiederherstellung. Hauptgröße für die tatsächliche Service-Qualität — eine perfekte Infrastruktur mit schlechter MTTR ist in der Praxis schlechter als eine durchschnittliche mit schneller Recovery.

MTBF (Mean Time Between Failures) misst die mittlere Zeit zwischen Ausfällen — sagt also etwas über Zuverlässigkeit aus. In unserem Fleet-Durchschnitt liegt MTTR bei unter 15 Minuten, MTBF bei über 18 Monaten pro Server.

Uptime kann zwei Dinge bedeuten: (1) die Zeit seit dem letzten Reboot eines einzelnen Servers, (2) die prozentuale Verfügbarkeit eines Service über einen Zeitraum. Linux-Admins lieben hohe Uptimes („487 Tage ohne Reboot!"), aus Security-Sicht ist das aber problematisch — ein Kernel, der 487 Tage nicht neugestartet wurde, hat vermutlich ungepatchte Security-Lücken.

Wir setzen auf regelmäßige, geplante Reboots in Wartungsfenstern statt auf Rekord-Uptimes. Mit Live-Kernel-Patching (kpatch, kernelcare) lassen sich Security-Fixes auch ohne Reboot einspielen.

Patch-Management ist der strukturierte Prozess, Security- und Funktions-Updates zu testen, zu deployen und zu dokumentieren. Ohne Prozess wird das zum Hit-or-miss: entweder wird nie gepatcht (Security-Risiko) oder blind gepatcht (Ausfall-Risiko).

Wir arbeiten mit abgestuftem Rollout: kritische Security-Patches innerhalb von 48h, Standard-Updates monatlich in geplanten Fenstern. Vor jedem Patch: Backup-Verifikation, Pre-Prod-Test (wo möglich), Rollback-Plan.

Incident Response ist der geplante Ablauf bei Störungen: Erkennung → Klassifizierung → Eskalation → Mitigation → Recovery → Post-Mortem. Jede Stufe mit klaren Verantwortlichkeiten, Zeit-Targets und Dokumentations-Pflichten. Ohne Playbook wird jeder Incident zur Improvisation — und damit zur verlängerten Auswirkung.

Ein Post-Mortem ist die strukturierte Nachbesprechung eines Incidents: Was ist wann passiert? Was war die Ursache? Was hat gut funktioniert? Was muss verbessert werden? Entscheidend ist die Blameless-Kultur — nicht „wer ist schuld?", sondern „welches System hat versagt und wie verhindern wir das?". Ohne Post-Mortem-Kultur wiederholt sich jeder Incident.

Ein Runbook ist die dokumentierte Schritt-für-Schritt-Anleitung für wiederkehrende oder kritische Aufgaben — „Was tun, wenn Disk voll?", „Wie Datenbank-Failover durchführen?". Gut geschriebene Runbooks erlauben es, dass auch ein Bereitschafts-Engineer um 3 Uhr morgens den richtigen nächsten Schritt macht. Wir pflegen über 200 Runbooks für unsere Kunden-Systeme.

Ein Backup ist eine Kopie von Daten, aus der im Fehlerfall wiederhergestellt werden kann. Klingt trivial — ist aber in 80 % der Fälle unvollständig. Häufige Fehler: nur File-Backup (keine Applikations-Konsistenz), kein Offsite-Kopie (gleicher Brand zerstört Primary + Backup), keine Restore-Tests, kein Schutz gegen Ransomware-Zerstörung der Backup-Dateien selbst.

Die 3-2-1-Regel ist der Industry-Standard für robuste Backup-Strategien: 3 Kopien der Daten (Original + 2 Backups), 2 verschiedene Speicher-Medien (z.B. Disk + Tape oder Disk + Object Storage), 1 Kopie offsite (physisch entfernt vom Original).

Moderne Erweiterung: 3-2-1-1-0 — zusätzlich 1 Kopie offline/immutable (gegen Ransomware) und 0 Fehler beim letzten Restore-Test. Wir orientieren uns an dieser erweiterten Regel.

Disaster Recovery ist der geplante Ablauf zur Wiederherstellung einer IT-Umgebung nach einem Totalausfall (Brand, Überschwemmung, Ransomware-Totalbefall). Ein DR-Plan beschreibt nicht nur „wie restore ich Daten?", sondern „in welcher Reihenfolge stelle ich Services wieder her?", „welche Abhängigkeiten existieren?", „wer trifft welche Entscheidungen?".

DR-Pläne sind nur so gut wie die letzte DR-Übung — wir empfehlen jährliche Simulationen, bei denen ein ganzes System kontrolliert abgeschaltet und aus dem Backup wiederhergestellt wird.

RPO (Recovery Point Objective) ist der maximal akzeptable Datenverlust, gemessen in Zeit. RPO = 1 Stunde heißt: Im Ernstfall verliere ich höchstens die letzte Stunde an Daten — also muss ich mindestens stündlich sichern.

RTO (Recovery Time Objective) ist die maximal akzeptable Wiederherstellungs-Dauer. RTO = 4 Stunden heißt: Nach 4 Stunden muss der Service wieder laufen — das determiniert Backup-Technologie, Infrastruktur und Personal-Kapazität.

RPO und RTO sollten fachlich festgelegt werden, nicht technisch: „Wie lange kann die Produktion stehen, bevor es existenzbedrohend wird?" ist eine Business-Frage, keine IT-Frage.

Veeam ist ein führender Anbieter von Enterprise-Backup-Software mit Fokus auf virtualisierte Umgebungen (VMware, Hyper-V, Nutanix). Bietet Application-Aware-Backups (Datenbank-konsistente Snapshots), Instant-Recovery (VM direkt aus Backup booten), Replikation und Cloud-Tiering. Lizenz pro Host/VM.

Der Proxmox Backup Server ist eine dedizierte Backup-Lösung der Proxmox-Macher. Client-side Deduplication (Chunk-Level) macht inkrementelle Backups sehr effizient — auch bei vielen VMs. Verify-Jobs prüfen regelmäßig die Integrität der Chunks. Für Kunden, die bereits Proxmox VE nutzen, ist PBS die natürliche Ergänzung.

Prometheus ist der De-facto-Standard für Metric-basiertes Monitoring in Kubernetes- und Cloud-Native-Umgebungen. Pullt Metriken von Exportern (statt Push) und speichert sie als Time-Series. Seine Query-Language PromQL ist mächtig, aber gewöhnungsbedürftig.

Wir nutzen Prometheus für Infrastructure- und Application-Monitoring. Typische Exporter: Node-Exporter (OS-Metriken), Blackbox-Exporter (Endpoint-Probing), PostgreSQL-Exporter, Nginx-Exporter.

Grafana ist der Standard für Dashboard-Visualisierungen von Monitoring-Daten. Unterstützt Prometheus, Loki, Elasticsearch, InfluxDB, PostgreSQL und viele andere Datasources. Das Ökosystem bietet tausende von Community-Dashboards, die sich für Standard-Anwendungsfälle (Linux-Nodes, PostgreSQL, Kubernetes) direkt importieren lassen.

Loki von Grafana Labs ist eine Log-Aggregation, die ähnlich wie Prometheus denkt: statt alle Log-Inhalte zu indizieren, werden nur Labels indiziert — die eigentlichen Logs liegen komprimiert in Object Storage. Ergebnis: sehr viel günstiger als klassische ELK-Stacks, aber mit etwas anderer Query-Logik.

Der Alertmanager nimmt Alerts von Prometheus entgegen, dedupliziert, gruppiert und routet sie zu den richtigen Empfängern — E-Mail, Slack, Teams, PagerDuty, SMS. Silencing für bekannte Wartungsfenster, Escalation für ungewollte Non-Response. Ein gut konfigurierter Alertmanager ist die Differenz zwischen „95 Alerts pro Tag, alle ignoriert" und „3 Alerts pro Tag, alle beachtet".

Bei Managed Server übernimmt ein Dienstleister den kompletten operativen Betrieb eines dedizierten oder virtualisierten Servers — Installation, Monitoring, Patching, Security-Hardening, Incident-Response. Der Kunde nutzt die Anwendungen, kümmert sich aber nicht um die Infrastruktur.

Managed Hosting ist die Full-Stack-Variante: der Dienstleister stellt Hardware, Rechenzentrum, Netz, Betriebssystem und Anwendungsbetrieb — alles aus einer Hand. Die Grenze zu Managed Server ist fließend; Managed Hosting betont die physische Infrastruktur stärker.

Bei Colocation bringt der Kunde seine eigene Hardware mit und mietet vom Provider nur Platz (Rack-Einheiten), Strom, Kühlung und Internet-Anschluss. Betrieb und Wartung liegen beim Kunden. Für Organisationen, die ihre Hardware schon haben oder Datenhoheit auf physischer Ebene wünschen, aber kein eigenes Rechenzentrum betreiben wollen.

On-Premise heißt: Die Systeme laufen physisch beim Kunden (eigener Serverraum, eigenes Rechenzentrum). Gegensatz zu Cloud/Off-Premise. Für Datenhoheit, Compliance-Anforderungen oder spezielle Latenz-Anforderungen (Produktion, Medizin) oft die einzige Option. Wir bieten Managed-Services auch on-premise — mit Fernzugriff über VPN/Bastion-Host.

Hybrid Cloud kombiniert On-Premise-Ressourcen mit Public Cloud — typischerweise bleiben sensible Daten on-premise, während variable Lasten in die Cloud ausgelagert werden. Technische Voraussetzung: Site-to-Site-VPN oder Direct-Connect, gemeinsame Identity, konsistente Netzsegmentierung.

HAProxy ist seit 2000 ein extrem performanter TCP- und HTTP-Load-Balancer, der in praktisch jeder High-Traffic-Site der Welt eingesetzt wird. Gegenüber Nginx stärker in reinem Load-Balancing, etwas schwächer bei statischem Content. Unsere typische Wahl für Production-Front-Ends.

Nginx ist heute der meistverwendete Webserver im Internet — vor Apache HTTP Server. Stärken: extrem geringer Ressourcenverbrauch, asynchroner Event-Loop, eingebauter Reverse-Proxy und Load-Balancer. Wir nutzen Nginx als Front-End vor Application-Servern und als TLS-Terminator.

VPN schafft einen verschlüsselten Tunnel über ein unsicheres Netzwerk — klassisch für Remote-Access von Heimarbeitsplätzen zu Firmensystemen oder für Site-to-Site-Verbindungen zwischen Standorten. Technologien: IPsec (legacy, aber überall), OpenVPN (TLS-basiert), WireGuard (modern, performant).

Klassische VPNs geraten zunehmend in die Kritik, weil sie Netzwerk-Zugang gewähren statt Anwendungs-Zugang. Der Trend geht zu ZTNA.

ZTNA ist ein Zugriffsmodell, bei dem nicht das Netzwerk freigegeben wird, sondern einzelne Anwendungen — nach erfolgreicher Authentifizierung und Autorisierung pro Zugriff. Der Client sieht die Anwendung erst, nachdem er authentifiziert wurde. Deutlich sicherer als klassisches VPN, weil lateral movement erschwert wird.

TLS ist das Protokoll, das Verbindungen im Internet verschlüsselt und authentifiziert — die Basis hinter HTTPS, IMAPS, SMTPS und vielen anderen „-S"-Protokollen. Aktuelle Versionen sind TLS 1.2 und TLS 1.3. TLS 1.0 und 1.1 sind seit Jahren deprecated und sollten überall deaktiviert sein.

In unseren Managed-Server-Setups sorgen wir für aktuelle Cipher-Suites, HSTS, automatische Zertifikat-Erneuerung (meist via Let's Encrypt), korrekte Chain-Konfiguration und regelmäßige SSL-Labs-Tests (Ziel: Rating A+).

SSH ist der Standard für den verschlüsselten Remote-Zugriff auf Linux-Systeme. Port 22 (standardmäßig, aber von uns geändert), Public-Key-Authentifizierung (Passwort-Login deaktiviert), Fail2Ban gegen Brute-Force, Bastion-Host als Sprungbrett. Typische Härtung: nur Protocol 2, keine Root-Logins, strikte Cipher-Liste.

PostgreSQL ist die verlässlichste Open-Source-Relational-DB der Welt — mit ACID-Transaktionen, MVCC, JSONB für semi-strukturierte Daten, Streaming Replication, logischer Replikation, Partitionierung und einer extrem stabilen Roadmap. Wird von uns für fast alle Kundenprojekte als Default gewählt, wo eine relationale DB gebraucht wird.

MySQL ist die am weitesten verbreitete Open-Source-DB, Teil des klassischen LAMP-Stacks. Seit der Oracle-Übernahme 2010 hat sich MariaDB als Community-Fork etabliert — binär kompatibel, aber mit eigener Feature-Entwicklung. Praktisch: MariaDB als Drop-in-Replacement für MySQL, die meisten Anwendungen funktionieren ohne Anpassung.

MongoDB ist die bekannteste NoSQL-Document-DB. Statt Tabellen speichert sie BSON-Dokumente (binäres JSON). Gut geeignet für Anwendungen mit flexiblem Schema oder tiefer JSON-Struktur. In der Realität ist PostgreSQL mit JSONB-Typ oft die bessere Wahl — wir empfehlen MongoDB nur dort, wo die spezifischen Stärken (Auto-Sharding, Aggregation-Pipeline) wirklich genutzt werden.

Replication ist der Prozess, bei dem Änderungen von einer primären Datenbank kontinuierlich auf eine oder mehrere Replicas übertragen werden. Zwecke: High Availability (automatisches Failover), Lastverteilung (Lesezugriffe auf Replicas), Offsite-Backup. Synchrone Replication garantiert Null Datenverlust — kostet aber Performance. Asynchrone Replication ist schneller, aber mit möglichem Replication-Lag.