Backup-to-Object-Richtlinienoptionen in BlueXP Backup und Recovery
Mit BlueXP backup and recovery können Sie Sicherungsrichtlinien mit einer Vielzahl von Einstellungen für Ihre lokalen ONTAP und Cloud Volumes ONTAP Systeme erstellen.
|
Diese Richtlinieneinstellungen sind nur für den Objekt-Storage relevant. Keine dieser Einstellungen wirkt sich auf Ihre Snapshot- oder Replikationsrichtlinien aus. |
HINWEIS Informationen zum Umschalten zwischen BlueXP backup and recovery -Workloads finden Sie unter "Wechseln Sie zu verschiedenen BlueXP backup and recovery -Workloads" .
Optionen für den Backup-Zeitplan
Mit BlueXP Backup und Recovery können Sie mehrere Backup-Richtlinien mit eindeutigen Zeitplänen für jede Arbeitsumgebung (Cluster) erstellen. Sie können Volumes mit unterschiedlichen Recovery-Punkten (RPO) unterschiedliche Backup-Richtlinien zuweisen.
Jede Sicherungsrichtlinie enthält einen Abschnitt für Labels & Retention, den Sie auf Ihre Sicherungsdateien anwenden können. Die auf das Volume angewendete Snapshot-Richtlinie muss eine der Richtlinien sein, die von BlueXP Backup- und Recovery- oder Backup-Dateien erkannt werden. Sie wird dann nicht erstellt.
Es gibt zwei Teile des Zeitplans: Das Etikett und der Aufbewahrungswert:
-
Die Bezeichnung definiert, wie oft eine Sicherungsdatei aus dem Volume erstellt (oder aktualisiert) wird. Sie können eine der folgenden Beschriftungstypen auswählen:
-
Sie können eine oder eine Kombination aus, stündlich, täglich, wöchentlich, monatlich, Und jährliche Zeitrahmen.
-
Sie können eine der vom System definierten Richtlinien auswählen, die Backup und Aufbewahrung für 3 Monate, 1 Jahr oder 7 Jahre bieten.
-
Wenn Sie im Cluster benutzerdefinierte Backup-Sicherungsrichtlinien mit ONTAP System Manager oder der ONTAP CLI erstellt haben, können Sie eine dieser Richtlinien auswählen.
-
-
Der Wert Retention definiert, wie viele Sicherungsdateien für jedes Etikett (Zeitrahmen) aufbewahrt werden. Sobald die maximale Anzahl von Backups in einer Kategorie oder Intervall erreicht wurde, werden ältere Backups entfernt, sodass Sie immer über die aktuellsten Backups verfügen. Dies spart auch Storage-Kosten, da veraltete Backups nicht mehr Speicherplatz in der Cloud belegen.
Beispiel: Erstellen Sie eine Backup Policy, die 7 wöchentlich und 12 monatlich Backups erstellt:
-
Jede Woche und jeden Monat wird eine Sicherungsdatei für das Volume erstellt
-
In der 8. Woche wird das erste wöchentliche Backup entfernt, und das neue wöchentliche Backup für die 8. Woche wird hinzugefügt (maximal 7 wöchentliche Backups bleiben erhalten)
-
Am 13. Monat wird das erste monatliche Backup entfernt, und das neue monatliche Backup für den 13. Monat wird hinzugefügt (maximal 12 monatliche Backups)
Jährliche Backups werden nach der Übertragung in den Objektspeicher automatisch aus dem Quellsystem gelöscht. Dieses Standardverhalten kann auf der Seite „Erweiterte Einstellungen“ der Arbeitsumgebung geändert werden.
DataLock- und Ransomware-Schutzoptionen
BlueXP Backup und Recovery bietet Unterstützung für DataLock und Ransomware-Schutz für Ihre Volume-Backups. Mit diesen Funktionen sperren Sie Ihre Backup-Dateien und scannen sie, um mögliche Ransomware auf den Backup-Dateien zu erkennen. Dies ist eine optionale Einstellung, die Sie in Ihren Backup-Richtlinien definieren können, wenn Sie zusätzliche Sicherheit für Ihre Volume-Backups für ein Cluster wünschen.
Beide Funktionen schützen Ihre Backup-Dateien, sodass Sie bei einem Ransomware-Angriff auf Ihre Backups immer über eine gültige Backup-Datei verfügen, von der Sie Daten wiederherstellen können. Darüber hinaus hilft es bei der Einhaltung bestimmter gesetzlicher Vorgaben, bei denen Backups für einen bestimmten Zeitraum gesperrt und aufbewahrt werden müssen. Wenn die Option DataLock und Ransomware-Schutz aktiviert ist, sind für den Cloud-Bucket, der als Teil der Backup- und Recovery-Aktivierung von BlueXP bereitgestellt wird, Objektsperrung und Objektversionierung aktiviert.
Diese Funktion bietet keinen Schutz für Ihre Quell-Volumes, sondern nur für die Backups dieser Quell-Volumes. Verwenden Sie einige der "Ransomware-Schutz durch ONTAP" um Ihre Quellvolumes zu schützen.
|
|
Was ist DataLock
Mit dieser Funktion können Sie die über SnapMirror in die Cloud replizierten Cloud-Snapshots sperren und die Funktion aktivieren, um einen Ransomware-Angriff zu erkennen und eine konsistente Kopie des Snapshots im Objektspeicher wiederherzustellen. Diese Funktion wird von AWS, Azure und StorageGRID unterstützt.
DataLock schützt Ihre Sicherungsdateien vor einer bestimmten Zeit, die auch unveränderlicher Speicher genannt wird. Diese Funktionalität nutzt Technologie des Objekt-Storage-Providers zur „Objektsperrung“.
Cloud-Anbieter verwenden ein Aufbewahrungsdatum (RUD), das auf Grundlage der Snapshot-Aufbewahrungsdauer berechnet wird. Die Snapshot-Aufbewahrungsdauer wird anhand der Bezeichnung und der in der Sicherungsrichtlinie definierten Aufbewahrungsdauer berechnet.
Die Mindestaufbewahrungsdauer für Snapshots beträgt 30 Tage. Sehen wir uns einige Beispiele an, wie das funktioniert:
-
Wenn Sie die Bezeichnung Täglich mit der Aufbewahrungsanzahl 20 wählen, beträgt die Aufbewahrungsdauer des Snapshots 20 Tage, standardmäßig also mindestens 30 Tage.
-
Wenn Sie die Bezeichnung Wöchentlich mit der Aufbewahrungsanzahl 4 wählen, beträgt die Aufbewahrungsdauer des Snapshots 28 Tage, standardmäßig also mindestens 30 Tage.
-
Wenn Sie die Bezeichnung Monatlich mit der Aufbewahrungsanzahl 3 wählen, beträgt die Aufbewahrungsdauer des Snapshots 90 Tage.
-
Wenn Sie die Bezeichnung Jährlich mit der Aufbewahrungsanzahl 1 wählen, beträgt die Aufbewahrungsdauer des Snapshots 365 Tage.
Was ist das Retention Until Date (RUD) und wie wird es berechnet?
Das Aufbewahrungsdatum (RUD) wird basierend auf der Snapshot-Aufbewahrungsfrist bestimmt. Das Aufbewahrungsdatum wird durch die Summe der Snapshot-Aufbewahrungsdauer und eines Puffers berechnet.
-
Der Puffer ist der Puffer für die Übertragungszeit (3 Tage) + Puffer für die Kostenoptimierung (28 Tage), was insgesamt 31 Tage ergibt.
-
Das Mindestaufbewahrungsdatum beträgt 30 Tage + 31 Tage Puffer = 61 Tage.
Hier einige Beispiele:
-
Wenn Sie einen monatlichen Sicherungszeitplan mit 12 Aufbewahrungszeiten erstellen, werden Ihre Sicherungen 12 Monate (plus 31 Tage) lang gesperrt, bevor sie gelöscht (durch die nächste Sicherungsdatei ersetzt) werden.
-
Wenn Sie eine Sicherungsrichtlinie erstellen, die 30 tägliche, 7 wöchentliche und 12 monatliche Sicherungen erstellt, gibt es drei gesperrte Aufbewahrungszeiträume:
-
Die „30 täglichen“ Backups werden 61 Tage lang aufbewahrt (30 Tage plus 31 Tage Puffer),
-
Die "7 wöchentlichen" Backups werden 11 Wochen lang (7 Wochen plus 31 Tage) aufbewahrt und
-
Die „12 monatlichen“ Backups werden 12 Monate (plus 31 Tage) aufbewahrt.
-
-
Wenn Sie einen stündlichen Backup-Zeitplan mit 24 Aufbewahrung erstellen, könnten Sie denken, dass Backups für 24 Stunden gesperrt sind. Da dies jedoch weniger als 30 Tage beträgt, wird jedes Backup für 61 Tage gesperrt und aufbewahrt (30 Tage plus 31 Tage Puffer).
|
Alte Sicherungen werden nach Ablauf der DataLock-Aufbewahrungsfrist gelöscht, nicht nach Ablauf der Aufbewahrungsfrist der Sicherungsrichtlinie. |
Die DataLock-Aufbewahrungseinstellung überschreibt die Richtlinienaufbewahrungseinstellung Ihrer Sicherungsrichtlinie. Dies könnte sich auf Ihre Storage-Kosten auswirken, da Backup-Dateien über einen längeren Zeitraum im Objektspeicher gespeichert werden.
Aktivieren Sie DataLock und Ransomware-Schutz
Sie können DataLock und Ransomware-Schutz beim Erstellen einer Richtlinie aktivieren. Nach der Erstellung der Richtlinie können Sie diese nicht mehr aktivieren, ändern oder deaktivieren.
-
Erweitern Sie beim Erstellen einer Richtlinie den Abschnitt DataLock- und Ransomware-Schutz.
-
Folgenden Optionen wählbar:
-
Keine: DataLock-Schutz und Ransomware-Schutz sind deaktiviert.
-
Entsperrt: DataLock-Schutz und Ransomware-Schutz sind aktiviert. Benutzer mit entsprechenden Berechtigungen können geschützte Sicherungsdateien während der Aufbewahrungsfrist überschreiben oder löschen.
-
Gesperrt: DataLock-Schutz und Ransomware-Schutz sind aktiviert. Während der Aufbewahrungsfrist können Benutzer geschützte Sicherungsdateien nicht überschreiben oder löschen. Dies gewährleistet die Einhaltung aller gesetzlichen Vorschriften.
-
Was ist Ransomware-Schutz
Ransomware-Schutz scannt Ihre Backup-Dateien, um einen Ransomware-Angriff auf einen Nachweis zu untersuchen. Die Erkennung von Ransomware-Angriffen erfolgt über einen Prüfsummenvergleich. Wenn potenzielle Ransomware-Angriffe in einer neuen Backup-Datei oder in einer vorherigen Backup-Datei erkannt werden, wird diese neuere Backup-Datei durch die neueste Backup-Datei ersetzt, die keine Anzeichen eines Ransomware-Angriffs zeigt. (Die Datei, die als Ransomware-Angriff gekennzeichnet ist, wird 1 Tag nach ihrer Ersetzung gelöscht.)
Scans werden in folgenden Situationen durchgeführt:
-
Scans von Cloud-Backup-Objekten werden kurz nach der Übertragung in den Cloud-Objektspeicher gestartet. Der Scan wird nicht beim ersten Schreiben der Backup-Datei in den Cloud-Speicher durchgeführt, sondern beim Schreiben der nächsten Backup-Datei.
-
Ransomware-Scans können gestartet werden, wenn das Backup für den Wiederherstellungsprozess ausgewählt wird.
-
Scans können jederzeit auf Anfrage durchgeführt werden.
Wie funktioniert der Wiederherstellungsprozess?
Wenn ein Ransomware-Angriff erkannt wird, startet der Dienst mithilfe der Active Data Connector Integrity Checker REST API den Wiederherstellungsprozess. Die älteste Version der Datenobjekte dient als Quelle der Wahrheit und wird im Rahmen des Wiederherstellungsprozesses in die aktuelle Version umgewandelt.
Sehen wir uns an, wie das funktioniert:
-
Im Falle eines Ransomware-Angriffs versucht der Dienst, das Objekt im Bucket zu überschreiben oder zu löschen.
-
Da der Cloud-Speicher versionierungsfähig ist, wird automatisch eine neue Version des Sicherungsobjekts erstellt. Wird ein Objekt bei aktivierter Versionsverwaltung gelöscht, wird es als gelöscht markiert, ist aber weiterhin abrufbar. Wird ein Objekt überschrieben, bleiben vorherige Versionen erhalten und markiert.
-
Beim Start eines Ransomware-Scans werden die Prüfsummen beider Objektversionen validiert und verglichen. Sind die Prüfsummen inkonsistent, wurde potenzielle Ransomware erkannt.
-
Der Wiederherstellungsprozess umfasst die Rückkehr zur letzten bekannten funktionierenden Kopie.
Unterstützte Arbeitsumgebungen und Objekt-Storage-Anbieter
Bei Verwendung von Objekt-Storage bei den folgenden Public- und Private-Cloud-Providern können Sie die DataLock- und Ransomware-Sicherung auf ONTAP Volumes aus den folgenden Arbeitsumgebungen aktivieren. Weitere Cloud-Provider werden in zukünftigen Versionen hinzugefügt.
Quelle Arbeitsumgebung | Ziel der Backup-Datei ifdef::aws[] |
---|---|
Cloud Volumes ONTAP in AWS |
Amazon S3 endif::aws[] ifdef::Azure[] |
Cloud Volumes ONTAP in Azure |
Azure Blob endif::Azure[] ifdef::gcp[] endif::gcp[] |
Lokales ONTAP System |
Ifdef::aws[] Amazon S3 endif::aws[] ifdef::azurAzure[] Azure Blob endif::Azure[] ifdef::gcp[] endif::gcp[] NetApp StorageGRID |
Anforderungen
-
Für AWS:
-
Ihre Cluster müssen ONTAP 9.11.1 oder höher ausführen
-
Der Connector kann in der Cloud oder vor Ort bereitgestellt werden
-
Die folgenden S3-Berechtigungen müssen Teil der IAM-Rolle sein, die dem Connector Berechtigungen erteilt. Sie befinden sich im Abschnitt „BackupS3Policy“ für die Ressource „arn:aws:s3::netapp-Backup-*“:
AWS S3 Berechtigungen
-
s3:GetObjectVersionTagging
-
s3:GetBucketObjectLockConfiguration
-
s3:GetObjectVersionAkl
-
s3:PuttObjectTagging
-
s3:DeleteObject
-
s3:DeleteObjectTagging
-
s3:GetObjectRetention
-
s3:DeleteObjectVersionTagging
-
s3:PutObject
-
s3:GetObject
-
s3:PutBucketObjectLockConfiguration
-
s3:GetLifecycleKonfiguration
-
s3:GetBucketTagging
-
s3:DeleteObjectVersion
-
s3:ListBucketVersions
-
s3:ListBucket
-
s3:PutBucketTagging
-
s3:GetObjectTagging
-
s3:PutBucketVersionierung
-
s3:PuttObjectVersionTagging
-
s3:GetBucketVersionierung
-
s3:GetBucketAcl
-
s3:BypassGovernanceAufbewahrung
-
s3:PutObjectRetention
-
s3:GetBucketLocation
-
s3:GetObjectVersion
-
-
-
Für Azure:
-
Ihre Cluster müssen ONTAP 9.12.1 oder höher ausführen
-
Der Connector kann in der Cloud oder vor Ort bereitgestellt werden
-
-
Für StorageGRID:
-
Ihre Cluster müssen ONTAP 9.11.1 oder höher ausführen
-
Auf Ihren StorageGRID Systemen muss 11.6.0.3 oder höher ausgeführt werden
-
Der Connector muss auf Ihrem Gelände bereitgestellt werden (er kann auf einer Website mit oder ohne Internetzugang installiert werden).
-
Die folgenden S3-Berechtigungen müssen Teil der IAM-Rolle sein, die dem Connector Berechtigungen bereitstellt:
StorageGRID S3 Berechtigungen
-
s3:GetObjectVersionTagging
-
s3:GetBucketObjectLockConfiguration
-
s3:GetObjectVersionAkl
-
s3:PuttObjectTagging
-
s3:DeleteObject
-
s3:DeleteObjectTagging
-
s3:GetObjectRetention
-
s3:DeleteObjectVersionTagging
-
s3:PutObject
-
s3:GetObject
-
s3:PutBucketObjectLockConfiguration
-
s3:GetLifecycleKonfiguration
-
s3:GetBucketTagging
-
s3:DeleteObjectVersion
-
s3:ListBucketVersions
-
s3:ListBucket
-
s3:PutBucketTagging
-
s3:GetObjectTagging
-
s3:PutBucketVersionierung
-
s3:PuttObjectVersionTagging
-
s3:GetBucketVersionierung
-
s3:GetBucketAcl
-
s3:PutObjectRetention
-
s3:GetBucketLocation
-
s3:GetObjectVersion
-
-
Einschränkungen
-
Die Data Lock- und Ransomware-Schutzfunktion ist nicht verfügbar, wenn Sie in der Backup-Richtlinie Archivspeicher konfiguriert haben.
-
Die bei der Aktivierung von BlueXP ausgewählte DataLock Option für Backup und Recovery muss für alle Backup-Richtlinien für dieses Cluster verwendet werden.
-
Sie können nicht mehrere DataLock-Modi auf einem einzelnen Cluster verwenden.
-
Wenn Sie DataLock aktivieren, werden alle Volume-Backups gesperrt. Es können keine gesperrten und nicht gesperrten Volume-Backups für einen einzelnen Cluster kombiniert werden.
-
DataLock- und Ransomware-Schutz ist für neue Volume-Backups mit einer Backup-Richtlinie mit aktiviertem DataLock und Ransomware-Schutz anwendbar. Sie können diese Funktionen später über die Option Erweiterte Einstellungen aktivieren oder deaktivieren.
-
FlexGroup Volumes können DataLock- und Ransomware-Schutz nur verwenden, wenn ONTAP 9.13.1 oder höher verwendet wird.
Tipps zur Senkung von DataLock-Kosten
Sie können die Ransomware-Scan-Funktion aktivieren oder deaktivieren, während die DataLock-Funktion aktiv bleibt. Um zusätzliche Kosten zu vermeiden, können Sie geplante Ransomware-Scans deaktivieren. Auf diese Weise können Sie Ihre Sicherheitseinstellungen anpassen und Kosten durch den Cloud-Provider vermeiden.
Selbst wenn geplante Ransomware-Scans deaktiviert sind, können Sie bei Bedarf trotzdem On-Demand-Scans durchführen.
Sie können verschiedene Schutzstufen wählen:
-
DataLock ohne Ransomware-Scans: Bietet Schutz für Backup-Daten im Zielspeicher, die sich entweder im Governance- oder im Compliance-Modus befinden können.
-
Governance-Modus: Bietet Administratoren Flexibilität, geschützte Daten zu überschreiben oder zu löschen.
-
Compliance-Modus: Bietet vollständige Unlöschbarkeit bis zum Ablauf der Aufbewahrungsfrist. So lassen sich auch die strengsten Datensicherheitsanforderungen hochgradig regulierter Umgebungen erfüllen. Die Daten können während ihres Lebenszyklus nicht überschrieben oder geändert werden. Dies bietet den bestmöglichen Schutz für Ihre Backup-Kopien.
Microsoft Azure verwendet stattdessen einen Sperrmodus und einen Entsperrmodus.
-
-
DataLock mit Ransomware-Scans: Bietet eine zusätzliche Sicherheitsschicht für Ihre Daten. Diese Funktion hilft bei der Erkennung von Versuchen, Sicherungskopien zu ändern. Bei einem Versuch wird diskret eine neue Version der Daten erstellt. Die Scanfrequenz kann in 1, 2, 3, 4, 5 geändert werden. 6 oder 7 Tage. Werden Scans alle 7 Tage eingestellt, sinken die Kosten deutlich.
Weitere Tipps zur Senkung der DataLock-Kosten finden Sie unter https://community.netapp.com/t5/Tech-ONTAP-Blogs/Understanding-BlueXP-Backup-and-Recovery-DataLock-and-Ransomware-Feature-TCO/ba-p/453475
Darüber hinaus können Sie Schätzungen für die mit DataLock verbundenen Kosten erhalten, indem Sie die "BlueXP Rechner für Backup und Recovery für Gesamtbetriebskosten (TCO)".
Storage-Optionen für die Archivierung
Beim Einsatz von AWS, Azure oder Google Cloud Storage können Sie ältere Backup-Dateien nach einer bestimmten Anzahl von Tagen auf eine kostengünstigere Archiv-Storage-Klasse oder auf eine Zugriffs-Tier verschieben. Sie haben auch die Möglichkeit, die Backup-Dateien sofort in den Archiv-Storage zu senden, ohne dafür in standardmäßigen Cloud-Storage geschrieben zu werden. Geben Sie einfach 0 als "Archiv nach Tagen" ein, um Ihre Sicherungsdatei direkt an den Archivspeicher zu senden. Dies kann insbesondere für Benutzer nützlich sein, die selten auf Daten aus Cloud-Backups zugreifen müssen oder Benutzer, die eine Tape-Backup-Lösung ersetzen.
Auf Daten auf Archiv-Tiers kann bei Bedarf nicht sofort zugegriffen werden und die Abrufkosten sind höher. Daher müssen Sie berücksichtigen, wie häufig Daten aus Backup-Dateien wiederhergestellt werden müssen, bevor Sie sich für die Archivierung Ihrer Backup-Dateien entscheiden.
|
|
Jede Backup-Richtlinie enthält einen Abschnitt zur „ Archivierungsrichtlinie“, den Sie auf Ihre Backup-Dateien anwenden können.
-
In AWS beginnen Backups in der Klasse „ Standard Storage“ und wechseln nach 30 Tagen in die Storage-Klasse „ Standard-infrequent Access“.
Wenn Ihr Cluster ONTAP 9.10.1 oder höher verwendet, können Sie ältere Backups entweder auf S3 Glacier oder S3 Glacier Deep Archive Storage Tiering. "Weitere Informationen zu AWS Archiv-Storage".
-
Wenn Sie bei der Aktivierung von BlueXP Backup und Recovery in Ihrer ersten Backup-Richtlinie keinen Archiv-Tier auswählen, wird S3 Glacier Ihre einzige Archivierungsoption für zukünftige Richtlinien sein.
-
Wenn Sie in Ihrer ersten Backup-Richtlinie S3 Glacier auswählen, können Sie für zukünftige Backup-Richtlinien für diesen Cluster in die S3 Glacier Deep Archive-Ebene wechseln.
-
Wenn Sie in Ihrer ersten Backup-Richtlinie S3 Glacier Deep Archive auswählen, ist diese Tier die einzige Archiv-Tier, die für zukünftige Backup-Richtlinien für diesen Cluster verfügbar ist.
-
-
In Azure werden Backups im Zusammenhang mit der Cool Zugriffsebene durchgeführt.
Wenn Ihr Cluster ONTAP 9.10.1 oder höher verwendet, können Sie ältere Backups auf Azure Archive Storage Tiering. "Erfahren Sie mehr über Azure Archiv-Storage".
-
In GCP werden Backups der Klasse Standard Storage zugeordnet.
Wenn Ihr On-Premises-Cluster ONTAP 9.12.1 oder höher verwendet, haben Sie nach einer bestimmten Anzahl von Tagen die Möglichkeit, ältere Backups in der Backup- und Recovery-UI von BlueXP auf den Archiv Storage zu verschieben, um weitere Kosten zu optimieren. "Erfahren Sie mehr über Google Archivspeicher".
-
In StorageGRID sind Backups der Klasse Standard Storage zugeordnet.
Wenn Ihr On-Premises-Cluster ONTAP 9.12.1 oder höher verwendet und Ihr StorageGRID System mindestens 11.4 nutzt, können Sie ältere Backup-Dateien im Public-Cloud-Archiv-Storage archivieren.
+ ** bei AWS, können Sie Backups in AWS S3 Glacier oder S3 Glacier Deep Archive Storage Tiering. "Weitere Informationen zu AWS Archiv-Storage".
+ ** bei Azure, können Sie ältere Backups in Azure Archive Storage Tiering. "Erfahren Sie mehr über Azure Archiv-Storage".