Einheit 5.7: Datensicherung und Lebenszyklus

Einführung

Es gibt kein einzelnes "Sichern aller Daten" Produkt auf IONOS Cloud, und die Behandlung eines Primitivs, als ob es jeden Workload abdeckt, ist der häufigste Daten-Schutz-Designfehler auf der Plattform. Jedes Primitive schützt eine bestimmte Fehlerklasse, und drei davon haben Grenzen, die, wenn sie verpasst werden, eine Ebene stillschweigend ungeschützt lassen. Das Backup Service berührt keine gemanagten Datenbanken. Ein Snapshot ist ein Rückgabepunkt und kein konsistenter Datenbank-Backup. Und das Backup Service bietet keine Unveränderlichkeit. Diese Einheit behandelt diese Grenzen als die Design-Eingaben, die sie sind, und komponiert die Primitiven zu einer Kontinuitätsebene für FinCorp.

1. Die Vier Primitiven und die Grenzen, die sie trennen

Jedes der vier Daten-Schutzmechanismen beantwortet eine andere Wiederherstellungsfrage. Die Fähigkeit besteht darin, den Mechanismus auf das Workload abzustimmen, und nicht nach dem zu greifen, was am vertrautesten ist.

1.1 Das Backup Service: Umfang und was es nicht ist

Das Backup Service ist das agentenbasierte Schutzprodukt, das von Acronis Cyber Protect unterstützt wird. Sie installieren einen Agenten auf dem Workload, definieren einen Schutzplan und der Agent sendet verschlüsselte Daten an ein Speicherziel. Für Workloads in der Cloud sind die Zielworkloads IONOS Cloud Compute Engine-VMs (Dedicated Core, vCPU und Cubes), die aus öffentlichen Bildern (automatische Agenten-Installation) oder privaten Bildern (manuelle Installation) bereitgestellt werden. Das gleiche Produkt, in seiner externen Agenten-Variante, schützt auch On-Premises-Server, Arbeitsstationen, VMs in anderen öffentlichen Clouds, Hyper-V- und VMware-virtuelle Maschinen sowie macOS-Geräte, was es zum natürlichen Werkzeug für den Schutz eines Hybrid-Estates von einem Konsole aus während einer Migration macht.

Die Verschlüsselung ist solide: Daten während der Übertragung verwenden HTTPS und TLS, und Daten bei REST verwenden AES-256-Server-seitige Verschlüsselung, mit optionaler client-seitiger AES-256, die Sie pro Schutzplan mit einem Passwort aktivieren. Das Standard-Speicherziel ist Backup-Speicher, aber Sie können auch Sicherungen auf Object Storage (IONOS Cloud, S3-kompatibel oder andere vordefinierte Anbieter) oder Network File Storage umleiten.

Zwei Grenzen müssen klar ausgesprochen werden. Erstens unterstützt das Backup Service keine unveränderlichen Sicherungen. Wenn Ihr Steuerungsziel ein manipulationsicherer, schreibgeschützter Speicher (die Art, die eine Ransomware-Wiederherstellung oder eine Prüfung von Beweisen erfordert) ist, liefert das Backup Service allein dies nicht; Sie komponieren Unveränderlichkeit separat, auf Object Storage-Objekt-Sperre (Einheit 5.2). Zweitens gilt für den Compliance-Umfang: das Backup Service ist durch das BSI IT-Grundschutz ISO 27001-Zertifikat (deutsche Rechenzentren) abgedeckt, aber nicht im BSI C5-Attestationsumfang. C5 Typ 1 (2023-11-07) umfasst nur Compute Engine, Cloud Cubes und Object Storage. Für FinCorp unter BSI ist diese Unterscheidung vertraglich, nicht kosmetisch: eine Sicherung einer C5-umfassten Workload erbt C5 nicht, nur weil die Quelle dies tat.

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

Ein Block Storage-Snapshot erfasst den Zustand eines einzelnen bereitgestellten Block Storage-Geräts zu einem bestimmten Zeitpunkt. Snapshots funktionieren auf 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 OS-Patch oder einem Anwendungs-Upgrade, und sie paaren sich natürlich mit den Migrations-Wellen-Validierungstoren, die in Modul 7 gelehrt werden.

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

