Einheit 5.7: Datensicherung und Lebenszyklus

Einführung

Es gibt auf IONOS CLOUD kein einzelnes Produkt, das „alles sichert“. Die Behandlung eines einzigen Mechanismus so, als würde er jede Arbeitslast abdecken, ist der häufigste Designfehler im Bereich der Datensicherung auf der Plattform. Jeder Mechanismus schützt eine bestimmte Fehlerklasse, und drei von ihnen haben Grenzen, die, wenn sie übersehen werden, dazu führen, dass eine Ebene stillschweigend ungeschützt bleibt. Das Backup Service greift verwaltete Datenbanken nicht an. Ein Snapshot ist ein Rollback-Punkt, keine konsistente Datensicherung. Und das Backup Service bietet keine Unveränderlichkeit. Diese Einheit behandelt diese Grenzen als die Designeingaben, die sie sind, und setzt die Mechanismen zu einer einzigen Kontinuitätsebene für FinCorp zusammen.

1. Die vier Grundbausteine und die Grenzen, die sie voneinander trennen

Jeder der vier Mechanismen zum Schutz von Daten beantwortet eine andere Frage zur Wiederherstellung. Die Fähigkeit besteht darin, den Mechanismus an die Arbeitslast anzupassen, nicht darauf, den vertrautesten Mechanismus zu wählen.

1.1 Der Backup Service: Umfang und was er nicht ist

Der Backup Service ist das agentenbasierte Schutzprodukt, das auf Acronis Cyber Protect basiert. Sie installieren einen Agenten auf der Arbeitslast, definieren einen Schutzplan, und der Agenten überträgt verschlüsselte Daten an ein Speicherziel. Für Arbeitslasten in der Cloud sind die Zielsysteme IONOS CLOUD Compute Engine VMs (Dedicated Core, vCPU und Cubes), die aus öffentlichen Images (automatische Agenteninstallation) oder privaten Images (manuelle Installation) bereitgestellt werden. Dasselbe Produkt in seiner Variante mit externem Agenten schützt auch Server, Arbeitsstationen, VMs in anderen öffentlichen Clouds, Hyper-V- und VMware-Virtuelle Maschinen sowie macOS-Geräte vor Ort. Dadurch ist es das natürliche Werkzeug, um einen hybriden Bestand aus einer einzigen Konsole während einer Migration zu schützen.

Die Verschlüsselung ist solide: Daten während der Übertragung verwenden HTTPS und TLS, und Daten im Ruhezustand verwenden serverseitige AES-256-Verschlüsselung, mit optionaler clientseitiger AES-256-Verschlüsselung, die Sie pro Schutzplan mit einem Passwort aktivieren. Das Standard-Speicherziel ist Backup Storage, Sie können Sicherungen jedoch auch an Object Storage (IONOS CLOUD, S3-kompatibel oder andere vorkonfigurierte Anbieter) oder Network File Storage leiten.

Zwei Grenzen müssen klar benannt werden. Erstens unterstützt der Backup Service keine unveränderlichen Sicherungen. Wenn Ihr Steuerungsziel eine manipulationserkennende, einmalige Aufbewahrung ist (wie sie eine Ransomware-Wiederherstellung oder eine Audit-Nachweispflicht erfordert), liefert der Backup Service allein dies nicht; Sie setzen Unveränderbarkeit separat über Object Storage Object Lock (Einheit 5.2) um. Zweitens zum Compliance-Umfang: Der Backup Service ist vom BSI IT-Grundschutz ISO 27001 Zertifikat (deutsche Rechenzentren) abgedeckt, gehört aber nicht zum BSI C5 Nachweisspektrum. C5 Type 1 (2023-11-07) deckt nur Compute Engine, Cloud Cubes und Object Storage ab. Für FinCorp unter BSI ist diese Unterscheidung vertraglich und nicht nur kosmetisch: Eine Sicherung einer C5-umfassten Arbeitslast erbt C5 nicht einfach deshalb, weil die Quelle es war.

1.2 Snapshots: VM-Ebene Rollback, keine Datenbank-Sicherung

Ein Block Storage Snapshot erfasst den Zustand eines einzelnen bereitgestellten Block Storage Geräts zu einem bestimmten Zeitpunkt. Snapshots funktionieren mit jedem Block Storage Typ (HDD, SSD Standard, SSD Premium und DAS NVMe) und werden schnell erstellt. Sie sind das richtige Werkzeug für einen schnellen Rollback-Punkt vor einer riskanten Änderung vor Ort, wie einem Betriebssystem-Patch oder einem Anwendungs-Upgrade, und sie passen natürlich zu den Validierungsschleusen für Migrationswellen, die in Modul 7 gelehrt werden.

