--- title: "Heterogene Datensicherung: So schützen Sie gemischte IT-Umgebungen, ohne Wiederherstellungslücken zu verursachen" published_at: "2026-10-02T13:21:04+00:00" modified_at: "2026-10-02T13:29:14+00:00" url: "https://www.baculasystems.com/de/blogs/heterogene-datensicherung/" markdown_url: "https://www.baculasystems.com/de/blogs/heterogene-datensicherung.md" --- [Home](https://www.baculasystems.com/de/) > [Backup- und Wiederherstellungs-Blog](https://www.baculasystems.com/de/blogs/) > Heterogene Datensicherung: So schützen Sie gemischte IT-Umgebungen, ohne Wiederherstellungslücken zu verursachen # Heterogene Datensicherung: So schützen Sie gemischte IT-Umgebungen, ohne Wiederherstellungslücken zu verursachen Aktualisiert 2nd Oktober 2026, Rob Morrison ## Was ist heterogenes Backup? Heterogenes Backup ist eine Strategie, die verschiedene Arten von Workloads – darunter physische Server, virtuelle Maschinen, Datenbanken, Kubernetes, SaaS-Anwendungen und Cloud-Workloads – unter gemeinsamen Wiederherstellungsrichtlinien schützt. Gemeinsame Wiederherstellungsziele erfordern keine identischen Backup-Methoden. Ein erfolgreiches Backup garantiert keine erfolgreiche Wiederherstellung. Heterogenes Backup schützt verschiedene Workload-Typen unter gemeinsamen Wiederherstellungszielen. Viele IT-Umgebungen in Unternehmen kombinieren mehrere Betriebssysteme, Hypervisoren, Datenbanken, Cloud-Dienste und Legacy-Plattformen. Konkret kann man auf Unternehmen stoßen, die ihre Abläufe auf Windows- und Linux-Servern betreiben und virtuelle Maschinen von VMware und Hyper-V nutzen. Zudem nutzen diese Unternehmen möglicherweise gleichzeitig Kubernetes-Cluster, Workloads in der Public Cloud, Software-as-a-Service-Anwendungen (SaaS), Datenbanken, netzwerkgebundene Speichersysteme sowie ältere physische oder Unix-Plattformen wie IBM System z-Mainframes (z/OS) und IBM AIX auf Power Systems (oder Oracle Solaris / HP-UX). Gemischte Umgebungen können durch Übernahmen, Cloud-Migrationen, Anwendungsmodernisierung, die Beibehaltung von Altsystemen und dezentralen Technologiekäufen entstehen. Das Problem bei der Datensicherung besteht daher darin, wie man eine zuverlässige Wiederherstellung über Systeme hinweg gewährleistet, die mit unterschiedlichen Anwendungsprogrammierschnittstellen (APIs), Konsistenzmechanismen, Identitäten, Metadaten und Ausfallmodi verbunden sind. Eine API stellt Regeln dar, die es zwei Softwarekomponenten ermöglichen, auf der Grundlage einer Reihe von Definitionen und Protokollen miteinander zu kommunizieren. Eine **heterogene Backup-Strategie** nutzt eine koordinierte Datensicherungsarchitektur, um mehrere Betriebssysteme, Anwendungen, Datenbanken, Hypervisoren, Speicherplattformen und Cloud-Umgebungen zu schützen. Die heterogene Backup-Strategie zielt darauf ab, gemeinsame Wiederherstellungsziele festzulegen, wie beispielsweise [Recovery Point Objectives (RPOs)](https://blog.bcm-institute.org/it-disaster-recovery/recovery-time-and-point-objectives) , [Recovery Time Objectives (RTOs)](https://docs.oracle.com/en-us/iaas/mysql-database/doc/recovery-time-objective-rto-and-recovery-point-objective-rpo.html) , Aufbewahrungsfristen, Unveränderlichkeit, Zugriffskontrolle und Tests. Wiederherstellungstests sind Teil des Backup-Designs. Das RPO ist der maximal akzeptable Datenverlust, den ein Unternehmen tolerieren kann, bevor der Geschäftsbetrieb beeinträchtigt wird. Das RTO ist der maximale Zeitraum, in dem ein Unternehmen ohne Betrieb auskommen kann, bevor die Unterbrechung inakzeptable Auswirkungen hat. Datenbanken, VMs und Kubernetes-Anwendungen können ein gemeinsames RPO nutzen, während sie unterschiedliche Schutzmechanismen einsetzen. Es ist unerlässlich, die Wiederherstellungsziele zu standardisieren, anstatt jede Workload in denselben Backup-Prozess zu zwängen. Gleichzeitig trägt die Strategie dazu bei, die workloadspezifischen Methoden – wie beispielsweise für Datenbank-Workloads und virtuelle Maschinen – beizubehalten, die zur Erreichung dieser Ziele erforderlich sind. Wichtig ist: Wenn alle Jobs auf einem Dashboard grün angezeigt werden, bedeutet dies nicht, dass ein Unternehmen seine Anwendungen wiederherstellen kann. Ein effektives heterogenes Backup standardisiert Richtlinien und Nachweise unter Berücksichtigung technischer Unterschiede, wie beispielsweise anwendungskonsistente Datenbank-Backups mit Transaktionsprotokollen für die Point-in-Time-Wiederherstellung und Image-Backups auf Hypervisor-Ebene für die vollständige Wiederherstellung virtueller Maschinen. ## Was macht eine Backup-Umgebung heterogen? Eine Backup-Umgebung ist heterogen, wenn ihre Workloads unterschiedliche Backup- oder Wiederherstellungsmethoden erfordern und unterschiedlichen Wiederherstellungsmethoden unterliegen. Gemischte IT-Umgebungen erfordern workloadspezifische Backup-Methoden. Eine gemischte Umgebung kann Folgendes umfassen: - macOS, Unix-Server, Linux, physische Windows-Systeme - Proxmox-Virtualisierungsmaschinen, VMware, Nutanix, Hyper-V, kernelbasierte Virtualisierungsmaschinen - Persistente Volumes, Kubernetes-Cluster, Manifeste, Secrets und Anwendungsmetadaten - Datenbanken (z. B. Microsoft SQL Server, Oracle, PostgreSQL, MySQL, SAP HANA, MongoDB) - Beispielsweise NAS-Geräte und Dateisysteme - Beispielsweise Private Clouds und weniger verbreitete oder technisch anspruchsvolle Workloads - Beispielsweise Salesforce und Microsoft 365 - Mainframes, proprietäre Anwendungen oder Systeme, die keinen modernen Agenten unterstützen Die Infrastruktur stellt eine Ebene dar. Es gelten unterschiedliche Wiederherstellungsanforderungen. Bei einer transaktionalen Datenbank kann es zu Datenverlusten kommen. Bei einem Archiv ist jedoch ein [Recovery Point Objective (RPO)](https://csrc.nist.gov/glossary/term/rpo) von 24 Stunden zulässig. Das RPO stellt den Zeitpunkt dar, bis zu dem Daten nach einem Ausfall wiederhergestellt werden müssen. Für [Fertigungssysteme](https://www.baculasystems.com/de/cybersicherheit-in-der-industrie/) , die während WAN-Ausfällen weiterlaufen müssen, ist möglicherweise eine lokale Wiederherstellungsinfrastruktur erforderlich, selbst wenn das [Weitverkehrsnetz (WAN)](https://aws.amazon.com/what-is/wan/) nicht verfügbar ist. Ein Weitverkehrsnetz ist die Technologie, die Ihre Niederlassungen, Rechenzentren, Cloud-Anwendungen und Cloud-Speicher miteinander verbindet. Aufbewahrungsfristen hängen von der jeweiligen Rechtsordnung, der Art der Unterlagen, dem Vertrag und den gesetzlichen Vorschriften ab. Und für eine kurzlebige Entwicklungsumgebung sind möglicherweise nur wenige Wiederherstellungspunkte erforderlich. Deshalb ist „unterstützt viele Plattformen“ eine unvollständige Definition für heterogene Datensicherung. Eine Plattform kann Daten aus vielen Quellen aufnehmen. Eine anwendungskonsistente Wiederherstellung ist nicht bei allen Quellen üblich. Das Gleiche gilt auch für getestete plattformübergreifende Wiederherstellung, Konfigurationswiederherstellung oder granulare Wiederherstellung. ## Warum benötigen unterschiedliche Workloads unterschiedliche Sicherungsmethoden? Unterschiedliche Workloads erfordern unterschiedliche Backup-Mechanismen, da sie auf unterschiedliche Weise einen wiederherstellbaren Zustand erreichen. Es ist sinnvoll, verschiedene Workloads zu standardisieren, doch mit einer strikten Vereinheitlichung sind versteckte Risiken verbunden. Workload-Klassen erreichen einen wiederherstellbaren Zustand auf verschiedene Weise. Ein Hypervisor-Snapshot kann die Grundlage für ein VM-Backup bilden, wenn das Backup-Produkt auch die Konfiguration und den erforderlichen Anwendungszustand erfasst. Für eine Datenbank sind möglicherweise eine native Backup-API, Transaktionsprotokolle und die Koordination der Protokollverkürzung erforderlich. Eine Kubernetes-Anwendung benötigt möglicherweise persistente Daten und Manifeste, benutzerdefinierte Ressourcen, Secrets und Informationen zu Abhängigkeiten. Eine Software-as-a-Service-Plattform (SaaS) stellt nur die Objekte und [Anwendungsprogrammierschnittstellen (APIs)](https://www.ibm.com/think/topics/api) bereit, die ihr Anbieter zulässt. Eine API repräsentiert Regeln und Protokolle, die es verschiedenen Softwareprogrammen ermöglichen, miteinander zu kommunizieren. Für einen physischen Server sind möglicherweise Dateien, der Systemzustand und Daten für die Bare-Metal-Wiederherstellung erforderlich. Workloads mit einem täglichen Snapshot und einer Aufbewahrungsrichtlinie von 30 Tagen weisen eine konsistente Konfiguration auf. Sie sind jedoch nicht zwangsläufig wiederherstellbar. Das System kann seinen Betrieb ohne externe Abhängigkeiten fortsetzen, wie z. B. Kubernetes-Anwendungsabhängigkeiten sowie Identitätskonfigurationen und Verschlüsselungsschlüssel. Dies bezieht sich auch auf Identitätskonfigurationen oder cloud-native Metadaten. Darüber hinaus kann das System möglicherweise nicht in einer anderen Region, einem anderen Cluster, auf einem anderen Hypervisor oder in einem anderen Konto wiederhergestellt werden. Workloads derselben Geschäftsstufe sollten das gleiche beabsichtigte Ergebnis erzielen, auch wenn sie unterschiedliche Sicherungsmechanismen aufweisen. Beispielsweise könnte eine Tier-1-Richtlinie Folgendes erfordern (Tier 1 ist eine veranschaulichende Klassifizierung, keine universelle Branchendefinition): - Max. 15 Minuten Datenverlust - Wiederherstellung des Dienstes innerhalb von zwei Stunden - Eine unveränderliche Kopie, die sich nicht innerhalb der Sicherheitsgrenzen der Produktion befindet - Vierteljährlich durchzuführende Wiederherstellungstests - Nachweis, dass die Wiederherstellung von Anwendungsabhängigkeiten korrekt erfolgt. Zu diesen Abhängigkeiten können Abhängigkeiten hinsichtlich der Wiederherstellungsreihenfolge sowie vorgelagerte Infrastruktur- und Sicherheitsdienste gehören. Eine Oracle-Datenbank oder eine Kubernetes-Anwendung kann unterschiedliche Tools oder Plug-ins verwenden, um diese Richtlinie einzuhalten. Zu diesen Tools oder Plug-ins können der Oracle Recovery Manager und das Dell PowerProtect Data Manager-Plug-in gehören. Die Steuerung folgt einem standardisierten Ablauf. Die Implementierung ist für die jeweilige Workload optimiert. ## Wie sollten Teams Workloads der richtigen Schutzmethode zuordnen? Ein heterogenes Backup-Konzept sollte auf einem auf die Wiederherstellung ausgerichteten Bestandsverzeichnis basieren und nicht auf einer Liste von Geräten. In der Regel erfassen Infrastrukturbestandsverzeichnisse Hosts und Speicherkapazität, ohne die Elemente eines vollständigen Geschäftsdienstes darzustellen. Beginnen Sie damit, die Anwendungen ihren Abhängigkeiten in Bezug auf Rechenleistung, Daten, Konfiguration, Identität, Netzwerk, Zertifikate und externe Dienste zuzuordnen, wie z. B. Zahlungsgateways/APIs von Drittanbietern und extern verwaltete Datenbanken oder SaaS-Identitätsanbieter. Klassifizieren Sie sie anschließend unter Berücksichtigung ihrer geschäftlichen Auswirkungen. Definieren Sie schließlich ihr Recovery Point Objective (RPO) und ihr Recovery Time Objective (RTO) sowie die Aufbewahrungsdauer. Definieren Sie außerdem die rechtlichen Anforderungen, wie z. B. Gesetze zur Datenhoheit und zum Datenaufbewahrungsort (z. B. die Datenschutz-Grundverordnung) sowie verbindliche Aufbewahrungsstandards (z. B. [Health Insurance Portability and Accountability Act](https://www.hhs.gov/hipaa/index.html) ), den Wiederherstellungsort und den verantwortlichen Eigentümer. Die [DSGVO](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en) ist das europäische Datenschutz- und Sicherheitsgesetz. Der [HIPAA](https://www.hhs.gov/hipaa/for-professionals/faq/does-hipaa-require-covered-entities-to-keep-medical-records-for-any-period/index.html) legt strenge Standards für die Verwaltung, Übertragung und Speicherung geschützter Gesundheitsdaten fest. Verwenden Sie diese Tabelle als Ausgangspunkt: | Workload-Typ | Zu schützende Objekte | Bevorzugte Konsistenzmethode | Überprüfung der Wiederherstellung | | --- | --- | --- | --- | | Physischer Server | Systemzustand, Dateien, Startdaten, Anwendungsdaten | Agent- und Anwendungsintegration | Bare-Metal- oder Alternate-Hardware-Boot-Test | | Virtuelle Maschine | Konfiguration, VM-Festplatten, Anwendungsstatus | Hypervisor-Snapshot plus Anwendungs-Quiescing | Start einer isolierten VM und Diensttest | | Datenbank | Protokolle, Datendateien, Konfiguration, Verschlüsselungsmaterial | Datenbank-native API oder zertifiziertes Plug-in | Wiederherstellung, Rollforward und Datenbankintegritätsprüfung | | Kubernetes-Anwendung | Cluster-/Anwendungsmetadaten und persistente Volumes | Anwendungs-Hooks, CSI-Snapshots (Container Storage Interface) und Kubernetes-kompatible Erkennung | Verwenden Sie einen sauberen Namespace oder Cluster für die Wiederherstellung und das Testen von Abhängigkeiten | | Netzwerkspeicher (NAS) oder Dateiplattform | Berechtigungen, Freigaben, Zugriffskontrolllisten (ACLs) und Dateimetadaten | Sicherung auf Dateiebene oder Snapshot-/API-Integration | Test zur Wiederherstellung von Berechtigungen, Dateien und großen Verzeichnissen | | Modernisierter Cloud-Dienst | Konfiguration der Identitäts- und Zugriffsverwaltung (IAM), Dienstdaten, Identitäten und Referenzen sowie Region-/Kontokontext | Anbieter-API sowie unabhängige Kopie, sofern unterstützt | Wiederherstellung in ein zugelassenes Konto oder eine zugelassene Region | | SaaS-Anwendung | Berechtigungen, Objekte, Anhänge und Beziehungen, die über die API verfügbar sind | SaaS-spezifischer Konnektor | Granulare Objektwiederherstellung und Überprüfung der Beziehungen | Wichtig ist, dass nicht alle Abhängigkeiten Backup-Objekte sind. Die folgenden Punkte, die im Wiederherstellungsplan enthalten sind, erfordern möglicherweise separate Schutz- oder Wiederherstellungsverfahren: - DNS-Einträge (Domain Name System), wie z. B. A- oder AAAA-Einträge und kanonische Namenseinträge - Infrastructure-as-Code-Repositorys, z. B. GitLab-/GitHub-Repositorys (die Terraform- oder Pulumi-Skripte enthalten) und Amazon Web Services CloudFormation-Vorlagen-Repositorys - Konfiguration von Identitätsanbietern - Container-Images - Lizenzserver, wie z. B. FlexNet Publisher (FlexLM) und Microsoft Key Management Services (KMS)-Server - API-Anmeldedaten von Drittanbietern, wie z. B. OAuth-Client-Secrets/Refresh-Token und API-Schlüssel für Zahlungsgateways ## Ein schrittweiser Prozess zur Gestaltung heterogener Backups ### 1. Workloads ermitteln und Verantwortlichkeiten zuweisen Kombinieren Sie automatisierte Erfassung mit Befragungen der Anwendungsverantwortlichen, beispielsweise durch Infrastruktur-Erfassungsscans (z. B. ServiceNow Discovery, Device42) sowie Fragebögen und Interviews zur Geschäftskontinuität. Identifizieren Sie nicht verwaltete Systeme, wie z. B. Rogue-/Shadow-IT-Server und Sandbox-/Staging-VMs von Entwicklern, sowie Cloud-Konten, wie z. B. Ad-hoc-AWS-/Azure-Abonnementkonten und Google Cloud Platform (GCP)-Projektarbeitsbereiche. Identifizieren Sie darüber hinaus Kubernetes-Namespaces, wie z. B. Staging- und Feature-Branch-Namespaces (z. B. „staging-checkout“, „dev-payments“), sowie Remote-Standorte, wie z. B. Zweigstellen/regionale Depots und Produktions-/Edge-Computing-Standorte. Identifizieren Sie außerdem SaaS-Anwendungen wie Plattformen für die Zusammenarbeit in Unternehmen (z. B. Microsoft 365, Google Workspace) und geerbte Plattformen wie Legacy-Mainframes/AS400-Systeme und IT-Umgebungen übernommener Tochtergesellschaften. Weisen Sie jedem geschützten Dienst einen technischen Verantwortlichen und einen geschäftlichen Verantwortlichen zu. ### 2. Definieren Sie Wiederherstellungsstufen, bevor Sie eine Technologie auswählen Gruppieren Sie Dienste anhand ihrer geschäftlichen Auswirkungen. Legen Sie messbare Anforderungen für RPO, RTO, Aufbewahrungsdauer, Wiederherstellungsort und Tests fest, wie z. B. automatisierte vierteljährliche Wiederherstellungsläufe in einer Sandbox und halbjährliche vollständige Failover-Simulationen. Lassen Sie nicht zu, dass der Standardzeitplan eines Tools zur geschäftlichen Anforderung wird. ### 3. Identifizieren Sie die Daten und Komponenten jeder Workload, die gemeinsam erfasst werden müssen, um einen nutzbaren Wiederherstellungspunkt zu erstellen Entscheiden Sie, was Sie für einen nutzbaren Wiederherstellungspunkt erfassen sollten. Ziehen Sie beispielsweise in Betracht, Datendateien und Protokolle für eine Datenbank zu erfassen. Erwägen Sie die Erfassung von VMs, Datenbanken, Nachrichtenwarteschlangen oder Kubernetes-Ressourcen für eine mehrschichtige Anwendung. Registrieren Sie Anwendungs-Hooks, wie z. B. „Pre-Snapshot-Freeze“- und „Post-Snapshot-Thaw“-Hooks, sowie Anforderungen an die Reihenfolge, wie z. B. geordnete Startabhängigkeiten (Infrastruktur – Datenbank – Anwendung – Frontend). ### 4. Passen Sie die Schutzmethoden an das Verhalten der Workloads an Entscheiden Sie sich für agentenbasierten, agentenlosen, Snapshot-basierten, API-basierten, datenbanknativen oder kontinuierlichen Schutz. Dabei müssen Sie die Anforderungen der Workloads berücksichtigen, wie z. B. den Zugriff auf Hypervisor/Betriebssystem (OS), den Ressourcenaufwand sowie das Transaktionsvolumen und die Änderungsraten. Nutzen Sie native Integrationen wie datenbanknative Backup-APIs, z. B. Oracle Recovery Manager (RMAN) oder Microsoft SQL Volume Shadow Copy Service (VSS)-Writer, sofern diese anwendungskonsistente Backups, die Koordination von Transaktionsprotokollen, effiziente inkrementelle Backups oder granulare Wiederherstellung bieten. Nutzen Sie darüber hinaus Snapshot-APIs von Speicher-Arrays und Cloud-nativen Lösungen, wie beispielsweise die Snapshot-APIs von AWS Elastic Block Store (EBS) oder die NetApp ONTAP-Integration, sofern diese die Konsistenz, eine bessere Protokollverarbeitung, inkrementelle Effizienz oder eine granulare Wiederherstellung verbessern. ### 5. Trennen Sie Backup-Steuerung und -Speicher von der Produktionsumgebung Beschränken Sie den administrativen Zugriff, verlangen Sie bei der Arbeit mit unterstützten Systemen eine Multi-Faktor-Authentifizierung, isolieren Sie Backup-Zugangsdaten, z. B. durch dedizierte, eigenständige Identitätsanbieter (z. B. separates lokales Verzeichnis/dedizierter Okta-Tenant) und PAM-Tresore (Privileged Access Management) mit Just-in-Time-Zugriff (z. B. CyberArk, HashiCorp Vault). Verwalten Sie unveränderliche oder Offline-Kopien, wie z. B. S3-Objektsperren mit WORM-Speicher (Write-Once-Read-Many) und luftisolierte physische Speicherkopien (z. B. Offline-Bänder oder isolierte Speichernetzwerke). Eine zweite Kopie, die unter der Kontrolle desselben kompromittierten Identitäts- und Zugriffsmanagementsystems steht, bietet keinen unabhängigen Schutz vor einer Kompromittierung dieses Identitätssystems. ### 6. Entwerfen Sie sowohl Wiederherstellungs- als auch Sicherungspfade Legen Sie fest, an welchem Ort Workloads wiederhergestellt werden sollen, falls die ursprüngliche Plattform nicht mehr verfügbar ist. Überprüfen Sie Netzwerkkapazität, Cloud-Kontingente, kompatible Rechenressourcen, Softwareversionen, Schlüssel und Fachkenntnisse. Wenn Sie ein Backup nur auf der ausgefallenen Quellplattform wiederherstellen können, kann dies zu einer zirkulären Abhängigkeit führen. ### 7. Testen Sie repräsentative Ausfallszenarien Testen Sie den Verlust von VMs, den Ausfall von Clustern, granulare Löschungen, Datenbankbeschädigungen, Ransomware, Kompromittierungen von Cloud-Konten und standortbezogene Ausfälle. Bewerten Sie die tatsächlichen RPO- und RTO-Werte. Zeichnen Sie nicht lediglich auf, wie der Vorgang abgeschlossen wurde. ## Was sind die häufigsten Probleme bei heterogenen Backups? Zu den häufigen Fehlern zählen fehlende Workloads, abgelaufene Anmeldedaten, unvollständige Anwendungsabhängigkeiten, übermäßige Administratorrechte und ungetestete plattformübergreifende Wiederherstellung. Plattformübergreifende Abhängigkeiten können zu Fehlern führen, die Identität, Authentifizierung, Abfolge und API-Kompatibilität betreffen. Zu den Fehlern können Abweichungen bei Identität, Zugriff und plattformübergreifender Authentifizierung sowie Inkompatibilitäten bei der Abfolge von Microservices und API-Protokollen zwischen unterstützten Plattformen gehören – nicht innerhalb dieser. ### Wie entstehen durch neue Workloads Lücken in der Backup-Abdeckung? In Umgebungen mit häufigen Bereitstellungs- oder Konfigurationsänderungen kann die manuelle Pflege von Backup-Richtlinien dazu führen, dass neue Workloads vorübergehend ungeschützt bleiben. Zu manuell gepflegten Backup-Richtlinien können manuelle, auf Tabellenkalkulationen basierende Audit-Richtlinien sowie statische Tagging-/Labeling-Richtlinien ohne automatisierte Durchsetzung gehören. Neue virtuelle Maschinen (VMs), Datenbanken, Namespaces, SaaS-Tenants oder Cloud-Konten werden möglicherweise nie erfasst. Ein Asset kann über eine Konsole weiterhin sichtbar sein, auch wenn seine Anmeldedaten abgelaufen sind oder seine Schutzmethode von der Richtlinie abweicht. Daher sollten Sie die Abdeckung kontinuierlich messen. Erfasste Produktions-Assets, wie z. B. Auflistungen von Cloud-API-Beständen sowie Hypervisor- und Cluster-Management-Objekte, sollten zusammen mit geschützten Assets erfasst werden. Zu den geschützten Assets können aktive Datensätze im Backup-Auftrags-Katalog und abgeschlossene Snapshot-Manifeste gehören. Der Abschluss eines Backup-Auftrags belegt die Datenerfassung, nicht jedoch die Wiederherstellbarkeit der Anwendung. Heben Sie darüber hinaus unbekannte, ausgeschlossene und nicht konforme Workloads hervor, wie z. B. verwaiste/ungeschützte Cloud-Datenbanken und veraltete/fehlerhafte Anmeldedaten. Verwenden Sie außerdem Tags und Labels, um die Zuordnung zu automatisieren. Teams müssen fehlende oder fehlerhafte Metadaten als Kontrollversagen überwachen. ### Bedeutet ein erfolgreiches Backup, dass eine Anwendung wiederherstellbar ist? In der Regel bestätigt Backup-Software, dass sie Daten gelesen und gespeichert hat. Sie kann jedoch nicht automatisch die Verfügbarkeit aller Anwendungsabhängigkeiten nachweisen, wie z. B. Active Directory/Identitätsanbieter, DNS-Server, externe Schlüsselverwaltungsserver (KMS) und Geheimnisspeicher. Außerdem kann sie nicht automatisch gewährleisten, dass der wiederhergestellte Dienst funktioniert. Um die Wiederherstellung sicherzustellen, sollten Sie auf automatisierte Start- oder Einbindungsprüfungen setzen, die Datenbankintegrität testen, nach Malware scannen, Validierungen auf Anwendungsebene durchführen und regelmäßige Abnahmen durch die Verantwortlichen vornehmen. Dienste mit hoher Auswirkung, wie z. B. Kernbank- und Transaktionsverarbeitungssysteme sowie E-Commerce-Checkout- und Auftragsabwicklungsplattformen, erfordern zudem umfassende Workflow-Tests und nicht nur reine Infrastrukturtests. ### Welche Sicherheitsrisiken birgt ein zentralisiertes Backup-Management? Eine einheitliche Plattform kann die Anzahl der Konsolen, Kataloge und Richtlinien-Systeme reduzieren, die Administratoren verwalten müssen. Sie kann jedoch auch zu einem besonders attraktiven Ziel für Angreifer werden. Die Auswirkungen eines Sicherheitsvorfalls können sich auf die gesamte IT-Umgebung ausbreiten. Dies geschieht, wenn ein zentrales Managementsystem Richtlinien löscht, Kopien auslaufen lässt – wie beispielsweise geplante tägliche inkrementelle Backup-Sätze, die noch nicht in ein externes oder luftisoliertes Repository repliziert wurden, sowie Snapshots zur langfristigen Aufbewahrung, die für die Archivierung zur Einhaltung gesetzlicher Vorschriften bestimmt sind und deren festgelegtes Ablaufdatum noch nicht erreicht ist – und anschließend auf jede Workload zugreift. Erwägen Sie eine Trennung der Rollen, um dieses Risiko zu verringern. Wenden Sie außerdem Just-in-Time-Zugriffsrechte für Administratoren an, verwenden Sie getrennte Anmeldedaten, nutzen Sie feste Aufbewahrungssperren, leiten Sie Protokolle weiter und setzen Sie gehärtete Verwaltungshosts ein Verwenden Sie darüber hinaus separate Sicherheitsdomänen, wie vollständig isolierte Amazon Web Services-Konten/Azure-Abonnements und luftisolierte/isolierte lokale Active Directory-Forests, für Sekundärkopien, beispielsweise fest gesperrte S3-WORM-Objekt-Buckets und luftisolierte, externe Bandkassetten oder isolierte Speicher-Appliances. Bei zentraler Transparenz sollte es nicht um uneingeschränkte zentralisierte Befugnisse gehen. ### Wie wirkt sich Deduplizierung auf die Kosten für Backup-Speicher aus? Daten aus gemischten Workloads, wie beispielsweise transaktionale SQL-Datenbanken in Kombination mit unkomprimierten Rohdateifreigaben und Images der virtuellen Desktop-Infrastruktur in Kombination mit Medien-/Videospeicher, lassen sich nicht gleichermaßen deduplizieren. Verschlüsselte Datenbanken, komprimierte Medien, virtuelle Festplatten mit hohen Änderungsraten und clientseitig verschlüsselte Cloud-Daten können zu schlechten Reduktionsraten führen. Obwohl globale Deduplizierung Kapazität einsparen kann, lässt sie sich auch für Leistungs-, Fehlerdomänen- oder Datenresidenz-Überlegungen nutzen, wie z. B. bei dedizierten/segmentierten Infrastrukturen, deren Komponenten gemeinsam ausfallen können, sowie bei Leistungspools und der geografischen und regulatorischen Isolierung der Datenresidenz. Kapazitätsmodelle sollten arbeitslastspezifische Änderungsraten, Aufbewahrungsfristen, das Verhalten bei Vollsicherungen, unveränderlichen Overhead, Replikation sowie Ausgangs- und Wiederherstellungs-Staging-Speicher berücksichtigen. Die Kapazitätsplanung sollte sich nicht auf eine einzige Deduplizierungsrate für wesentlich unterschiedliche Arbeitslasttypen stützen. ### Warum sollte die plattformübergreifende Wiederherstellung getestet werden? Unternehmen verlassen sich häufig auf Backups, um die Cloud-Migration oder die Wiederherstellung auf einem anderen Hypervisor zu unterstützen. In der Praxis kann die Wiederherstellung jedoch durch Unterschiede bei Treibern, Startmodi, Festplattenformaten, Netzwerkkonfigurationen, Identitäten, Managed-Service-Funktionen und Anwendungslizenzen blockiert werden. Daher sollte die Wiederherstellung auf einer anderen Plattform als separater Anwendungsfall betrachtet werden, der dokumentierte Unterstützung und Tests erfordert. Das Exportieren von Daten ist nicht gleichbedeutend mit der Rekonstruktion einer betriebsbereiten Anwendung. ## Sollten Sie eine einzige Backup-Plattform oder mehrere Spezialtools verwenden? Beide Modelle können funktionieren. Die Wahl hängt von der Unterstützung der Workloads, den Wiederherstellungsanforderungen, den Sicherheitsgrenzen, den betrieblichen Kompetenzen und den regulatorischen Anforderungen ab. Heterogenes Backup ist mit zwei gängigen Ansätzen verbunden. Konkret können Unternehmen eine einheitliche Plattform nutzen, um verschiedene Workload-Typen unter einem Katalog- und Richtlinien-System abzusichern. Ein föderierter Ansatz behält Spezialprodukte bei und ergänzt diese um gemeinsame Überwachung, Governance oder Berichterstellung. | Entscheidungsfaktor | Einheitliche Backup-Plattform | Mehrere Spezialtools | | --- | --- | --- | | Betriebliche Sichtweise | Gemeinsame Konsole, Katalog und Berichterstellung | Aggregation oder manuelle Korrelation erforderlich | | Tiefe der Workloads | Kann je nach Integration variieren | Kann für tiefgreifendere native Funktionen nützlich sein | | Konsistenz der Richtlinien | Einfacher zentral zu formulieren und zu prüfen | Unternehmen sollten Richtlinien produktübergreifend umsetzen | | Sicherheitsrisiko | Ein zentrales Managementsystem kann das Sicherheitsrisiko erhöhen | Mehr zentrale Managementsysteme und Anmeldedaten, die gesichert werden müssen | | Kompetenzen und Support | Weniger Betriebsmodelle | Mehr Fachwissen und Koordination mit Anbietern | | Ausstiegsrisiko | Größere Abhängigkeit von einem Katalog oder Backup-Format | Höhere Integrations- und Betriebskomplexität | | Am besten geeignet | Breit unterstützte IT-Umgebung mit starkem zentralem Betrieb | Workloads mit unterschiedlichen technischen oder regulatorischen Anforderungen | Unternehmen können ein einheitliches Governance-Modell anwenden, selbst wenn unterschiedliche Workloads unterschiedliche Backup-Produkte erfordern. Der Einsatz eines spezialisierten Datenbank- oder Mainframe-Tools kann gerechtfertigt sein, wenn eine allgemeine Plattform keine Konsistenz gewährleistet und die Anforderungen an Leistung oder Wiederherstellung nicht erfüllt, wie beispielsweise bei Oracle Real Application Clustern mit hohem Durchsatz, die eine RMAN-Integration zu einem bestimmten Zeitpunkt erfordern, sowie bei Mainframe- und Legacy-OS-Workloads (z. B. IBM z/OS oder AS/400). Unternehmen sollten jedoch den Abdeckungsgrad und etwaige Fehler im Blick behalten, wie z. B. nicht registrierte/ungeschützte spezialisierte Workloads, plattformübergreifende Inkompatibilitäten bei der Wiederherstellung sowie API-Fehler. Dies bezieht sich auch auf die Einhaltung von Aufbewahrungsfristen und Nachweise aus Wiederherstellungstests im Zusammenhang mit jeder Ausnahme bei den üblichen Betriebsprozessen. Testen Sie zunächst die Edge-Workloads. Konzentrieren Sie sich nicht nur auf die gängige VMware- oder Windows-IT-Umgebung. Konsolidieren Sie anschließend Tools wie unterschiedliche Punkt-Backup-Agenten, die separat über Oracle-Datenbanken, Kubernetes-Cluster und Legacy-Unix-Systeme laufen und derzeit individuelle Verwaltungskonsolen sowie separate Lizenzvereinbarungen erfordern. Prüfen Sie als Nächstes, ob die in Frage kommende Plattform Anwendungsmetadaten, Berechtigungen, Protokolle und Abhängigkeiten wiederherstellen kann. Prüfen Sie, ob die in Frage kommende Plattform die eingesetzten Versionen unterstützt. Stellen Sie fest, ob eine Wiederherstellung auch dann möglich ist, wenn die SaaS-Steuerungsebene oder der Lizenzierungsdienst des Anbieters nicht verfügbar ist. ## So messen Sie, ob heterogenes Backup funktioniert Die Erfolgsquote von Backup-Jobs allein ist kein Maßstab für die Wiederherstellbarkeit. Sie können Schutz und Wiederherstellung anhand einer aussagekräftigeren Bewertungsmatrix messen: - **Asset-Abdeckung:** Prozentsatz der erfassten Produktionsressourcen, wie z. B. neu bereitgestellte Cloud-Infrastruktur sowie Kubernetes-Namespaces und persistente Volumes, die durch eine genehmigte Richtlinie geschützt sind - **Richtlinienkonformität:** Prozentsatz der Ressourcen, die die erforderlichen RPO-, Aufbewahrungs-, Kopier- und festen Kontrollen erfüllen, wie z. B. die Sperrung unveränderlicher Objekte (WORM) und geografisch getrennte bzw. luftisolierte Sekundärkopien - **Gültigkeit der Wiederherstellungspunkte:** Prozentsatz der stichprobenartig ausgewählten Wiederherstellungspunkte, die Integritäts- und Malware-Prüfungen bestehen - **Getestete Wiederherstellbarkeit:** Prozentsatz der kritischen Anwendungen, wie z. B. Enterprise-Resource-Planning-Systeme (ERP) (z. B. SAP, Oracle EBS) sowie kundenorientierte E-Commerce- und Zahlungsgateways, die innerhalb des vorgeschriebenen Testzeitraums wiederhergestellt und validiert wurden - **Beobachtete RPO und RTO:** Tatsächlicher Datenverlust und verstrichene Wiederherstellungszeit während Tests oder Vorfällen, wie z. B. das Delta bei der zeitpunktbezogenen Datenbankwiederherstellung (beobachtete RPO) sowie die Zeit für die vollständige Wiederherstellung und den Neustart der Anwendung (beobachtete RTO). - **Abweichungsdauer:** Wie lange eine neue oder geänderte Workload außerhalb einer genehmigten Richtlinie verbleibt - **Ausnahmealter:** Wie lange nicht unterstützte oder ausgenommene Workloads ungelöst bleiben - **Fähigkeit zur Wiederherstellung in einer isolierten Umgebung nach einer Kompromittierung:** Ob Anmeldedaten, Netzwerke, Rechenressourcen, Schlüssel und Verfahren vorhanden sind, um die Wiederherstellung außerhalb der kompromittierten Umgebung durchzuführen Workload-Klasse und Geschäfts-Tier können bei der Segmentierung von Metriken helfen, wie z. B. Tier-0-/geschäftskritische Workloads (z. B. Kernbanking, IAM/Active Directory) und Tier-3-/nicht kritische Workloads (z. B. interne Entwicklungs-/Testumgebungen, Archiv-Dateifreigaben). Eine Erfolgsquote von 98 % kann wiederholte Ausfälle einiger Systeme verschleiern, die den größten Teil des Geschäftsrisikos verursachen. ## Wie Bacula Enterprise heterogene Backup-Umgebungen unterstützt [Bacula Enterprise](https://www.baculasystems.com/de/unternehmensbackup-software-loesungen/bacula-unternehmen-backup-software/) wurde entwickelt, um heterogene IT-Umgebungen zu schützen, ohne jede Workload in dieselbe Backup-Methode zu zwängen. Stattdessen können Unternehmen physische, virtuelle, containerisierte, Datenbank-, SaaS- und Cloud-Workloads über eine gemeinsame Backup- und Wiederherstellungsplattform verwalten und bei Bedarf workloadspezifische Integrationen nutzen. Dies ist in gemischten Umgebungen wichtig, da – wie oben erläutert – eine virtuelle Maschine, eine transaktionale Datenbank und eine Kubernetes-Anwendung zwar dieselben Wiederherstellungsziele verfolgen können, jedoch völlig unterschiedliche Mechanismen erfordern, um einen nutzbaren Wiederherstellungspunkt zu erstellen. Bacula Enterprise unterstützt dieses Modell durch eine modulare Architektur und eine breite Palette spezieller Plugins und Integrationen. Zu den unterstützten Umgebungen gehören VMware, Hyper-V, Proxmox, Nutanix, KVM, Xen/XCP-ng, OpenStack, Libvirt, Azure VM und viele andere sowie physische Windows-, Linux-, macOS- und Unix-Systeme. Bacula bietet zudem spezielle Funktionen für Kubernetes, Docker und Red Hat OpenShift. Für Anwendungs- und Datenbank-Workloads bietet Bacula Integrationen für Technologien wie Microsoft SQL Server, Oracle, PostgreSQL, MySQL, MariaDB, MongoDB, SAP HANA, IBM DB2 und SAP ASE. Auch SaaS-Workloads wie Microsoft 365 und Google Workspace lassen sich in die übergreifende Backup-Umgebung einbinden. Das Ergebnis ist, dass Unternehmen einheitliche Betriebsrichtlinien anwenden können, ohne das heterogene Backup auf einen Ansatz nach dem kleinsten gemeinsamen Nenner reduzieren zu müssen. So können Administratoren beispielsweise Zeitpläne, Aufbewahrungsfristen und Backup-Richtlinien zentral definieren und dabei hypervisor-orientierte Schutzmaßnahmen für virtuelle Maschinen, datenbankspezifische Methoden für transaktionsorientierte Systeme sowie Kubernetes-orientierte Mechanismen für containerisierte Anwendungen nutzen. Bacula Enterprise kann diese Workloads zudem mit unterschiedlichen Backup-Speicherzielen kombinieren. Zu den Integrationen gehören Festplatten-, Band- und Cloud-Speicher sowie S3-kompatibler Speicher, Microsoft Azure, Google Cloud, Oracle Cloud und Amazon Glacier-Schnittstellen. Dies ermöglicht es Unternehmen, Speicher und Aufbewahrungsfristen entsprechend der Workload-Ebene, den Wiederherstellungsanforderungen und den infrastrukturellen Einschränkungen zu gestalten, anstatt sich allein an der Quellplattform zu orientieren. Die zentralisierte Verwaltung erfolgt über die [BWeb Management Suite](https://www.baculasystems.com/backup-management-software-system/) , mit der sich die Backup-Umgebung konfigurieren, überwachen und analysieren lässt. Dies bietet Administratoren einen einheitlichen Überblick über verschiedene Technologien, während die für jede Workload erforderlichen speziellen Backup- und Wiederherstellungsmethoden beibehalten werden. Für Unternehmen, die eine Konsolidierung mehrerer Backup-Produkte in Betracht ziehen, kann diese breite Unterstützung die Anzahl der separat zu betreibenden Backup-Systeme reduzieren. Die Abdeckung der Workloads sollte jedoch weiterhin anhand der tatsächlich verwendeten Technologien und Versionen bewertet werden. Das Ziel besteht nicht einfach darin, jede Workload unter einer Konsole zusammenzufassen, sondern sicherzustellen, dass jedes kritische System über die geeignete Backup-Methode und einen getesteten Wiederherstellungspfad verfügt. ## Häufig gestellte Fragen ### Wie sollten nicht unterstützte Altsysteme in eine heterogene Backup-Strategie einbezogen werden? Tragen Sie sie in ein offizielles Ausnahmeregister ein, in dem der Verantwortliche, die geschäftlichen Auswirkungen, die aktuelle Wiederherstellungsmethode, Ausgleichskontrollen sowie das Datum der Stilllegung oder Behebung angegeben sind. Eine einzige Wiederherstellungsstrategie kann zudem mehrere Backup-Technologien abdecken. Sie können verschiedene Maßnahmen nutzen, wie z. B. Snapshots auf Speicherebene, Datenbank-Dumps, Dateiexporte, Replikation oder Isolierung. Testen Sie außerdem alle Workarounds. Denken Sie daran: Selbst wenn Sie unzugängliche proprietäre Daten kopieren, erhalten Sie kein brauchbares Backup. Eine Backup-Strategie ist erst dann vollständig, wenn die Wiederherstellung getestet wurde. ### Kann ein unveränderliches Repository Backups aus jeder Umgebung sicher speichern? Ein unveränderliches Repository kann die Aufbewahrungs- und Kapazitätsverwaltung vereinfachen. Dies gilt, sofern das Repository die erforderlichen Eigenschaften hinsichtlich Unveränderlichkeit, Durchsatz, Isolation und regulatorischer Kontrollen unterstützt. Allerdings kann es zu einer Konzentration von Betriebs- und Sicherheitsrisiken führen. Bewerten Sie die Trennung der Mandanten, Verschlüsselungsschlüssel, Verwaltungsdomänen, Datenstandorte, Ausfalldomänen, den Wiederherstellungsdurchsatz sowie die Auswirkungen eines Ausfalls des Repositorys. Selbst wenn Unternehmen ein einheitliches Management anwenden, können kritische Dienste wie Identitäts- und Verzeichnisdienste (z. B. Active Directory/Entra ID, Public-Key-Infrastruktur) sowie zentrale Finanz- und Transaktionsverarbeitungssysteme (z. B. SAP, Mainframe-Kernbanking) auf der Grundlage einer Risikobewertung separate Sicherungskopien oder Speicherebenen rechtfertigen. ### Wie oft sollte eine heterogene Wiederherstellung getestet werden? Legen Sie die Häufigkeit anhand der Geschäftsstufe und der Änderungsrate fest. Wenden Sie bei jedem Backup eine automatisierte Validierung für kritische Dienste an. Vergessen Sie nicht geplante Anwendungswiederherstellungsübungen, wie z. B. die Simulation eines Full-Stack-Disaster-Recovery-Wechsels (DR) und die isolierte Ransomware-Wiederherstellung im „Clean Room“. Workloads auf niedrigeren Ebenen können seltener getestet werden. Die Testhäufigkeit sollte sich aus den geschäftlichen Auswirkungen, den regulatorischen Anforderungen, der Änderungshäufigkeit und den Wiederherstellungszielen ableiten. Sie müssen jedoch alle wesentlichen Plattformtypen sowie Prozesse und Ziele einbeziehen, die zur Wiederherstellung einer Workload verwendet werden. Führen Sie nach größeren Upgrades, Datenmigrationen, Identitätsänderungen oder Architekturänderungen erneute Tests durch. Messen Sie den Erfolg der Wiederherstellung, nicht nur den Erfolg der Sicherung. Über den Autor [https://www.linkedin.com/in/rob-morrison-3aa443/](https://www.linkedin.com/in/rob-morrison-3aa443/) Rob Morrison ist der Marketingdirektor bei Bacula Systems. Er begann seine IT-Marketing-Karriere bei Silicon Graphics in der Schweiz, wo er fast 10 Jahre lang in verschiedenen Marketing-Management-Positionen sehr erfolgreich war. In den folgenden 10 Jahren hatte Rob Morrison auch verschiedene Marketing-Management-Positionen bei JBoss, Red Hat und Pentaho inne und sorgte für das Wachstum der Marktanteile dieser bekannten Unternehmen. Er ist Absolvent der Plymouth University und hat einen Honours-Abschluss in Digital Media and Communications und ein Overseas Studies Program absolviert. *Verwandte Beiträge* [https://www.baculasystems.com/de/blogs/sicherheit-elektronischer-patientenakten/](https://www.baculasystems.com/de/blogs/sicherheit-elektronischer-patientenakten/) [Sicherheit elektronischer Patientenakten: Patientendaten, HIPAA und die Bedrohungen, die das Gesundheitswesen nicht ignorieren darf](https://www.baculasystems.com/de/blogs/sicherheit-elektronischer-patientenakten/) Juni 17, 2026 [https://www.baculasystems.com/de/blogs/mongodb-sicherung-wiederherstellen/](https://www.baculasystems.com/de/blogs/mongodb-sicherung-wiederherstellen/) [Vollständige Anleitung zur Sicherung und Wiederherstellung von MongoDB-Datenbanken](https://www.baculasystems.com/de/blogs/mongodb-sicherung-wiederherstellen/) März 16, 2026 [https://www.baculasystems.com/de/blogs/intersystems-iris-sicherung-und-wiederherstellung-zur-gewaehrleistung-der-datenbankintegritaet/](https://www.baculasystems.com/de/blogs/intersystems-iris-sicherung-und-wiederherstellung-zur-gewaehrleistung-der-datenbankintegritaet/) [InterSystems IRIS: Sicherung und Wiederherstellung zur Gewährleistung der Datenbankintegrität](https://www.baculasystems.com/de/blogs/intersystems-iris-sicherung-und-wiederherstellung-zur-gewaehrleistung-der-datenbankintegritaet/) Mai 28, 2026 [https://www.baculasystems.com/de/blogs/cassandra-sichern-wiederherstellen/](https://www.baculasystems.com/de/blogs/cassandra-sichern-wiederherstellen/) [Vollständige Anleitung zur Sicherung und Wiederherstellung von Cassandra-Datenbanken](https://www.baculasystems.com/de/blogs/cassandra-sichern-wiederherstellen/) April 23, 2026 [https://www.baculasystems.com/de/blogs/proxmox-vs-kvm/](https://www.baculasystems.com/de/blogs/proxmox-vs-kvm/) [Auswahl der richtigen Virtualisierungsplattform: Proxmox vs. KVM erklärt](https://www.baculasystems.com/de/blogs/proxmox-vs-kvm/) Februar 4, 2025 [https://www.baculasystems.com/de/blogs/bewahrte-praktiken-fur-openstack-sicherung-und-wiederherstellung/](https://www.baculasystems.com/de/blogs/bewahrte-praktiken-fur-openstack-sicherung-und-wiederherstellung/) [OpenStack Sicherung und Wiederherstellung: Bewährte Praktiken, integrierte Methoden und Lösungen](https://www.baculasystems.com/de/blogs/bewahrte-praktiken-fur-openstack-sicherung-und-wiederherstellung/) November 13, 2023