• Nicht inkrementell. Jeder Snapshot ist eine separate, unabhängige Instanz, die den vollständigen Zustand der Quell-Volume darstellt. Es gibt keine inkrementelle Kette; ein Snapshot eines 100 GiB-Volume, das 10 GiB Daten enthält, erzeugt immer noch ein 100 GiB-Snapshot, einschließlich Blöcken, die keine Daten enthalten. Ein wiederhergestelltes größeres Volume kann nach dem Booten des VM und dem Einbinden des Volume möglicherweise eine manuelle Partitionserweiterung benötigen.
• Region-lokal. Ein Snapshot lebt in der Region seiner Quell-Volume. Es schützt nicht vor einem regionsspezifischen Ereignis und kann nicht allein eine cross-regionale Wiederherstellung durchführen. Für cross-regionale Ausfallsicherheit kopieren Sie die geschützten Daten auf Object Storage.
• Manuelle Lebensdauer. Snapshots werden beibehalten, bis Sie sie löschen. Es gibt keine automatische Ablaufzeit, sodass eine unverwaltete Snapshot-Bevölkerung zu einer stillen Kostenlinie (Snapshots verbrauchen HDD-Kontingent) und einer Governance-Lücke wird.

Die Grenze, die hier am meisten zählt: ein Snapshot ist ein konsistenter Blockgeräte-Image, kein anwendungskonsistenter oder datenbankkonsistenter Backup. Die Erstellung eines Snapshot des Volume unter einer laufenden gemanagten Datenbank ist kein unterstütztes Datenbank-Backup-Verfahren und wird nicht zuverlässig zu einem transaktionskonsistenten Zustand wiederherstellen. Die Datenbank-Kontinuität hat ihr eigenes Primitiv, das im nächsten Abschnitt behandelt wird.

1.3 Die Datenbank-Grenze: PITR plus Dump/Wiederherstellung

Die wichtigste Grenze in dieser Einheit: das Backup Service sichert keine gemanagten Datenbanken. Auch Snapshots dienen nicht als deren Backup. Die Datenbank-Kontinuität bei IONOS wird innerhalb des Datenbank-Dienstes selbst durch zwei native Mechanismen bereitgestellt.

Der erste ist die point-in-time-Wiederherstellung (PITR). Managed PostgreSQL automatisiert kontinuierliche Sicherungen in einem verschlüsselten IONOS Cloud Object Storage-Bucket in der gleichen Region (Datenbanken in Regionen ohne IONOS Object Storage werden in eu-central-2 gesichert), und der Sicherungsspeicherort ist unveränderlich. Das PITR-Fenster beträgt 7 Tage für PostgreSQL standardmäßig, und auf PostgreSQL ist die Aufbewahrungsfrist von 1 bis 365 Tagen über backup.retentionDays konfigurierbar; lehren Sie nicht 7 als harte Grenze, es ist der Standard. Managed MariaDB bietet eine 7-tägige PITR-Aufbewahrungsfrist. Die Wiederherstellung wird durch reale Einschränkungen gesteuert, die Sie entwerfen müssen: nur eine Sicherung kann gleichzeitig wiederhergestellt werden, die Cluster muss VERFÜGBAR sein, Sie können von der gleichen oder einer älteren Hauptversion wiederherstellen, eine Wiederherstellung kann eine Datenbank in eine andere Region verschieben, und recoveryTargetTime ist nicht einschließlich. Das Wiederherstellungsziel ist im schlimmsten Fall nicht verlustfrei: wenn alle Replikate gleichzeitig Daten verlieren, beträgt das potenzielle Datenverlustfenster bis zu 30 Minuten oder 16 MB.

Der zweite ist die logische Dump/Wiederherstellung, der gleiche Mechanismus, der als einziger Migrationspfad in diese Dienste dient. Für PostgreSQL sind die Tools pg_dump, pg_restore und psql; für MariaDB ist es mariadb-dump. Eine periodische logische Dump, die in Object Storage gelandet ist, gibt Ihnen eine portable, motorversionstolerante Kopie, die außerhalb der Cluster überlebt, was genau das ist, was PITR (gebunden an den eigenen unveränderlichen Sicherungsspeicher der Cluster) nicht bietet.