Drei Eigenschaften definieren, wie Sie mit Snapshots arbeiten, und jede ist eine Einschränkung:

• Nicht-incrementell. Jeder Snapshot ist eine separate, unabhängige Instanz, die den vollständigen Zustand des Quellvolumens darstellt. Es gibt keine inkrementelle Kette; ein Snapshot eines 100 GiB Volumens, das 10 GiB Daten enthält, erzeugt immer noch einen 100 GiB Snapshot, einschließlich Blöcke ohne geschriebene Daten. Ein wiederhergestelltes größeres Volumen kann nach dem Starten der VM und dem Einhängen des Volumens eine manuelle Partitionserweiterung erfordern.
• Region-lokal. Ein Snapshot befindet sich in der Region seines Quellvolumens. Er schützt nicht vor einem regionsspezifischen Ereignis und kann allein keine cross-regionale Wiederherstellung einleiten. Für cross-regionale Dauerhaftigkeit kopieren Sie die geschützten Daten in Object Storage.
• Manueller Lebenszyklus. Snapshots werden aufbewahrt, bis Sie sie löschen. Es gibt keine automatische Ablaufzeit, daher wird eine unkontrollierte Snapshot-Population zu einer stillen Kostenzeile (Snapshots verbrauchen HDD-Quota) und zu einer Governance-Lücke.

Die wichtigste Grenze hier: Ein Snapshot ist ein absturzsicheres Block-Geräte-Image, keine anwendungskonsistente oder datenbankkonsistente Sicherung. Das Erstellen eines Snapshots des Volumens unter einer laufenden verwalteten Datenbank ist kein unterstützter Datenbank-Sicherungsmechanismus, und er stellt keinen transaktionskonsistenten Zustand zuverlässig wieder her. Die Datenbankkontinuität hat ihre eigene Grundbaustein, die als Nächstes behandelt wird.

1.3 Die Datenbank-Grenze: PITR plus Dump/Restore

Die wichtigste Grenze in dieser Einheit: Der Backup Service sichert verwaltete Datenbanken nicht. Auch Snapshots dienen nicht als deren Sicherung. Die Datenbankkontinuität auf IONOS CLOUD wird innerhalb des Datenbankdienstes selbst durch zwei native Mechanismen bereitgestellt.

Der erste ist die Wiederherstellung zu einem bestimmten Zeitpunkt (PITR). Managed PostgreSQL automatisiert kontinuierliche Sicherungen in einen verschlüsselten IONOS Cloud Object Storage Bucket in derselben Region (Datenbanken in Regionen ohne IONOS CLOUD Object Storage werden in eu-central-2 gesichert), und der Sicherungsspeicherort ist unveränderlich. Das PITR-Fenster beträgt standardmäßig 7 Tage für PostgreSQL, und bei PostgreSQL ist die Aufbewahrungsdauer von 1 bis 365 Tage über backup.retentionDays konfigurierbar; lehren Sie 7 nicht als harte Grenze, es ist der Standardwert. Managed MariaDB bietet eine 7-tägige PITR-Aufbewahrung. Die Wiederherstellung wird durch echte Einschränkungen gesteuert, die Sie bei der Planung berücksichtigen müssen: Nur eine Sicherung kann gleichzeitig wiederhergestellt werden, der Cluster muss AVAILABLE sein, Sie können von derselben oder einer älteren Hauptversion wiederherstellen, eine Wiederherstellung kann eine Datenbank in eine andere Region verschieben, und recoveryTargetTime ist nicht inklusiv. Das Wiederherstellungsziel ist im schlimmsten Fall nicht verlustfrei: Wenn alle Replikate gleichzeitig Daten verlieren, beträgt das potenzielle Datenverlust-Fenster bis zu den letzten 30 Minuten oder 16 MB.

Der zweite ist das logische Dump/Restore, derselbe Mechanismus, der als einziger Migrationspfad in diese Dienste dient. Für PostgreSQL sind die Werkzeuge pg_dump, pg_restore und psql; für MariaDB ist es mariadb-dump. Ein periodisches logisches Dump, das in Object Storage abgelegt wird, liefert Ihnen eine portable, versionstolerante Kopie, die außerhalb des Clusters überlebt, was genau das ist, was PITR (gebunden an den eigenen unveränderlichen Sicherungsspeicher des Clusters) nicht bietet.

