# Ein europäischer IT-Stack: Digitale Souveränität durch austauschbare Architektur

Source: https://forgeone.solutions/de/inside-forgeone/europaeischer-it-stack-austauschbare-architektur
Language: de
Published: 2026-10-19
Updated: 2026-10-19

Digitale Souveränität entsteht nicht durch eine starre Produktliste, sondern durch funktionale Architekturbereiche, getestete Exit-Pfade und austauschbare Plattformverbünde.

Was bedeutet digitale Souveränität, wenn eine Organisation ihre Infrastruktur nicht auf der grünen Wiese neu baut? Die Debatte bleibt häufig bei europäischen Cloud-Anbietern, dem Speicherort von Daten oder dem Austausch einzelner Anwendungen stehen. Das sind wichtige Fragen, aber noch keine belastbare Architektur.

Für uns bei ForgeOne beginnt Souveränität mit Kontrolle: über Daten, Betrieb, Identitäten, Schnittstellen, Wiederherstellung und zukünftige Veränderungen. Eine Technologieentscheidung darf nicht zur unumkehrbaren Bindung werden. Gleichzeitig wäre es unrealistisch, vollständige Unabhängigkeit oder einen unterbrechungsfreien Wechsel zwischen beliebigen Plattformen zu versprechen.

Unser Ziel ist deshalb keine uneingeschränkte Eins-zu-eins-Austauschbarkeit einzelner Produkte. Wir wollen funktionale Architekturbausteine so planen, dass eine Organisation sie mit Vorbereitung, Tests und geeigneten Ressourcen kontrolliert ersetzen kann. Wenn dabei angrenzende Werkzeuge oder Prozesse angepasst werden müssen, ist das kein Scheitern des Prinzips, sondern Teil einer ehrlich entworfenen Exit-Strategie.

## Das Wichtigste auf einen Blick

Ein europäischer IT-Stack lässt sich für viele klar abgegrenzte Anforderungen bereits heute aufbauen. Technologien für Virtualisierung, Betriebssysteme, Identitätsmanagement, Backup und Zusammenarbeit sind verfügbar. Eine vollständige Unabhängigkeit von internationalen Herstellern und Lieferketten entsteht dadurch jedoch nicht.

Entscheidend sind nicht allein Herkunft und Lizenzmodell, sondern die Integration der Komponenten, langfristige Wartbarkeit, Wiederherstellbarkeit und realistische Migrationsmöglichkeiten. Gerade bei bestehenden Infrastrukturen müssen Funktionsumfang, Betriebsaufwand und wirtschaftliche Risiken berücksichtigt werden.

EuroStack verfolgt das Ziel, europäische Technologieangebote und deren Rahmenbedingungen zu stärken. Die Initiative ersetzt aber keine technisch geprüfte Referenzarchitektur.

## Was ist ein europäischer IT-Stack?

Ein europäischer IT-Stack ist für uns kein Herkunftssiegel für eine willkürliche Produktliste. Mindestens fünf Perspektiven müssen getrennt bewertet werden: rechtlicher Unternehmenssitz, Eigentümerstruktur, Entwicklung und Governance, technologische Abhängigkeiten sowie die tatsächliche Fähigkeit, eine Lösung selbst zu betreiben und später zu verlassen.

### A. Europäische Anbieter

Dazu zählen Anbieter mit europäischem Sitz und nachvollziehbarer Produktverantwortung. Beispiele im Infrastruktur- und Arbeitsplatzumfeld sind Proxmox und LINBIT in Österreich, Bareos, Univention, OpenProject, Nextcloud, Open-Xchange und Checkmk in Deutschland sowie XWiki in Frankreich. Dabei bleibt relevant, ob der Sitz innerhalb der EU oder in einem europäischen Nicht-EU-Staat liegt. Der Sitz allein beantwortet weder die Eigentümer- noch die Governance-Frage.

SUSE verdeutlicht diese notwendige Trennung: Das Unternehmen wurde in Deutschland gegründet, hat seinen Hauptsitz in Luxemburg und beschreibt sich selbst als schwedisch kontrolliert. Unternehmenssitz, Eigentümerstruktur, Entwicklungsstandorte und technische Kontrolle sind damit verschiedene Kriterien, die nicht zu einem einzigen Herkunftsetikett verkürzt werden sollten.

### B. International entwickelte Open-Source-Technologien

Debian ist ein internationales Community-Projekt. Kubernetes und Keycloak werden in globalen Open-Source-Ökosystemen entwickelt. Ansible ist ein Open-Source-Projekt mit kommerziellem Red-Hat-Ökosystem; Ubuntu wird von Canonical mit internationaler Organisation getragen. Solche Technologien sind nicht ausschließlich europäisch. Sie können dennoch einen souveränen Eigenbetrieb ermöglichen, weil Quellcode, offene Schnittstellen, dokumentierte Datenpfade und ein breites Ökosystem die Kontrolle verbessern. Open Source ist hier ein Werkzeug für Kontrolle, aber kein automatischer Herkunftsnachweis.

### C. Verbleibende Abhängigkeiten

Hardware, Prozessoren, Firmware, Fertigungskapazitäten, Bibliotheken, externe Dienste und spezialisierte Fachanwendungen bleiben häufig von internationalen Lieferketten oder proprietären Komponenten abhängig. Ein seriöses Zielbild benennt diese Grenzen und prüft, wer Roadmap, Lizenzmodell und technische Weiterentwicklung kontrolliert. Europäische Herkunft kann digitale Souveränität unterstützen, ersetzt aber keine offene, kontrollierbare und austauschbare Architektur.

## EuroStack und europäische Technologiepolitik: Initiative statt Referenzarchitektur