Die Datenbank-Wiederherstellungs-Entwurf ist also geschichtet: PITR für fein granulierte Rollback innerhalb des Aufbewahrungszeitraums und geplante logische Dumps auf Object Storage für langfristige, portable und (mit Objekt-Sperre) manipulationsichere Aufbewahrung.

2. Zusammensetzen einer Daten-Continuitätsebene

Kein einzelnes Primitiv ist eine Continuitätsebene. Die Ebene entsteht, wenn Sie jeder Workload-Ebene den Mechanismus zuweisen, der zu ihrer Fehlerklasse und ihrem Wiederherstellungsziel passt, und dann Object Storage als gemeinsame Archiv- und Unveränderlichkeitsebene hinzufügen.

Die folgende Tabelle kartiert die Fehlerklasse, die jedes Primitiv tatsächlich abdeckt.

Zwei Zusammensetzungsregeln ergeben sich aus dieser Tabelle. Erstens ist Unveränderlichkeit eine Eigenschaft von Object Storage, nicht von Backup Service: Wenn eine Ebene eine schreibgeschützte Aufbewahrung benötigt, muss die Wiederherstellungskopie in einem objektsperren Bucket landen, egal ob es sich um ein Backup Service-Ziel, eine exportierte Snapshot-Daten oder eine Datenbank-Dump handelt. Die Objektsperre unterstützt GOVERNANCE- und COMPLIANCE-Modi, mit einer Aufbewahrungsfrist von bis zu 365 Tagen im DCD und bis zu 100 Jahren über den API. Zweitens wird die Cross-Region-Dauerhaftigkeit erreicht, indem eine Kopie in Object Storage gespeichert wird, da sowohl Snapshots als auch PITR-Sicherungsspeicher regionsspezifisch sind.

Unternehmensfallstudie (FinCorp)

Das regulierte Anwesen von FinCorp umfasst die migrierten VMware-Workloads, ein Managed PostgreSQL-Cluster hinter der Anwendungsebene und das in Modul 2 eingerichtete Audit-Archiv. Unter BSI und GDPR ist die Anforderung nicht "alles sichern", sondern eine verteidigbare, pro-Ebene-Wiederherstellungsstrategie mit manipulationsbeweisbaren Beweisen, wo dies vorgeschrieben ist.

Die Computerebene (die migrierten und IONOS-nativen VMs) wird durch das Backup Service geschützt. Während der Migration ist dies doppelt nützlich: die externen-Agent-Variante schützt die lokalen VMs während des Umstiegs von der gleichen Konsole, die später auch die IONOS-VMs schützen wird. Da das Backup Service keine Unveränderlichkeit bietet, leitet FinCorp die Ransomware-Wiederherstellungskopien an ein Object Storage-Ziel mit Objekt-Sperre im COMPLIANCE-Modus weiter, sodass die Beweiskopie nicht innerhalb ihrer Aufbewahrungsfrist geändert oder gelöscht werden kann. Die riskanten Schritte während des Umstiegs erhalten einen Snapshot-Rückgabepunkt sofort davor, wobei anerkannt wird, dass Snapshots regionale und kurzlebige Arbeitsartefakte sind und nicht das Archiv.

Das PostgreSQL-Cluster wird absichtlich vom Backup Service ausgeschlossen, da dies die Plattformgrenze ist. Seine Kontinuität wird durch PITR für das 7-Tage-Operationssfenster sowie eine nächtliche pg_dump-Lieferung an einen objektsperren Bucket für die langfristige, portable, audit-gerechte Kopie sichergestellt. Das 30-Minuten-/16-MB-Schadensfenster mit dem schlechtesten Fall wird als das Cluster-akzeptierte RPO dokumentiert und mit dem in Einheit 7.1 übernommenen Geschäft-RPO abgestimmt. Das Audit-Archiv selbst befindet sich bereits in objektsperren Object Storage aus Einheit 2.3. Das Ergebnis ist eine Kontinuitätsebene: unterschiedliche Mechanismen pro Ebene, Object Storage als gemeinsame unveränderliche Grundlage und keine Ebene, die stillschweigend auf eine Primitive vertraut, die sie nicht abdeckt.

Entscheidungszusammenfassung

Wählen Sie den Schutzmechanismus nach der Workload-Ebene und dem Wiederherstellungsziel, nicht nach der Vertrautheit.