Das Datenbank-Wiederherstellungsdesign ist also geschichtet: PITR für feingranularen Rollback innerhalb des Aufbewahrungsfensters und geplante logische Dumps in Object Storage für langfristige, portable und (mit Object Lock) manipulationserkennende Aufbewahrung.

2. Zusammensetzung einer einzigen Datenkontinuitätsebene

Kein einzelnes Primitiv ist eine Kontinuitätsebene. Die Ebene entsteht, wenn jeder Workload-Ebene der Mechanismus zugewiesen wird, der zu ihrer Fehlerklasse und ihrem Wiederherstellungsziel passt, und anschließend Object Storage als gemeinsame Archiv- und Unveränderlichkeitsschicht darunter hinzugefügt wird.

Die folgende Tabelle zeigt die Fehlerklassen, die jedes Primitiv tatsächlich abdeckt.

Aus dieser Tabelle ergeben sich zwei Zusammensetzungsregeln. Erstens ist Unveränderlichkeit eine Eigenschaft von Object Storage, nicht von Backup Service: Wo eine Ebene eine einmalige Schreibaufbewahrung benötigt, muss die Wiederherstellungskopie in einem object-gesicherten Bucket landen, unabhängig davon, ob diese Kopie ein Backup Service-Ziel, exportierte Daten eines Snapshots oder ein Datenbank-Dump ist. Object Lock unterstützt die Modi GOVERNANCE und COMPLIANCE, mit einer Aufbewahrungsdauer von bis zu 365 Tagen im DCD und bis zu 100 Jahren über die API. Zweitens wird regionenübergreifende Dauerhaftigkeit erreicht, indem eine Kopie in Object Storage abgelegt wird, da sowohl Snapshots als auch PITR-Sicherungsspeicher an eine Region gebunden sind.

Unternehmens-Fallstudie (FinCorp)

Das regulierte Umfeld von FinCorp umfasst die migrierten VMware-Workloads, einen verwalteten PostgreSQL-Cluster hinter der Anwendungsebene und das in Modul 2 eingerichtete Audit-Archiv. Gemäß BSI und DSGVO besteht die Anforderung nicht darin, „alles zu sichern“, sondern in einer vertretbaren, stufenweisen Wiederherstellungsbereitschaft mit manipulationssicheren Nachweisen, sofern diese vorgeschrieben sind.

Die Compute-Ebene (die migrierten und IONOS CLOUD-eigenen VMs) wird durch den Backup Service geschützt. Während der Migration ist dies doppelt nützlich: Die Variante mit externem Agent schützt die On-Premises-VMs über den Cutover hinweg über dieselbe Konsole, mit der anschließend die IONOS CLOUD-VMs geschützt werden. Da der Backup Service keine Unveränderlichkeit bietet, leitet FinCorp die Sicherungskopien zur Ransomware-Wiederherstellung an ein Object Storage-Ziel mit Object Lock im COMPLIANCE-Modus, sodass die Nachweiskopie innerhalb ihrer Aufbewahrungsfrist weder verändert noch gelöscht werden kann. Die riskanten In-Place-Schritte während des Cutovers erhalten unmittelbar zuvor einen Snapshot-Rollback-Punkt, wobei akzeptiert wird, dass Snapshots regionsspezifisch und kurzlebige Arbeitsartefakte sind, nicht das Archiv.

Der PostgreSQL-Cluster wird bewusst vom Backup Service ausgenommen, da dies die Plattformgrenze darstellt. Seine Kontinuität wird durch PITR für das 7-Tage-Betriebsfenster gewährleistet, ergänzt um eine nächtliche pg_dump, die in einen object-locked Bucket ausgeliefert wird, um eine langfristige, portable, auditfähige Kopie zu erstellen. Das Worst-Case-Verlustfenster von 30 Minuten / 16 MB wird als akzeptiertes RPO des Cluster dokumentiert und mit dem in Einheit 7.1 übernommenen geschäftlichen RPO abgestimmt. Das Audit-Archiv selbst befindet sich bereits seit Einheit 2.3 in object-locked Object Storage. Das Ergebnis ist eine einheitliche Kontinuitätsebene: unterschiedliche Mechanismen pro Ebene, Object Storage als gemeinsame unveränderliche Grundlage und keine Ebene, die stillschweigend auf ein Verfahren angewiesen ist, das sie nicht abdeckt.