Die [EuroStack-Initiative](https://eurostack.eu/) ist mit Stand Oktober 2026 eine industriepolitische Initiative. Sie will Technologie, Governance und Finanzierung zusammenführen, damit europäische digitale Infrastruktur von Konnektivität über Cloud und Software bis zu KI aufgebaut und genutzt wird. Sie ist damit weder ein Produktkatalog noch eine getestete Referenzarchitektur, die konkrete Komponenten automatisch kompatibel macht.

EuroStack beschreibt die Leitlinien „Buy European“, „Sell European“ und „Fund European“. Die Initiative stellt zugleich klar, dass sie keine vollständige Abkopplung von US-Technologie anstrebt, sondern belastbare europäische Alternativen und mehr Wettbewerb. Diese [Selbstbeschreibung und Abgrenzung](https://eurostack.eu/who-we-are/) ist wichtig: Politische Zielsetzung, verfügbare Produkte und praktisch integrierte Betriebsarchitektur sind drei unterschiedliche Reifegrade.

Die [EU-Strategie zur Technologiesouveränität](https://digital-strategy.ec.europa.eu/de/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy) umfasst Chips, Infrastruktur, Software, Cloud und KI und verbindet sie unter anderem mit einer Open-Source-Strategie. Der [Bericht zur digitalen Dekade 2026](https://digital-strategy.ec.europa.eu/en/policies/2026-state-digital-decade-package) dokumentiert jedoch weiterhin Marktfragmentierung und Fachkräftelücken. Er weist für die EU nur 9 Prozent des weltweiten Halbleitermarkts aus und nennt zugleich erhebliche Abhängigkeiten von Nicht-EU-Anbietern bei Cloud, Cybersecurity und weiteren strategischen Technologien. Produktive europäische und offen entwickelte Bausteine existieren bereits; Integration in großem Maßstab, tragfähige Lieferketten und dauerhaft finanzierbarer Betrieb bleiben davon getrennte Aufgaben.

## Die Architektur: funktionale Bereiche statt starre Produktkombinationen

Die folgende Einteilung ist kein verpflichtender Produktkatalog und keine streng übereinanderliegende Schichtenarchitektur. Sie zeigt, welche Aufgaben eine betriebsfähige Plattform abdecken muss und an welchen Stellen Alternativen, Übergänge und Abhängigkeiten geplant werden sollten.

| Architekturbereich | Mögliche Technologien | Funktionale Aufgabe |
| --- | --- | --- |
| Physische Infrastruktur | Server; Prozessoren; Netzwerkhardware; Firmware; physischer Storage | Stellt Rechenleistung, Konnektivität und persistente Medien bereit und macht Lieferketten sichtbar. |
| Virtualisierung und Container | Proxmox VE; SUSE Virtualization; SUSE Rancher Prime; RKE2; K3s | Abstrahiert Compute-Ressourcen und betreibt virtuelle Maschinen sowie Container-Workloads. |
| Storage und Datenhaltung | Ceph; LINSTOR/DRBD; PostgreSQL; MariaDB | Speichert Block-, Datei-, Objekt- und Anwendungsdaten mit definierten Verfügbarkeits- und Konsistenzanforderungen. |
| Serverbetriebssysteme | SLES; openSUSE; Debian; Ubuntu | Stellt die Laufzeit für Dienste bereit und definiert Paket-, Update- und Supportpfade. |
| Plattformbetrieb | SUSE Multi-Linux Manager; ATIX orcharhino; Ansible; AWX; OpenTofu | Automatisiert Bereitstellung, Konfiguration, Lifecycle, Patchen und reproduzierbaren Betrieb. |
| Identität und Sicherheit | Keycloak; FreeIPA; Univention; OPNsense; IPFire | Steuert Identitäten, Rollen, Federation, Netzwerkregeln, Zertifikate und Notfallzugänge. |
| Datensicherung und Wiederherstellung | Proxmox Backup Server; Bareos; native Backup-Funktionen | Schützt VMs, Dateien und Anwendungen entsprechend Wiederanlauf-, Aufbewahrungs- und Konsistenzzielen. |
| Monitoring und Observability | Checkmk; Icinga; Zabbix; Grafana | Macht Zustand, Leistung, Ereignisse und Fehler über Plattformgrenzen hinweg nachvollziehbar. |
| Kommunikation und Collaboration | grommunio; Open-Xchange; Nextcloud; OpenProject; XWiki | Unterstützt Kommunikation, Dateien, Projekte und Wissensarbeit mit portierbaren Datenpfaden. |
| Digitaler Arbeitsplatz | SLED; openSUSE Desktop; Debian; Ubuntu; LibreOffice; Collabora Online | Stellt Endanwendern Betriebssystem, Office-Werkzeuge und kontrollierte Zugänge bereit. |

Identitätsmanagement, Sicherheit, Backup, Monitoring, Automatisierung und Lifecycle Management sind zugleich Querschnittsfunktionen. Sie wirken über mehrere Bereiche hinweg und dürfen in einer Visualisierung nicht wie isolierte Endpunkte erscheinen. Auch PKI, Secrets Management, DNS und CI/CD verlaufen quer durch die Architektur. Gerade diese unscheinbaren Abhängigkeiten entscheiden oft darüber, ob eine Migration planbar bleibt.

Weiterführende Einordnungen zu konkreten Bausteinen finden sich auf unseren Seiten zu [Proxmox VE](https://forgeone.solutions/de/produkte/proxmox-virtual-environment), [SUSE](https://forgeone.solutions/de/produkte/suse), [SUSE Multi-Linux Manager](https://forgeone.solutions/de/produkte/suse-multilinux-manager), [Bareos](https://forgeone.solutions/de/produkte/bareos), [Keycloak](https://forgeone.solutions/de/produkte/keycloak), [FreeIPA](https://forgeone.solutions/de/produkte/freeipa) und [Ansible](https://forgeone.solutions/de/produkte/ansible).

## Austauschbarkeit bedeutet mehr als die Verfügbarkeit einer Alternative

Für uns bei ForgeOne ist eine Technologie nicht bereits deshalb austauschbar, weil ein anderes Produkt mit vergleichbaren Funktionen existiert. Entscheidend ist, ob der Wechsel geplant, vorbereitet, getestet und mit vertretbarem Aufwand durchgeführt werden kann. Wir unterscheiden deshalb technische Austauschbarkeit und organisatorische Wechselbereitschaft.

### Technische Austauschbarkeit

- Dokumentierte Schnittstellen und offene Standards.
- Datenexport, Datenmigration und übertragbare Konfigurationen.
- Reproduzierbare, automatisierte Installation und Konfiguration.
- Dokumentierte Migrations- und Wiederherstellungsverfahren.
- Testbare Alternativplattformen und definierte Rückfallmöglichkeiten.
- Nachvollziehbare Abhängigkeiten zwischen Komponenten.

### Organisatorische Wechselbereitschaft

- Aktuelle technische Dokumentation und klare Verantwortlichkeiten.
- Verfügbare interne oder externe Kompetenzen und Supportleistungen.
- Vertragliche Ausstiegsmöglichkeiten und geregelter Datenzugang.
- Geeignete Test- und Migrationsumgebungen.
- Ausreichende zeitliche und personelle Ressourcen.
- Definierte Freigabe-, Abnahme- und Eskalationsprozesse.

Auch eine technisch offene Plattform kann faktisch zu einer Abhängigkeit werden, wenn niemand mehr weiß, wie sie aufgebaut ist, wie ihre Daten exportiert werden oder wie eine Alternative eingeführt werden kann.

„Eine Technologie ist für uns erst dann kontrolliert austauschbar, wenn nicht nur eine Alternative existiert, sondern auch ein dokumentierter und überprüfbarer Weg dorthin.“

Wird eine Virtualisierungsplattform ersetzt, können sich Backup, Netzwerk, Storage, Monitoring und Automatisierung mit verändern. Entscheidend ist nicht, ob jeder Produktname unverändert bleibt, sondern ob die erforderlichen Betriebsfunktionen weiterhin kontrolliert bereitgestellt werden.

Damit unterscheiden wir Produktaustausch und den Austausch eines funktionalen Plattformverbunds. Ein einzelnes Werkzeug lässt sich manchmal direkt ersetzen. In anderen Fällen wird ein Verbund aus Hypervisor, Backup-Ziel, Storage-Treiber und Betriebsprozess gemeinsam neu zusammengesetzt. Eine souveräne Architektur macht diesen Umfang sichtbar, bevor der Wechsel notwendig wird.

## Beispiel: von Proxmox VE zu SUSE Virtualization

### Ausgangssituation

Eine Organisation betreibt Proxmox VE als Hypervisor, Proxmox Backup Server für VM-Backups, Linux-basierte virtuelle Maschinen, zentrales Monitoring, automatisierte Konfigurationsverwaltung und ein zentrales Identitätsmanagement. Die Plattform ist produktiv; Aufbewahrung, Wiederherstellungsziele und Verantwortlichkeiten sind definiert.

### Neue Anforderung

Aus strategischen oder technischen Gründen soll die Virtualisierung künftig mit [SUSE Virtualization](https://forgeone.solutions/de/produkte/suse-virtualization) betrieben werden. Die Entscheidung soll möglich sein, ohne Anwendungen, Identitäten und sämtliche Betriebsprozesse grundsätzlich neu zu entwerfen. Das bedeutet jedoch nicht, dass jede Integration unverändert übernommen werden kann.

### Was sich tatsächlich ändert

Proxmox Backup Server ist direkt in Proxmox VE integriert und bietet dort VM- und Container-orientierte Sicherungsabläufe. Daraus folgt keine direkte Wiederherstellbarkeit bestehender PBS-Sicherungen in SUSE Virtualization. Die native Backup- und Restore-Funktion von SUSE Virtualization ist wiederum versions-, Storage- und konfigurationsabhängig. Die offizielle Dokumentation muss deshalb für die eingesetzte Version und das konkrete Backend geprüft werden.

Bareos kann ergänzend agenten- oder anwendungsbasierte Sicherungen innerhalb virtueller Maschinen übernehmen. Das macht Bareos nicht automatisch zum vollständigen Ersatz für alle PBS-Funktionen. VM-Snapshots, vollständige VM-Wiederherstellung, anwendungskonsistente Sicherung, Plattform-Disaster-Recovery sowie RPO und RTO müssen getrennt entworfen und getestet werden.

- Vollständige VM-Sicherungen und die Wiederherstellung kompletter virtueller Maschinen.
- Dateibasierte und anwendungskonsistente Sicherungen innerhalb der Gastsysteme.
- VM-Snapshots als kurzlebiger Betriebsmechanismus statt als alleinige Datensicherung.
- Bare-Metal- beziehungsweise Systemwiederherstellung und Wiederaufbau der gesamten Plattform.
- RPO, RTO, langfristige Aufbewahrung und Zugriff auf historische Backup-Bestände.

Die konkrete Backup-Architektur richtet sich deshalb nach unterstützten Funktionen, Storage-Technologien und Wiederherstellungsanforderungen. Wir erhalten beim Plattformwechsel die erforderlichen Betriebsfunktionen, nicht zwangsläufig dieselben Produkte.

## Zwei Plattformen, dieselben betrieblichen Anforderungen

Beim Wechsel der Virtualisierung können sich die eingesetzten Werkzeuge ändern. Entscheidend ist, dass die notwendigen Betriebsfunktionen erhalten bleiben.

### Proxmox VE

Proxmox VE betreibt die virtuellen Maschinen. Proxmox Backup Server übernimmt die nativ integrierte VM-Datensicherung und schreibt die Sicherungen auf einen geeigneten Backup-Storage.

- **Anwendungen und virtuelle Maschinen: Linux-basierte virtuelle Maschinen und Anwendungen** — Bleibt erhalten: Workloads bleiben fachlich erhalten, müssen aber auf der jeweiligen Plattform technisch validiert werden.

- **Virtualisierungsplattform: Proxmox VE** — Wird ersetzt: Hypervisor und VM-Verwaltung der Ausgangsarchitektur.

- **Native Backup-Funktionen: Proxmox Backup Server** — Wird ersetzt: Direkt in Proxmox VE integrierte Sicherung und Wiederherstellung virtueller Maschinen und Container.

- **Backup-Ziel: Geeigneter Backup-Storage** — Anpassen oder prüfen: Kapazität, Aufbewahrung, Trennung und Wiederherstellbarkeit müssen für die konkrete Umgebung geprüft werden.

#### Übergreifende Betriebsfunktionen

- **Zentrales Identity Management** — Bleibt erhalten: Die Funktion bleibt erhalten; Plattformanbindung und Notfallzugriff sind zu prüfen.

- **Monitoring und Alarmierung** — Anpassen oder prüfen: Service-Sicht bleibt erhalten, hypervisorspezifische Checks ändern sich.

- **Automatisierung mit Ansible** — Anpassen oder prüfen: Allgemeine Rollen bleiben nutzbar; Proxmox-spezifische Module werden angepasst.

- **Lifecycle Management** — Anpassen oder prüfen: Update-, Wartungs- und Freigabeprozesse bleiben erforderlich, ihre technische Umsetzung ist plattformspezifisch.

- **Dokumentation und Betriebsprozesse** — Bleibt erhalten: Verantwortlichkeiten und Abnahmeprinzipien bleiben erhalten und werden für die Plattform aktualisiert.

### SUSE Virtualization

SUSE Virtualization betreibt die virtuellen Maschinen und nutzt seine unterstützten nativen Backup- und Restore-Funktionen. Bareos kann geeignete Gast- und Anwendungssicherungen ergänzen, ersetzt Proxmox Backup Server aber nicht pauschal.

- **Anwendungen und virtuelle Maschinen: Linux-basierte virtuelle Maschinen und Anwendungen** — Bleibt erhalten: Workloads können fachlich erhalten bleiben, sofern Boot, Treiber, Netzwerk, Storage und Anwendungen erfolgreich validiert wurden.

- **Virtualisierungsplattform: SUSE Virtualization** — Wird ersetzt: Zielplattform für Hypervisor- und VM-Verwaltungsfunktionen.

- **Native Backup-Funktionen: Unterstützte native Backup- und Restore-Funktionen** — Anpassen oder prüfen: Unterstützung hängt von SUSE-Version, Volume-Technologie, Backup-Ziel und Konfiguration ab; vollständige VM-Restores sind praktisch zu testen.

- **Ergänzende Datensicherung: Bareos für Gast- und Anwendungssicherungen** — Anpassen oder prüfen: Ergänzt geeignete Datei-, Gast- und Anwendungssicherungen. Bareos ist in diesem Modell keine pauschale Eins-zu-eins-Alternative zu Proxmox Backup Server.

- **Backup-Ziel: Unterstützter NFS- oder S3-kompatibler Backup-Storage** — Anpassen oder prüfen: Die konkrete Unterstützung ist anhand der eingesetzten SUSE-Version und Storage-Konfiguration zu prüfen.

#### Übergreifende Betriebsfunktionen

- **Zentrales Identity Management** — Bleibt erhalten: Die Funktion bleibt erhalten; Plattformanbindung und Notfallzugriff sind erneut abzunehmen.

- **Monitoring und Alarmierung** — Anpassen oder prüfen: Service-Sicht bleibt erhalten; Proxmox-spezifische Checks werden durch passende SUSE- und Kubernetes-nahe Prüfungen ersetzt.

- **Automatisierung mit Ansible** — Anpassen oder prüfen: Allgemeine Gastrollen bleiben nutzbar; Provider- und Plattformtasks müssen angepasst werden.

- **Lifecycle Management** — Anpassen oder prüfen: Update-, Wartungs- und Freigabeprozesse werden an die Zielplattform angepasst.

- **Dokumentation und Betriebsprozesse** — Bleibt erhalten: Verantwortlichkeiten und Abnahmeprinzipien bleiben erhalten; technische Runbooks werden aktualisiert.

Die Darstellung zeigt beispielhafte Architekturvarianten. Ein Plattformwechsel erfordert eine gesonderte Prüfung von Workloads, Storage, Netzwerk, Backup, Wiederherstellung und Integrationen. Die gezeigten Kombinationen stellen keine pauschale Kompatibilitäts- oder Migrationsgarantie dar.

Versionshinweis zur dokumentierten Backup-Funktion: In der hier geprüften SUSE-Virtualization-Dokumentation für Version 1.8 ist die Backup-Unterstützung auf SUSE-Storage-Volumes begrenzt; Volumes auf externem Storage werden mit dieser Funktion nicht gesichert.

| Funktion | Proxmox-basierte Variante | SUSE-basierte Variante | Beim Wechsel |
| --- | --- | --- | --- |
| Virtualisierung | Proxmox VE | SUSE Virtualization | Compute, Netzwerk und Storage-Mappings neu abnehmen |
| Native VM-Sicherung | Proxmox Backup Server | Unterstützte native Backup-/Restore-Ziele | Aufbewahrung, Konsistenz und Full-VM-Restore neu validieren |
| Gast-/Anwendungssicherung | Optional Bareos oder anwendungseigene Verfahren | Optional Bareos oder anwendungseigene Verfahren | Kann bei stabilen Agenten- und Datenpfaden teilweise erhalten bleiben |
| Linux-Workloads | Virtuelle Maschinen | Virtuelle Maschinen | Treiber, Boot, Netzwerk, Zeit, Performance und Anwendung testen |
| Identity | Zentrale Identität | Zentrale Identität | Schnittstellen und Notfallzugriff prüfen, funktional möglichst erhalten |
| Monitoring | Plattform- und Gastchecks | Angepasste Plattform- und Gastchecks | Hypervisor-spezifische Checks ersetzen, Service-Sicht erhalten |
| Automatisierung | Proxmox-Module und allgemeine Rollen | SUSE-/Kubernetes-nahe Abläufe und allgemeine Rollen | Provider-spezifische Tasks anpassen, Rollen für Gäste weiterverwenden |
| Collaboration | Anwendungen oberhalb der VM-Schicht | Anwendungen oberhalb der VM-Schicht | Möglichst unverändert, aber vollständig fachlich testen |

Die Tabelle ist zugleich die textuelle Architekturvisualisierung: In beiden Varianten bleiben Linux-Workloads, zentrale Identität, Service-Monitoring, Automatisierungsprinzipien und Collaboration-Anwendungen als Funktionen bestehen. Ausgetauscht werden Virtualisierungs- und native Backup-Schicht; angepasst werden deren Integrationen. Ein automatisches Umschalten wird damit ausdrücklich nicht behauptet.

Beispielhafte Sicherungspfade: Proxmox VE → Proxmox Backup Server → Backup-Storage. In einer möglichen Zielarchitektur: SUSE Virtualization → unterstützte native VM-Backup-Funktionen → geeigneter Backup-Storage. Ergänzend: SUSE Virtualization → Gastbetriebssysteme und Anwendungen → Bareos → Backup-Storage.

Diese Darstellung ist ein Architekturbeispiel und keine vollständig getestete oder zertifizierte ForgeOne-Referenzimplementierung. Eine konkrete Umsetzung muss Version, Storage, Workloads, Konsistenzanforderungen und Restore-Ziele separat validieren.

## Herstellerabhängigkeit in der Praxis: VMware VDDK

Das VMware Virtual Disk Development Kit (VDDK) ist ein proprietäres SDK für den Zugriff auf virtuelle VMware-Datenträger. Red Hat empfiehlt ein daraus gebautes VDDK-Image für die Übertragung virtueller Festplatten mit dem Migration Toolkit for Virtualization (MTV); ohne VDDK können Übertragungen deutlich langsamer sein, und bei VMware-vSAN-gestützten virtuellen Maschinen funktioniert dieser MTV-Pfad laut [Dokumentation zu den VMware-Voraussetzungen](https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/2.9/html/installing_and_using_the_migration_toolkit_for_virtualization/prerequisites-per-provider_mtv) nicht.

Laut dem am 27. August 2026 aktualisierten Red-Hat-Hinweis waren frühere öffentliche Downloadpfade nicht mehr verfügbar. Weil Broadcom das proprietäre Paket besitzt und lizenziert, kann Red Hat das Image nicht selbst verteilen; zu diesem Stand musste der Zugang über den VMware-/Broadcom-Support angefordert werden. Für eine Migrationsplanung bedeutet das: VDDK-Zugang, Nutzungsbedingungen, passende Version und ein intern erreichbares Image müssen vor dem Zeitplan praktisch geprüft werden, statt sie als dauerhaft verfügbare Fremdkomponente vorauszusetzen. Der [Red-Hat-Hinweis zur VDDK-Verfügbarkeit](https://access.redhat.com/solutions/7146995) beschreibt genau diese Abhängigkeit.

Das macht VMware-Migrationen nicht allgemein unmöglich. MTV kann in bestimmten Konstellationen ohne vSAN auch ohne VDDK arbeiten, allerdings mit möglichen Leistungseinbußen. Red Hat nennt außerdem Storage Copy Offload/XCopy als möglichen Ausweg, wenn das Storage-Backend dies unterstützt. Ob dieser oder ein anderer Export-, Konvertierungs- oder Neuaufbaupfad geeignet ist, hängt von Storage, Workloads, Ausfallfenster und Rückfallanforderungen ab und muss im Lab validiert werden.

## Ein kontrollierter Migrationspfad

1. Bestehende Plattform, Abhängigkeiten, Datenpfade und Wiederherstellungsziele dokumentieren.
2. Zielplattform, Storage-Backend und benötigte Begleitwerkzeuge anhand der realen Anforderungen auswählen.
3. Neue Infrastruktur parallel und getrennt von der produktiven Umgebung aufbauen.
4. Backup-, Restore- und Disaster-Recovery-Verfahren vor der ersten produktiven Migration implementieren.
5. Repräsentative Test-VMs einschließlich zustandsbehafteter Anwendungen migrieren.
6. Datenintegrität, Boot, Netzwerk, DNS, Zeit, Performance, Berechtigungen und Anwendungspfade prüfen.
7. Monitoring, Alarmierung, Automatisierung, Inventar und Dokumentation anpassen.
8. Produktive Workloads in kontrollierten Wellen mit Abbruchkriterien migrieren.
9. Wiederherstellung und Rückfall praktisch testen; Ergebnisse und Restabweichungen dokumentieren.
10. Die alte Plattform erst nach fachlicher und technischer Abnahme außer Betrieb nehmen.

Historische PBS-Sicherungen können während einer Übergangsphase weiterhin für Wiederherstellungen auf oder über die bisherige Proxmox-Umgebung benötigt werden. Aufbewahrungsfristen, die Verfügbarkeit der alten Plattform und ein dokumentierter Lesepfad gehören daher in den Migrationsplan.

## Austauschbarkeit ist eine Eigenschaft der Architektur

### Offene Standards und dokumentierte APIs

OIDC, SAML, LDAP und andere etablierte Protokolle können Kopplungen reduzieren, wenn sie für den jeweiligen Zweck geeignet und sauber implementiert sind. Ein Standard auf dem Datenblatt genügt nicht: Claims, Gruppenabbildung, Zertifikate, Fehlerverhalten und Logout-Pfade müssen dokumentiert und getestet sein.

### Datenportabilität

Export- und Importmöglichkeiten müssen die tatsächlich benötigten Daten, Metadaten, Rechte, Historien und Anhänge umfassen. Ein vorhandener Exportknopf ist noch keine verifizierte Datenübernahme. Testimporte und Prüfsummen liefern einen belastbareren Nachweis.

### Automatisierung und Trennung

Versionierte Infrastruktur- und Konfigurationsquellen machen Zustände reproduzierbar. Gleichzeitig sollten Hypervisor, Backup, Identity und Anwendungsschicht nicht unnötig vermischt werden. [Git-basierte Ansible-Automatisierung](https://forgeone.solutions/de/produkte/ansible) hilft besonders dann, wenn allgemeine Rollen von plattformspezifischen Modulen getrennt bleiben.

### Dokumentation, Validierung und Exit

Abhängigkeiten, Schnittstellen, Credentials-Pfade, Restore-Verfahren und Eigentümerschaft müssen verständlich dokumentiert sein. Alternative Plattformen und Wiederherstellungen gehören regelmäßig ins Lab. Bereits bei der Einführung sollte feststehen, wie Daten exportiert werden, welche Komponenten ersetzt werden müssten und wie lange notwendige Altzugriffe erhalten bleiben. Offene Standards verbessern die Ausgangslage, garantieren aber keine vollständige Austauschbarkeit.

## Zeitliche Zielsetzung ohne falsche Versprechen

Technologiewechsel sollen mit ausreichender Vorbereitung in überschaubaren und planbaren Zeiträumen realisierbar bleiben. Eine pauschale Zusage für wenige Tage wäre unseriös. Anzahl und Kritikalität der Systeme, Datenvolumen, Anwendungskopplungen, Schnittstellen, Verfügbarkeitsanforderungen, Compliance, verfügbare Fachkräfte und Testumfang bestimmen den Aufwand.

Der Architekturgewinn liegt darin, dass Alternativen und Abhängigkeiten schon bei der Einführung dokumentiert, Automatisierung wiederverwendbar gehalten und Migrationen im Lab erprobt werden. Dadurch muss ein Wechsel nicht automatisch zu einem monatelangen Grundsatzprojekt werden. Produktive Wechsel benötigen trotzdem eine eigene Risiko-, Ressourcen- und Zeitplanung sowie eine fachliche und technische Abnahme.

## Wo Europa bereits gut aufgestellt ist

| Bereich | Einordnung | Beispiele und Grenze |
| --- | --- | --- |
| Virtualisierung | Europäische Optionen vorhanden | Proxmox VE und SUSE Virtualization verfolgen unterschiedliche Architekturmodelle; Migration bleibt projektspezifisch. |
| Backup | Europäische Optionen vorhanden | PBS und Bareos decken unterschiedliche Sicherungsebenen ab; native Plattformfunktionen sind separat zu prüfen. |
| Linux und Lifecycle | Europäische Anbieter plus globale Communities | SLES/openSUSE und SUSE Multi-Linux Manager; Debian/Ubuntu und orcharhino als weitere Bausteine mit eigener Governance. |
| Identity | Europäische Produkte plus internationale Projekte | Univention als europäischer Anbieter; FreeIPA und Keycloak als international entwickelte Open-Source-Projekte. |
| E-Mail, Groupware und Collaboration | Mehrere europäische Anbieter | grommunio, Open-Xchange, Nextcloud, OpenProject und XWiki; Funktionsumfang und Migrationspfade unterscheiden sich. |
| Office und Desktop | Offene und europäische Bausteine verfügbar | LibreOffice, Collabora Online, SLED und openSUSE; Makros und Fachanwendungen bleiben mögliche Blocker. |
| Netzwerk, Security und Monitoring | Mehrere europäische Optionen | OPNsense, IPFire, Checkmk, Icinga und Zabbix; Hardware und Spezialintegrationen gesondert bewerten. |
| Automatisierung und Container | Globale Open-Source-Ökosysteme verfügbar | Ansible, AWX, OpenTofu, Kubernetes, RKE2 und K3s ermöglichen Eigenbetrieb, sind aber nicht sämtlich europäische Ursprungsprodukte. |
| Storage | Europäische und globale Open-Source-Optionen | LINSTOR/DRBD, SUSE Storage und Ceph; Design, Hardware und Betriebswissen bleiben entscheidend. |
| Hardware und Firmware | Weiterhin wesentliche Abhängigkeiten | CPU, Fertigung, Komponenten und Firmware lassen sich nicht allein durch Softwarearchitektur europäisieren. |

## Grenzen eines europäischen IT-Stacks

- Integration: Standardisierte Schnittstellen erleichtern die Verbindung produktiv verfügbarer Komponenten. Einheitliche Upgrades, Fehlerbilder und Ende-zu-Ende-Support entstehen daraus jedoch nicht automatisch.
- Betrieb: Ein modularer Stack verlangt zusätzliche Integrations-, Kompatibilitäts- und Wiederherstellungstests. Auch Proxmox, SUSE und offene Projekte müssen nach denselben Kriterien für Lifecycle, Monitoring und Support bewertet werden.
- Funktionsumfang: Eng integrierte Plattformfunktionen, proprietäre Fachanwendungen, Spezialhardware und historisch gewachsene Automatisierung lassen sich nicht immer eins zu eins ersetzen.
- Lieferketten: Abhängigkeiten bei Prozessoren, Fertigung, Firmware, Netzwerkkomponenten, Bibliotheken, Drittanbietern und einzelnen Cloud-Diensten bleiben bestehen.
- Wirtschaftlichkeit: Eine Migration kann technisch möglich und trotzdem unverhältnismäßig sein, wenn Anpassung, Parallelbetrieb, Tests und Schulung mehr kosten als das vermiedene Risiko.
- Kompetenz und Verantwortung: Fachkräfte, belastbare Dokumentation, Hersteller- oder Community-Support und klare Eskalationswege bestimmen, ob Eigenbetrieb tatsächlich mehr Kontrolle schafft.

Eine belastbare Entscheidung vergleicht deshalb nicht nur Lizenzkosten oder Herkunft. Sie bewertet technische Abhängigkeiten, Betriebsaufwand, Ausfallrisiko, Exit-Kosten und verfügbare Kompetenzen über den geplanten Lebenszyklus. Digitale Souveränität ist dabei kein erreichter Endzustand, sondern die nachweisbare Fähigkeit, Entscheidungen und Wechsel unter realistischen Bedingungen selbst zu steuern.

## Unsere Position bei ForgeOne

Wir glauben nicht, dass Europa sämtliche IT-Technologien neu entwickeln muss. Viele geeignete Produkte und Open-Source-Projekte existieren bereits. Entscheidend ist, sie sinnvoll zu kombinieren, ihre Grenzen zu verstehen und eine Architektur aufzubauen, die langfristig anpassbar bleibt.

Wir möchten keine neue geschlossene Plattform schaffen. Unser Ansatz ist eine offene, modulare Infrastruktur, bei der einzelne Technologien und bei Bedarf ganze funktionale Plattformverbünde kontrolliert ausgetauscht werden können. Technologien sind für uns Werkzeuge, keine unumkehrbaren Entscheidungen.

Das gilt auch oberhalb der Infrastruktur: [grommunio](https://forgeone.solutions/de/produkte/grommunio), [Nextcloud](https://forgeone.solutions/de/produkte/nextcloud), [OpenProject](https://forgeone.solutions/de/produkte/openproject) und [XWiki](https://forgeone.solutions/de/produkte/xwiki) können je nach Anforderungen unterschiedliche Aufgaben im digitalen Arbeitsplatz übernehmen. Souverän wird daraus erst ein System mit dokumentierten Datenpfaden, Identitäten, Backups, Updates und Exit-Optionen.

## Häufige Fragen zum europäischen IT-Stack

### Was gehört zu einem europäischen IT-Stack?

Ein europäischer IT-Stack kann Virtualisierung, Betriebssysteme, Storage, Backup, Identitätsmanagement, Netzwerk, Security, Automatisierung und Anwendungen umfassen. Dabei muss zwischen europäischen Herstellern und international entwickelten Open-Source-Technologien unterschieden werden.

### Kann eine IT-Infrastruktur vollständig digital souverän sein?

Vollständige Unabhängigkeit von sämtlichen internationalen Technologien und Lieferketten ist derzeit schwer realisierbar. Digitale Souveränität lässt sich jedoch durch kontrollierten Eigenbetrieb, offene Standards, dokumentierte Abhängigkeiten und überprüfbare Wechselmöglichkeiten erheblich stärken.

### Wie lassen sich Herstellerabhängigkeiten reduzieren?

Durch offene Schnittstellen, portable Daten, reproduzierbare Konfigurationen, dokumentierte Betriebsprozesse und getestete Exit-Strategien. Entscheidend ist nicht nur die Existenz einer Alternative, sondern auch die praktische Fähigkeit, diese einzuführen.

### Ist ein Wechsel von Proxmox VE zu SUSE Virtualization ohne Datenverlust möglich?

Ein solcher Wechsel kann mit geeigneten Migrationsverfahren geplant werden. Ob er ohne Datenverlust gelingt, hängt jedoch von den Workloads, den eingesetzten Verfahren, der Konsistenz der Daten und der erfolgreichen Validierung ab. Ein verlustfreier Wechsel darf nicht pauschal garantiert werden. Backup-, Restore- und Rückfallverfahren müssen vor der produktiven Migration geprüft werden.

## Fazit

Ein vollständig europäischer IT-Stack ohne internationale Abhängigkeiten ist heute nur eingeschränkt realisierbar. Für klar abgegrenzte Anforderungen kann bereits heute ein weitgehend europäischer und Open-Source-basierter Stack aufgebaut werden. Ob er souverän betreibbar ist, muss die konkrete Organisation durch getestete Betriebs-, Wiederherstellungs- und Exit-Verfahren nachweisen.

Die eigentliche Herausforderung besteht nicht darin, für jede proprietäre Anwendung einen europäischen Produktnamen zu finden. Sie besteht darin, Komponenten so zu verbinden, dass Organisationen die Kontrolle über Infrastruktur, Daten und Veränderungen behalten.

Für uns ist eine IT-Architektur dann wirklich souverän, wenn wir nicht nur entscheiden können, welche Technologie wir heute einsetzen, sondern auch, welche wir morgen wieder ersetzen.

Eine breitere Einordnung unseres Ansatzes bietet die Seite [Digitale Souveränität](https://forgeone.solutions/de/digitale-souveraenitaet); Anforderungen an Datensicherung und Wiederanlauf vertieft der Bereich [Backup und Data Protection](https://forgeone.solutions/de/produkte/backup-data-protection).

## Titelbild

[![Modulare IT-Architektur mit zwei austauschbaren Infrastruktur-Stacks und kontrolliertem Migrationspfad.](https://forgeone.solutions/media/inside-forgeone-europaeischer-it-stack-austauschbare-architektur.webp)](https://forgeone.solutions/media/inside-forgeone-europaeischer-it-stack-austauschbare-architektur.webp)

## Autor

Mathias Rumbold

## Kategorie

- [Inside ForgeOne](https://forgeone.solutions/de/inside-forgeone/europaeischer-it-stack-austauschbare-architektur?category=inside-forgeone)

## Tags

- [Inside ForgeOne](https://forgeone.solutions/de/inside-forgeone/europaeischer-it-stack-austauschbare-architektur?tags=inside-forgeone)
- [Digitale Souveränität](https://forgeone.solutions/de/inside-forgeone/europaeischer-it-stack-austauschbare-architektur?tags=digitale-souveraenitaet)
- [Open Source](https://forgeone.solutions/de/inside-forgeone/europaeischer-it-stack-austauschbare-architektur?tags=open-source)
- [Vendor Lock-in](https://forgeone.solutions/de/inside-forgeone/europaeischer-it-stack-austauschbare-architektur?tags=vendor-lock-in)
- [Europäische Technologiesouveränität](https://forgeone.solutions/de/inside-forgeone/europaeischer-it-stack-austauschbare-architektur?tags=european-tech-sovereignty)
- [Backup](https://forgeone.solutions/de/inside-forgeone/europaeischer-it-stack-austauschbare-architektur?tags=backup)
- [Automation](https://forgeone.solutions/de/inside-forgeone/europaeischer-it-stack-austauschbare-architektur?tags=automation)
- [Linux](https://forgeone.solutions/de/inside-forgeone/europaeischer-it-stack-austauschbare-architektur?tags=linux)
- [Migration](https://forgeone.solutions/de/inside-forgeone/europaeischer-it-stack-austauschbare-architektur?tags=migration)

## Links und Quellen

- [Proxmox VE Administrationshandbuch](https://pve.proxmox.com/pve-docs/pve-admin-guide.html)
- [Proxmox: Unternehmensangaben und Media Kit](https://www.proxmox.com/en/about/company-details/media-kit)
- [SUSE Virtualization: Backup und Wiederherstellung](https://documentation.suse.com/cloudnative/virtualization/latest/en/virtual-machines/backup-restore.html)
- [SUSE: Kontakt und Unternehmenssitz](https://www.suse.com/contact/)
- [SUSE: Digitale Souveränität und europäische Struktur](https://www.suse.com/c/championing-digital-sovereignty-in-europe/)
- [Bareos-Dokumentation](https://docs.bareos.org/)
- [Bareos: Open-Source-Datensicherung](https://www.bareos.com/en/)
- [Univention: Über uns](https://www.univention.com/about-us/)
- [Nextcloud: Über uns](https://nextcloud.com/about/)
- [OpenProject: Impressum](https://www.openproject.org/legal/imprint/)
- [XWiki: Wer wir sind](https://xwiki.com/en/company/who-we-are/)
- [Keycloak-Dokumentation](https://www.keycloak.org/documentation)
- [Ansible Community-Dokumentation](https://docs.ansible.com/ansible/latest/index.html)
- [ATIX: orcharhino](https://atix.de/en/services/products/orcharhino/)
- [EuroStack: Europas digitale Zukunft gestalten](https://eurostack.eu/)
- [EuroStack: Initiative und Entstehung](https://eurostack.eu/who-we-are/)
- [Europäische Kommission: Technologiesouveränität und Open-Source-Strategie](https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy)
- [Europäische Kommission: Bericht zur digitalen Dekade 2026](https://digital-strategy.ec.europa.eu/en/policies/2026-state-digital-decade-package)
- [Red Hat: Verfügbarkeit von VMware-VDDK-Images für MTV](https://access.redhat.com/solutions/7146995)
- [Red Hat: VMware- und VDDK-Voraussetzungen für MTV 2.9](https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/2.9/html/installing_and_using_the_migration_toolkit_for_virtualization/prerequisites-per-provider_mtv)

## Digitale Souveränität beginnt mit der eigenen Infrastruktur

Welche Abhängigkeiten bestehen in Ihrer IT-Landschaft? ForgeOne unterstützt Unternehmen und öffentliche Einrichtungen dabei, Open-Source-Alternativen zu bewerten und langfristig betreibbare Architekturen mit nachvollziehbaren Migrations- und Exit-Strategien zu entwickeln.

[IT-Projekt mit ForgeOne besprechen](https://book.forgeone.solutions/de/book/forgeone/sales)

## Weiterführende Inhalte

- [Open Source und Enterprise ist kein Widerspruch](https://forgeone.solutions/de/inside-forgeone/open-source-und-enterprise-ist-kein-widerspruch)
- [Wann ist ein System produktionsreif?](https://forgeone.solutions/de/inside-forgeone/wann-ist-ein-system-produktionsreif)
- [Digitale Souveränität beginnt beim Fundament](https://forgeone.solutions/de/news/digitale-souveraenitaet-austausch-bundeskanzleramt)