Harte Einschränkungen, die weitergeführt werden müssen: die Backup Service schließt gemanagte Datenbanken aus und bietet keine immutablen Sicherungen; Snapshots sind nicht inkrementell, regionsspezifisch, manuell aufbewahrt und nicht datenbankkonsistent; PITR ist fenstergebunden und regionsspezifisch; Immutabilität und Cross-Region-Haltbarkeit werden auf Object Storage erreicht.

Zusammenfassung

IONOS-Datenschutz ist eine Sammlung von einzelnen, zweckgebundenen Primitiven, von denen jedes eine harte Grenze hat, die Sie zu einer Kontinuitätsebene komponieren, anstatt ein einzelnes Backup-Produkt zu verwenden. Das Backup Service schützt virtuelle Maschinen und Block Storage (und Hybrid-Besitztümer), aber nicht gemanagte Datenbanken und nicht mit unveränderlichen Backups. Snapshots sind schnelle, regionale Rückgabepunkte, keine Datenbank-Backups. Gemanagte Datenbanken werden durch ihre eigene PITR (Point-in-time-Wiederherstellung) plus portable Dump-/Wiederherstellungsmechanismen wiederhergestellt. Das Object Storage-Objekt-Sperre liefert die Unveränderlichkeit und die archivierende Schicht über Regionen hinweg, die den anderen fehlt. Weisen Sie einen Mechanismus pro Tier nach Fehlerklasse zu und lassen Sie Object Storage die gemeinsame Grundlage sein.

Wichtige Punkte:

• Das Backup Service (Acronis) deckt virtuelle Maschinen und Block Storage ab, einschließlich On-Premises- und anderen Cloud-virtuellen Maschinen über den externen Agenten, aber es sichert explizit keine gemanagten Datenbanken und unterstützt keine unveränderlichen Backups.
• Block Storage-Snapshots sind vollständige, nicht inkrementelle, regionale, manuell beibehaltene VM-Ebene-Rückgabepunkte, keine konsistenten Datenbank-Backups.
• Die Kontinuität gemanagter Datenbanken ist nativ: PITR (PostgreSQL 7-Tage-Standard, konfigurierbar 1-365; MariaDB 7-Tage) für die Wiederherstellung innerhalb eines Zeitfensters, sowie logische Dump-/Wiederherstellungsmechanismen für portable, langfristige Kopien.
• Unveränderlichkeit und cross-regionale Ausfallsicherheit sind Eigenschaften von Object Storage (Objekt-Sperre GOVERNANCE / COMPLIANCE), die unter der Wiederherstellungskopie komponiert werden, die sie benötigt.
• Die Compliance ist pro Dienst: das Backup Service befindet sich unter IT-Grundschutz ISO 27001, nicht unter der BSI-C5-Zertifizierung, sodass ein Backup den Umfang der Quelle Workload nicht erbt.

Wichtige Begriffe:

• Point-in-time-Wiederherstellung (PITR): Kontinuierliche Datenbank-Sicherung in einem unveränderlichen, gleichen regionalen Object Storage-Speicher, die es ermöglicht, zu jedem Zeitstempel innerhalb des Aufbewahrungszeitraums wiederherzustellen. Der Aufbewahrungszeitraum ist begrenzt und es handelt sich nicht um eine portable Kopie.
• Objekt-Sperre: Object Storage-Schreibschutz mit Leserechten in GOVERNANCE- oder COMPLIANCE-Modus (bis zu 365 Tagen über DCD, 100 Jahre über API). Dies ist die Unveränderlichkeitsebene der Plattform.
• Logische Dump-/Wiederherstellung: Engine-ebene Export/Import (pg_dump/pg_restore/psql, mariadb-dump), die eine portable, versionstolerante Datenbankkopie erzeugt, die auch als einziger gemanagter Datenbank-Migrationspfad dient.

Weitere Lektüre

• Einheit 5.2: Object Storage (Objektsperre, Lebenszyklus, die Unveränderlichkeit und Archivschicht)
• Einheit 5.3: Relationale Datenbanken (PITR-Fenster, Dump/Wiederherstellung, Replikationsmodus RPO)
• Einheit 7.1: Widerstandsfähigkeit und Geschäftskontinuität (Trennung der Datenkontinuitätsebene von der Verkehrssteuerungsebene, RTO/RPO-Anker)