Zusammenfassung der Entscheidung

Wählen Sie den Schutzmechanismus anhand der Workload-Ebene und des Wiederherstellungsziels, nicht anhand der Vertrautheit.

Harte Einschränkungen, die zu beachten sind: Der Backup Service schließt verwaltete Datenbanken aus und bietet keine unveränderlichen Sicherungen; Snapshots sind nicht inkrementell, regional lokal, manuell aufzubewahren und nicht datenbankkonsistent; PITR ist fenstergebunden und regional lokal; Unveränderlichkeit und überregionale Ausfallsicherheit werden über Object Storage erreicht.

Zusammenfassung

Der Datenschutz von IONOS CLOUD besteht aus einer Reihe von Einzweck-Primitiven, die jeweils eine feste Grenze aufweisen. Diese werden zu einer einheitlichen Kontinuitätsebene komponiert, nicht zu einem einzelnen Sicherungsprodukt. Der Backup Service schützt VMs und Block Storage (sowie hybride Umgebungen), jedoch keine verwalteten Datenbanken und auch keine unveränderlichen Sicherungen. Snapshots sind schnelle, regionale Rollback-Punkte, keine Datensicherungen. Verwaltete Datenbanken werden über deren eigenes PITR sowie portierbare Dump/Restore-Prozesse wiederhergestellt. Der Object Storage Object Lock stellt die Schicht für Unveränderlichkeit und archivierte Daten über Regionen hinweg bereit, die den anderen Komponenten fehlt. Weisen Sie jeder Ebene gemäß Fehlerklasse genau einen Mechanismus zu und nutzen Sie Object Storage als gemeinsame Grundlage.

Wichtige Punkte:

• Der Backup Service (Acronis) deckt VMs und Block Storage ab, einschließlich von On-Premises-VMs und VMs in anderen Clouds über den externen Agenten. Verwaltete Datenbanken werden jedoch ausdrücklich nicht gesichert, und unveränderliche Sicherungen werden nicht unterstützt.
• Snapshots von Block Storage sind vollständige, nicht inkrementelle, regionale und manuell verwaltete Rollback-Punkte auf VM-Ebene, keine datenbankkonsistenten Sicherungen.
• Die Kontinuität verwalteter Datenbanken ist nativ: PITR (PostgreSQL: Standard 7 Tage, konfigurierbar 1 bis 365 Tage; MariaDB: 7 Tage) für Wiederherstellungen innerhalb des Zeitfensters sowie logisches Dump/Restore für portierbare Langzeitkopien.
• Unveränderlichkeit und Ausfallsicherheit über Regionen hinweg sind Eigenschaften des Object Storage (Object Lock GOVERNANCE / COMPLIANCE), die unter der jeweiligen Wiederherstellungskopie eingesetzt werden, die sie benötigt.
• Compliance ist dienstespezifisch: Der Backup Service unterliegt dem IT-Grundschutz ISO 27001, nicht der BSI C5-Zertifizierung. Eine Sicherung erbt daher nicht den Geltungsbereich der Quellearbeitsschleife.

Wichtige Begriffe:

• Punkt-in-time-Wiederherstellung (PITR): Kontinuierliche Datensicherung zu einem unveränderlichen, regionalen Object Storage-Speicher, die die Wiederherstellung zu einem beliebigen Zeitstempel innerhalb des Aufbewahrungszeitfensters ermöglicht. Sie ist an das Zeitfenster gebunden und keine portierbare Kopie.
• Object Lock: Einmal-Schreiben, mehrmalig-Lesen-Aufbewahrung im Object Storage im GOVERNANCE- oder COMPLIANCE-Modus (bis zu 365 Tage über DCD, 100 Jahre über API); die Unveränderlichkeitsschicht der Plattform.
• Logisches Dump/Restore: Export/Import auf Engine-Ebene (pg_dump/pg_restore/psql, mariadb-dump), das eine portierbare, versionstolerante Datenbankkopie erzeugt und zugleich der einzige Migrationspfad für verwaltete Datenbanken ist.

Weitere Lektüre

• Einheit 5.2: Object Storage (Object Lock, Lebenszyklus, Unveränderbarkeit und Archivschicht)
• Einheit 5.3: Relationale Datenbanken (PITR-Fenster, Dump/Restore, Replikationsmodus-RPO)
• Einheit 7.1: Resilienz und Business Continuity (Trennung der Datenkontinuitätsebene von der Verkehrssteuerungsebene; RTO/RPO-Anker)