Syntax und Beispiele für Backup-Richtlinien - AWS Organizations

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Syntax und Beispiele für Backup-Richtlinien

Auf dieser Seite wird die Syntax für Backup-Richtlinien beschrieben und durch Beispiele illustriert.

Syntax für Backup-Richtlinien

Eine Backup-Richtlinie ist eine Textdatei, die den JSON-Regeln entsprechend strukturiert ist. Die Syntax für Backup-Richtlinien folgt der Syntax für alle Verwaltungsrichtlinientypen. Eine umfassende Erläuterung dieser Syntax finden Sie unter Richtliniensyntax und Vererbung für Verwaltungsrichtlinientypen. Dieses Thema konzentriert sich auf die Anwendung dieser allgemeinen Syntax auf die spezifischen Anforderungen des Backup-Richtlinientyps.

Der Großteil einer Backup-Richtlinie besteht aus dem Backup-Plan und seinen Regeln. Die Syntax für den Backup-Plan innerhalb einer AWS Organizations Backup-Richtlinie ist strukturell identisch mit der Syntax, die von verwendet wird AWS Backup, aber die Schlüsselnamen unterscheiden sich. In den Beschreibungen der folgenden Richtlinienschlüsselnamen enthält jeder den entsprechenden AWS Backup Planschlüsselnamen. Weitere Informationen zu - AWS Backup Plänen finden Sie unter CreateBackupPlan im AWS Backup -Entwicklerhandbuch.

Anmerkung

Bei Verwendung von JSON werden doppelte Schlüsselnamen abgelehnt. Wenn Sie mehrere Pläne, Regeln oder Auswahlen in eine einzelne Richtlinie aufnehmen möchten, stellen Sie sicher, dass der Name jedes Schlüssels eindeutig ist.

Um vollständig und funktionsfähig zu sein, muss eine effektive Backup-Richtlinie mehr als nur einen Backupplan mit seinem Zeitplan und seinen Regeln enthalten. Die Richtlinie muss auch die AWS-Regionen und die zu sichernden Ressourcen sowie die AWS Identity and Access Management (IAM)-Rolle identifizieren, die zur Durchführung des Backups verwenden AWS Backup kann.

Die folgende funktionell vollständige Richtlinie zeigt die grundlegende Syntax von Backup-Richtlinien. Wenn dieses Beispiel direkt an ein -Konto angehängt wurde, AWS Backup sichert alle Ressourcen für dieses Konto in den eu-north-1 Regionen us-east-1 und RED , die das -Tag dataType mit dem Wert PII oder haben. Diese Ressourcen werden täglich um 5:00 Uhr in My_Backup_Vault gesichert und zudem wird eine Kopie in My_Secondary_Vault gespeichert. Beide Tresore befinden sich im gleichen Konto wie die Ressource. Es speichert auch eine Kopie des Backups im My_Tertiary_Vault in einem anderen, explizit angegebenen Konto. Die Tresore müssen bereits in jedem der angegebenen AWS-Regionen für jeden vorhanden sein AWS-Konto , der die effektive Richtlinie erhält. Wenn eine der gesicherten Ressourcen EC2-Instances sind, wird die Unterstützung für den Microsoft Volume Shadow Copy Service (VSS) für die Backups auf diesen Instances aktiviert. Der Backup wendet das Tag Owner:Backup auf jeden Wiederherstellungspunkt an.

{ "plans": { "PII_Backup_Plan": { "rules": { "My_Hourly_Rule": { "schedule_expression": {"@@assign": "cron(0 5 ? * * *)"}, "start_backup_window_minutes": {"@@assign": "60"}, "complete_backup_window_minutes": {"@@assign": "604800"}, "enable_continuous_backup": {"@@assign": false}, "target_backup_vault_name": {"@@assign": "My_Backup_Vault"}, "recovery_point_tags": { "Owner": { "tag_key": {"@@assign": "Owner"}, "tag_value": {"@@assign": "Backup"} } }, "lifecycle": { "move_to_cold_storage_after_days": {"@@assign": "180"}, "delete_after_days": {"@@assign": "270"} }, "copy_actions": { "arn:aws:backup:us-west-2:$account:backup-vault:My_Secondary_Vault": { "target_backup_vault_arn": { "@@assign": "arn:aws:backup:us-west-2:$account:backup-vault:My_Secondary_Vault" }, "lifecycle": { "move_to_cold_storage_after_days": {"@@assign": "180"}, "delete_after_days": {"@@assign": "270"} } }, "arn:aws:backup:us-east-1:$account:backup-vault:My_Tertiary_Vault": { "target_backup_vault_arn": { "@@assign": "arn:aws:backup:us-east-1:111111111111:backup-vault:My_Tertiary_Vault" }, "lifecycle": { "move_to_cold_storage_after_days": {"@@assign": "180"}, "delete_after_days": {"@@assign": "270"} } } } } }, "regions": { "@@append": [ "us-east-1", "eu-north-1" ] }, "selections": { "tags": { "My_Backup_Assignment": { "iam_role_arn": {"@@assign": "arn:aws:iam::$account:role/MyIamRole"}, "tag_key": {"@@assign": "dataType"}, "tag_value": { "@@assign": [ "PII", "RED" ] } } } }, "advanced_backup_settings": { "ec2": { "windows_vss": {"@@assign": "enabled"} } }, "backup_plan_tags": { "stage": { "tag_key": {"@@assign": "Stage"}, "tag_value": {"@@assign": "Beta"} } } } } }

Zur Syntax der Backup-Richtlinie gehören die folgenden Komponenten:

  • $account-Variablen – In bestimmten Textzeichenfolgen in den Richtlinien können Sie die $account-Variable verwenden, um das aktuelle AWS-Kontodarzustellen. Wenn einen Plan in der effektiven Richtlinie AWS Backup ausführt, ersetzt es diese Variable automatisch durch das aktuelle , AWS-Konto in dem die effektive Richtlinie und ihre Pläne ausgeführt werden.

    Wichtig

    Sie können die $account-Variable nur in Richtlinienelementen verwenden, die einen Amazon-Ressourcennamen (ARN) enthalten können, beispielsweise in Elementen, die den Backup-Tresor, in dem der Backup gespeichert werden soll, oder die IAM-Rolle mit Berechtigungen zum Ausführen der Sicherung angeben.

    Im Folgenden wird beispielsweise vorausgesetzt, dass in jeder , für die die Richtlinie gilt AWS-Konto , ein Tresor mit dem Namen My_Vault vorhanden ist.

    arn:aws:backup:us-west-2:$account:vault:My_Vault"

    Wir empfehlen Ihnen, AWS CloudFormation Stack-Sets und ihre Integration mit Organizations zu verwenden, um automatisch Backup-Tresore und IAM-Rollen für jedes Mitgliedskonto in der Organisation zu erstellen und zu konfigurieren. Weitere Informationen finden Sie unter Erstellen eines Stack-Sets mit selbstverwalteten Berechtigungen im AWS CloudFormation -Benutzerhandbuch.

  • Vererbungsoperatoren – Backup-Richtlinien können sowohl die wertbestimmenden Faktoren für die Vererbung als auch die untergeordneten Steuerungsoperatoren verwenden.

  • plans

    Der Schlüssel der obersten Ebene der Richtlinie ist der Schlüssel plans. Eine Backup-Richtlinie muss immer mit diesem festen Schlüsselnamen oben in der Richtliniendatei beginnen. Unter diesem Schlüssel können Sie einen oder mehrere Backup-Pläne haben.

  • Jeder Plan unter dem Schlüssel der obersten Ebene plans hat einen Schlüsselnamen, der aus dem vom Benutzer zugewiesenen Namen des Backup-Plans besteht. Im obigen Beispiel lautet der Name des Backup-Plans PII_Backup_Plan. In einer Richtlinie kann es mehrere Pläne geben, jeweils mit eigenen rules, regions, selections und tags.

    Dieser Schlüsselname des Backup-Plans in einer Backup-Richtlinie entspricht dem Wert des BackupPlanName Schlüssels in einem - AWS Backup Plan.

    Jeder Plan kann die folgenden Elemente enthalten:

    • rules – Dieser Schlüssel enthält eine Sammlung von Regeln. Jede Regel wird in eine geplante Aufgabe übersetzt, mit einer Startzeit und einem Fenster, in dem die durch die Elemente regions und selections in der effektiven Backup-Richtlinie angegebenen Ressourcen zu sichern sind.

    • regions – Dieser Schlüssel enthält eine Array-Liste von AWS-Regionen , deren Ressourcen durch diese Richtlinie gesichert werden können.

    • selections – Dieser Schlüssel enthält eine oder mehrere Sammlungen von Ressourcen (innerhalb der angegebenen regions), die durch die angegebenen rules gesichert werden.

    • advanced_backup_settings – Dieser Schlüssel enthält Einstellungen für Backups, die auf bestimmten Ressourcen ausgeführt werden.

    • backup_plan_tags – Gibt Tags an, die dem Backup-Plan selbst angefügt sind.

  • rules

    Der Richtlinienschlüssel rules wird dem Schlüssel Rules in einem AWS Backup -Plan zugeordnet. Unter dem Schlüssel rules kann es eine oder mehrere Regeln geben. Jede Regel wird zu einer geplanten Aufgabe zur Durchführung eines Backups der ausgewählten Ressourcen.

    Jede Regel enthält einen Schlüssel, dessen Name der Name der Regel ist. Im vorherigen Beispiel lautet der Regelname „My_Hourly_Rule“. Der Wert des Regelschlüssels ist die folgende Sammlung von Regelelementen:

    • schedule_expression – Dieser Richtlinienschlüssel wird dem ScheduleExpression Schlüssel in einem - AWS Backup Plan zugeordnet.

      Gibt die Startzeit des Backups an. Dieser Schlüssel enthält den @@assign Vererbungswert-Operator und einen Zeichenfolgewert mit einem CRON-Ausdruck, der angibt, wann einen Backup-Auftrag initiieren AWS Backup soll. Das allgemeine Format der CRON-Zeichenfolge lautet „cron( )“. Dabei ist jeweils eine Zahl oder ein Platzhalter angegeben. Bei Angabe von cron(0 5 ? * 1,3,5 *) beispielsweise wird die Sicherung jeden Montag, Mittwoch und Freitag um 5 Uhr morgens gestartet. Bei Angabe von cron(0 0/1 ? * * *) wird der Backup stündlich zur vollen Stunde an jedem Wochentag gestartet.

    • target_backup_vault_name – Dieser Richtlinienschlüssel wird dem TargetBackupVaultName Schlüssel in einem - AWS Backup Plan zugeordnet.

      Gibt den Namen des Backup-Tresors an, in dem der Backup gespeichert werden soll. Sie erstellen den Wert mithilfe von AWS Backup. Dieser Schlüssel enthält den @@assign -Vererbungswert-Operator und einen Zeichenfolgewert mit einem Tresornamen.

      Wichtig

      Der Tresor muss bereits vorhanden sein, wenn der Backup-Plan zum ersten Mal gestartet wird. Wir empfehlen Ihnen, AWS CloudFormation Stack-Sets und ihre Integration mit Organizations zu verwenden, um automatisch Backup-Tresore und IAM-Rollen für jedes Mitgliedskonto in der Organisation zu erstellen und zu konfigurieren. Weitere Informationen finden Sie unter Erstellen eines Stack-Sets mit selbstverwalteten Berechtigungen im AWS CloudFormation -Benutzerhandbuch.

    • start_backup_window_minutes – Dieser Richtlinienschlüssel wird dem StartWindowMinutes Schlüssel in einem - AWS Backup Plan zugeordnet.

      (Optional) Gibt an, wie viele Minuten gewartet werden soll, bevor eine Aufgabe abgebrochen wird, die nicht erfolgreich gestartet wurde. Dieser Schlüssel enthält den @@assign-Vererbungswert-Operator und einen Wert mit einer ganzzahligen Minutenangabe.

    • complete_backup_window_minutes – Dieser Richtlinienschlüssel wird dem Schlüssel CompletionWindowMinutes in einem AWS Backup -Plan zugeordnet.

      (Optional) Gibt an, nach wie vielen Minuten eine Backup-Aufgabe, die erfolgreich gestartet wurde, abgeschlossen werden muss oder von AWS Backupabgebrochen wird. Dieser Schlüssel enthält den @@assign-Vererbungswert-Operator und einen Wert mit einer ganzzahligen Minutenangabe.

    • enable_continuous_backup – Dieser Richtlinienschlüssel wird dem EnableContinuousBackup Schlüssel in einem - AWS Backup Plan zugeordnet.

      (Optional) Gibt an, ob kontinuierliche Backups AWS Backup erstellt. True bewirkt AWS Backup , dass kontinuierliche Backups erstellt, die point-in-time wiederhergestellt werden können (PITR). False (oder nicht angegeben), bewirkt AWS Backup , dass Snapshot-Backups erstellt.

      Anmerkung

      Da PITR-aktivierte Backups maximal 35 Tage aufbewahrt werden können, müssen Sie entweder False auswählen oder keinen Wert angeben, wenn Sie eine der folgenden Optionen festlegen:

      • Legen Sie für delete_after_days größer als 35 fest.

      • Legen Sie move_to_cold_storage_after_days auf einen beliebigen Wert fest.

      Weitere Informationen zu kontinuierlichen Backups finden Sie unter P-oint-in-time Wiederherstellung im AWS Backup -Entwicklerhandbuch.

    • lifecycle – Dieser Richtlinienschlüssel wird dem Lifecycle Schlüssel in einem - AWS Backup Plan zugeordnet.

      (Optional) Gibt an, wann dieses Backup in den Cold Storage AWS Backup überführt und wann es abläuft.

      • move_to_cold_storage_after_days – Dieser Richtlinienschlüssel wird dem MoveToColdStorageAfterDays Schlüssel in einem - AWS Backup Plan zugeordnet.

        Gibt an, wie viele Tage nach dem Backup AWS Backup den Wiederherstellungspunkt in den Cold Storage verschiebt. Dieser Schlüssel enthält den @@assign-Vererbungswert-Operator und einen Wert mit einer ganzzahligen Angabe der Tage.

      • delete_after_days – Dieser Richtlinienschlüssel wird dem DeleteAfterDays Schlüssel in einem - AWS Backup Plan zugeordnet.

        Gibt an, wie viele Tage nach dem Backup AWS Backup den Wiederherstellungspunkt löscht. Dieser Schlüssel enthält den @@assign-Vererbungswert-Operator und einen Wert mit einer ganzzahligen Angabe der Tage. Wenn Sie ein Backup in den Cold Storage übertragen, muss sie dort mindestens 90 Tage bleiben. Dieser Wert muss also mindestens um 90 Tage höher als der Wert für move_to_cold_storage_after_days sein.

    • copy_actions – Dieser Richtlinienschlüssel wird dem CopyActions Schlüssel in einem - AWS Backup Plan zugeordnet.

      (Optional) Gibt an, dass das Backup an einen oder mehrere zusätzliche Speicherorte kopieren AWS Backup soll. Jeder Speicherort der Backup-Kopie wird wie folgt beschrieben:

      • Ein Schlüssel, dessen Name diese Kopieraktion eindeutig kennzeichnet. Zu diesem Zeitpunkt muss der Schlüsselname dem Amazon-Ressourcennamen (ARN) des Backup-Tresors entsprechen. Dieser Schlüssel enthält zwei Einträge.

        • target_backup_vault_arn – Dieser Richtlinienschlüssel wird dem Schlüssel DestinationBackupVaultArn in einem AWS Backup -Plan zugeordnet.

          (Optional) Gibt den Tresor an, in dem eine zusätzliche Kopie des Backups AWS Backup speichert. Der Wert dieses Schlüssels enthält den Vererbungswert-Operator @@assign und den ARN des Tresors.

          • Um auf einen Tresor in der zu verweisen AWS-Konto , in der die Backup-Richtlinie ausgeführt wird, verwenden Sie die $account Variable im ARN anstelle der Konto-ID-Nummer. Wenn den Backup-Plan AWS Backup ausführt, ersetzt es die Variable automatisch durch die Konto-ID-Nummer des , AWS-Konto in dem die Richtlinie ausgeführt wird. Dadurch kann das Backup ordnungsgemäß ausgeführt werden, wenn die Backup-Richtlinie für mehr als ein Konto in einer Organisation gilt.

          • Um auf einen Tresor in einem anderen AWS-Konto in derselben Organisation zu verweisen, verwenden Sie die tatsächliche Konto-ID-Nummer im ARN.

          Wichtig
          • Wenn dieser Schlüssel fehlt, wird eine Version des ARN in Kleinbuchstaben im Namen des übergeordneten Schlüssels verwendet. Da bei ARNs die Groß-/Kleinschreibung beachtet wird, stimmt diese Zeichenfolge möglicherweise nicht mit dem tatsächlichen ARN des Fehlers überein und der Plan schlägt fehl. Aus diesem Grund raten wir davon ab, dass Sie diesen Schlüssel und Wert angeben.

          • Der Backup-Tresor, in den Sie das Backup kopieren möchten, muss beim ersten Start des Backup-Plans bereits vorhanden sein. Wir empfehlen Ihnen, AWS CloudFormation -Stack-Sets und ihre Integration mit Organizations zu verwenden, um automatisch Backup-Tresore und IAM-Rollen für jedes Mitgliedskonto in der Organisation zu erstellen und zu konfigurieren. Weitere Informationen finden Sie unter Erstellen eines Stack-Sets mit selbstverwalteten Berechtigungen im AWS CloudFormation -Benutzerhandbuch.

        • lifecycle – Dieser Richtlinienschlüssel wird dem Lifecycle Schlüssel unter dem CopyAction Schlüssel in einem - AWS Backup Plan zugeordnet.

          (Optional) Gibt an, wann diese Kopie eines Backups in den Cold Storage AWS Backup überführt und wann sie abläuft.

          • move_to_cold_storage_after_days – Dieser Richtlinienschlüssel wird dem Schlüssel MoveToColdStorageAfterDays in einem AWS Backup -Plan zugeordnet.

            Gibt die Anzahl der Tage nach dem Backup an, bevor den Wiederherstellungspunkt in den Cold Storage AWS Backup verschiebt. Dieser Schlüssel enthält den @@assign-Vererbungswert-Operator und einen Wert mit einer ganzzahligen Angabe der Tage.

          • delete_after_days – Dieser Richtlinienschlüssel wird dem Schlüssel DeleteAfterDays in einem AWS Backup -Plan zugeordnet.

            Gibt die Anzahl der Tage nach dem Backup an, bevor den Wiederherstellungspunkt AWS Backup löscht. Dieser Schlüssel enthält den @@assign-Vererbungswert-Operator und einen Wert mit einer ganzzahligen Angabe der Tage. Wenn Sie ein Backup in den Cold Storage übertragen, muss sie dort mindestens 90 Tage bleiben. Dieser Wert muss also mindestens um 90 Tage höher als der Wert für move_to_cold_storage_after_days sein.

    • recovery_point_tags – Dieser Richtlinienschlüssel wird dem RecoveryPointTags Schlüssel in einem - AWS Backup Plan zugeordnet.

      (Optional) Gibt Tags an, die an jedes Backup AWS Backup angefügt werden, das es aus diesem Plan erstellt. Der Wert dieses Schlüssels enthält eines oder mehrere der folgenden Elemente:

      • Einen Bezeichner für dieses Schlüsselname-Wert-Paar. Dieser Name für jedes Element unter recovery_point_tags ist der Tag-Schlüsselname in Kleinbuchstaben, auch wenn tag_key eine andere Groß-/Kleinschreibung hat. Bei diesem Bezeichner wird nicht zwischen Groß- und Kleinschreibung unterschieden. Im vorherigen Beispiel wurde dieses Schlüsselpaar durch den Namen Owner bezeichnet. Jedes Schlüsselpaar enthält die folgenden Elemente:

        • tag_key – Gibt den Tag-Schlüsselnamen an, der dem Backupplan angefügt werden soll. Dieser Schlüssel enthält den @@assign-Vererbungswert-Operator und einen Zeichenfolgewert. Beim -Wert ist die Groß- und Kleinschreibung zu beachten.

        • tag_value – Gibt den Wert an, der dem Backup-Plan angefügt und dem zugeordnet ist tag_key. Dieser Schlüssel enthält alle Vererbungswert-Operatoren sowie einen oder mehrere Werte, die in der effektiven Richtlinie ersetzt, angehängt oder entfernt werden sollen. Bei den Werten muss die Groß- und Kleinschreibung beachtet werden.

  • regions

    Der regions Richtlinienschlüssel gibt an AWS-Regionen , AWS Backup in welcher nach Ressourcen sucht, die den Bedingungen im selections Schlüssel entsprechen. Dieser Schlüssel enthält einen der Vererbungswertoperatoren und einen oder mehrere Zeichenfolgenwerte für AWS-Region Codes, zum Beispiel: ["us-east-1", "eu-north-1"].

  • selections

    Der Richtlinienschlüssel selections gibt die Ressourcen an, die durch die Planregeln in dieser Richtlinie gesichert werden. Dieser Schlüssel entspricht ungefähr dem BackupSelection Objekt in AWS Backup. Die Ressourcen werden durch eine Abfrage nach übereinstimmenden Tag-Schlüsselnamen und -werten angegeben. Der Schlüssel selections enthält einen darunterliegenden Schlüssel – tags.

    • tags – Gibt die Tags an, die die Ressourcen identifizieren, sowie die IAM-Rolle, die berechtigt ist, die Ressourcen abzufragen und zu sichern. Der Wert dieses Schlüssels enthält eines oder mehrere der folgenden Elemente:

      • Ein Bezeichner für dieses Tag-Element. Dieser Bezeichner unter tags ist der Tag-Schlüsselname in Kleinbuchstaben, auch wenn das abzufragende Tag eine andere Groß-/Kleinschreibung hat. Bei diesem Bezeichner wird nicht zwischen Groß- und Kleinschreibung unterschieden. Im vorherigen Beispiel wurde ein Element durch den Namen My_Backup_Assignment bezeichnet. Jeder Bezeichner unter tags enthält die folgenden Elemente:

        • iam_role_arn – Gibt die IAM-Rolle an, die über die Berechtigung zum Zugriff auf die Ressourcen verfügt, die durch die Tag-Abfrage in den durch den Schlüssel AWS-Regionen angegebenen regions-Regionen identifiziert wurden. Dieser Wert enthält den @@assign Vererbungswert-Operator und einen Zeichenfolgenwert, der den ARN der Rolle enthält. AWS Backup verwendet diese Rolle, um die Ressourcen abzufragen und zu ermitteln und das Backup durchzuführen.

          Anstelle der Konto-ID-Nummer können Sie die $account-Variable im ARN verwenden. Wenn der Backup-Plan von ausgeführt wird AWS Backup, ersetzt er die Variable automatisch durch die tatsächliche Konto-ID-Nummer des , AWS-Konto in dem die Richtlinie ausgeführt wird.

          Wichtig

          Die Rolle muss bereits vorhanden sein, wenn Sie den Backup-Plan zum ersten Mal starten. Wir empfehlen Ihnen, AWS CloudFormation Stack-Sets und ihre Integration mit Organizations zu verwenden, um automatisch Backup-Tresore und IAM-Rollen für jedes Mitgliedskonto in der Organisation zu erstellen und zu konfigurieren. Weitere Informationen finden Sie unter Erstellen eines Stack-Sets mit selbstverwalteten Berechtigungen im AWS CloudFormation -Benutzerhandbuch.

        • tag_key – Gibt den Tag-Schlüsselnamen an, nach dem gesucht werden soll. Dieser Schlüssel enthält den @@assign-Vererbungswert-Operator und einen Zeichenfolgewert. Beim -Wert ist die Groß- und Kleinschreibung zu beachten.

        • tag_value – Gibt den Wert an, der einem Schlüsselnamen zugeordnet werden muss, der mit übereinstimmttag_key. AWS Backup schließt die Ressource im Backup nur ein, wenn tag_key sowohl als auch tag_value übereinstimmen. Dieser Schlüssel enthält alle Vererbungswert-Operatoren sowie einen oder mehrere Werte, die in der effektiven Richtlinie ersetzt, angehängt oder entfernt werden sollen. Bei den Werten muss die Groß- und Kleinschreibung beachtet werden.

  • advanced_backup_settings – Gibt Einstellungen für bestimmte Backup-Szenarien an. Dieser Schlüssel enthält eine oder mehrere Einstellungen. Jede Einstellung ist eine JSON-Objektzeichenfolge mit den folgenden Elementen:

    • Objektschlüsselname – Eine Zeichenfolge, die den Ressourcentyp angibt, für den die folgenden erweiterten Einstellungen gelten.

    • Objektwert – Eine JSON-Objektzeichenfolge, die eine oder mehrere Backup-Einstellungen enthält, die für den zugehörigen Ressourcentyp spezifisch sind.

    Derzeit ermöglicht die einzige unterstützte erweiterte Backup-Einstellung Backups des Microsoft Volume Shadow Copy Service (VSS) für Windows oder SQL Server, die auf einer Amazon-EC2-Instance ausgeführt werden. Der Schlüsselname muss der Ressourcentyp "ec2" sein, und der Wert gibt an, dass "windows_vss"-Support entweder enabled oder disabled für Backups ist, die auf diesen Amazon-EC2-Instances ausgeführt werden. Weitere Informationen zu dieser Feature finden Sie unter Erstellen eines VSS-aktivierten Windows-Backups im AWS Backup -Entwicklerhandbuch.

    "advanced_backup_settings": { "ec2": { "windows_vss": { "@@assign": "enabled" } } }
  • backup_plan_tags – Gibt Tags an, die dem Backup-Plan selbst angefügt sind. Dies wirkt sich nicht auf die Tags aus, die in Regeln oder in der Auswahl angegeben sind.

    (Optional) Sie können Tags an Ihre Backup-Pläne anfügen. Der Wert dieses Schlüssels ist eine Sammlung von Elementen.

    Der Schlüsselname für jedes Element unter backup_plan_tags ist der Tag-Schlüsselname in Kleinbuchstaben, auch wenn das abzufragende Tag eine andere Groß-/Kleinschreibung hat. Bei diesem Bezeichner wird nicht zwischen Groß- und Kleinschreibung unterschieden. Der Wert für jeden dieser Einträge besteht aus den folgenden Schlüsseln:

    • tag_key – Gibt den Tag-Schlüsselnamen an, der dem Backupplan angefügt werden soll. Dieser Schlüssel enthält den @@assign-Vererbungswert-Operator und einen Zeichenfolgewert. Bei diesem Wert ist die Groß- und Kleinschreibung zu beachten.

    • tag_value – Gibt den Wert an, der dem Backup-Plan angefügt und dem zugeordnet ist tag_key. Dieser Schlüssel enthält den @@assign-Vererbungswert-Operator und einen Zeichenfolgewert. Bei diesem Wert ist die Groß- und Kleinschreibung zu beachten.

Beispiele für Backup-Richtlinien

Die folgenden Backup-Richtlinienbeispiele dienen nur zu Informationszwecken. In einigen der folgenden Beispiele kann die JSON-Leerzeichenformatierung komprimiert sein, um Platz zu sparen.

Beispiel 1: Richtlinie, die einem übergeordneten Knoten zugewiesen ist

Das folgende Beispiel zeigt eine Backup-Richtlinie, die einem der übergeordneten Knoten eines Kontos zugewiesen ist.

Übergeordnete Richtlinie – Diese Richtlinie kann an den Organisationsstamm oder an eine Organisationseinheit angefügt werden, bei der es sich um eine übergeordnete Organisationseinheit aller betreffenden Konten handelt.

{ "plans": { "PII_Backup_Plan": { "regions": { "@@assign": [ "ap-northeast-2", "us-east-1", "eu-north-1" ] }, "rules": { "Hourly": { "schedule_expression": { "@@assign": "cron(0 5/1 ? * * *)" }, "start_backup_window_minutes": { "@@assign": "480" }, "complete_backup_window_minutes": { "@@assign": "10080" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "180" }, "delete_after_days": { "@@assign": "270" } }, "target_backup_vault_name": { "@@assign": "FortKnox" }, "copy_actions": { "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": { "target_backup_vault_arn": { "@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "30" }, "delete_after_days": { "@@assign": "120" } } }, "arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault": { "target_backup_vault_arn": { "@@assign": "arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "30" }, "delete_after_days": { "@@assign": "120" } } } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyIamRole" }, "tag_key": { "@@assign": "dataType" }, "tag_value": { "@@assign": [ "PII", "RED" ] } } } }, "advanced_backup_settings": { "ec2": { "windows_vss": { "@@assign": "enabled" } } } } } }

Wenn keine anderen Richtlinien geerbt oder an die Konten angefügt werden, AWS-Konto sieht die effektive Richtlinie, die in jedem zutreffenden gerendert wird, wie im folgenden Beispiel aus. Der CRON Ausdruck bewirkt, dass der Backup einmal pro Stunde zur vollen Stunde ausgeführt wird. Die Konto-ID 123456789012 ist die tatsächliche Konto-ID für jedes Konto.

{ "plans": { "PII_Backup_Plan": { "regions": [ "us-east-1", "ap-northeast-3", "eu-north-1" ], "rules": { "hourly": { "schedule_expression": "cron(0 0/1 ? * * *)", "start_backup_window_minutes": "60", "target_backup_vault_name": "FortKnox", "lifecycle": { "to_delete_after_days": "2", "move_to_cold_storage_after_days": "180" }, "copy_actions": { "arn:aws:backup:us-east-1:$account:vault:secondary_vault": { "target_backup_vault_arn": { "@@assign": "arn:aws:backup:us-east-1:$account:vault:secondary_vault" }, "lifecycle": { "to_delete_after_days": "28", "move_to_cold_storage_after_days": "180" } }, "arn:aws:backup:us-west-1:111111111111:vault:tertiary_vault": { "target_backup_vault_arn": { "@@assign": "arn:aws:backup:us-west-1:111111111111:vault:tertiary_vault" }, "lifecycle": { "to_delete_after_days": "28", "move_to_cold_storage_after_days": "180" } } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": "arn:aws:iam::123456789012:role/MyIamRole", "tag_key": "dataType", "tag_value": [ "PII", "RED" ] } } }, "advanced_backup_settings": { "ec2": { "windows_vss": "enabled" } } } } }

Beispiel 2: Eine übergeordnete Richtlinie wird mit einer untergeordneten Richtlinie zusammengeführt

Im folgenden Beispiel werden eine geerbte übergeordnete Richtlinie und eine untergeordnete Richtlinie entweder geerbt oder direkt an eine AWS-Konto Zusammenführung angehängt, um die effektive Richtlinie zu bilden.

Übergeordnete Richtlinie – Diese Richtlinie kann an den Organisationsstamm oder an eine übergeordnete Organisationseinheit angefügt werden.

{ "plans": { "PII_Backup_Plan": { "regions": { "@@append":[ "us-east-1", "ap-northeast-3", "eu-north-1" ] }, "rules": { "Hourly": { "schedule_expression": { "@@assign": "cron(0 0/1 ? * * *)" }, "start_backup_window_minutes": { "@@assign": "60" }, "target_backup_vault_name": { "@@assign": "FortKnox" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "28" }, "to_delete_after_days": { "@@assign": "180" } }, "copy_actions": { "arn:aws:backup:us-east-1:$account:vault:secondary_vault" : { "target_backup_vault_arn" : { "@@assign" : "arn:aws:backup:us-east-1:$account:vault:secondary_vault" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "28" }, "to_delete_after_days": { "@@assign": "180" } } } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyIamRole" }, "tag_key": { "@@assign": "dataType" }, "tag_value": { "@@assign": [ "PII", "RED" ] } } } } } } }

Untergeordnete Richtlinie – Diese Richtlinie kann direkt an das Konto oder an eine Organisationseinheit auf einer Ebene unterhalb der Organisationseinheit, an die die übergeordnete Richtlinie angefügt ist, angefügt werden.

{ "plans": { "Monthly_Backup_Plan": { "regions": { "@@append":[ "us-east-1", "eu-central-1" ] }, "rules": { "Monthly": { "schedule_expression": { "@@assign": "cron(0 5 1 * ? *)" }, "start_backup_window_minutes": { "@@assign": "480" }, "target_backup_vault_name": { "@@assign": "Default" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "30" }, "to_delete_after_days": { "@@assign": "365" } }, "copy_actions": { "arn:aws:backup:us-east-1:$account:vault:Default" : { "target_backup_vault_arn" : { "@@assign" : "arn:aws:backup:us-east-1:$account:vault:Default" }, "lifecycle": { "move_to_cold_storage_after_days": { "@@assign": "30" }, "to_delete_after_days": { "@@assign": "365" } } } } } }, "selections": { "tags": { "MonthlyDatatype": { "iam_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyMonthlyBackupIamRole" }, "tag_key": { "@@assign": "BackupType" }, "tag_value": { "@@assign": [ "MONTHLY", "RED" ] } } } } } } }

Resultierende effektive Richtlinie – Die effektive Richtlinie, die auf die Konten angewendet wird, enthält zwei Pläne mit jeweils eigenen Regeln und Ressourcen, auf die die Regeln angewendet werden sollen.

{ "plans": { "PII_Backup_Plan": { "regions": [ "us-east-1", "ap-northeast-3", "eu-north-1" ], "rules": { "hourly": { "schedule_expression": "cron(0 0/1 ? * * *)", "start_backup_window_minutes": "60", "target_backup_vault_name": "FortKnox", "lifecycle": { "to_delete_after_days": "2", "move_to_cold_storage_after_days": "180" }, "copy_actions": { "arn:aws:backup:us-east-1:$account:vault:secondary_vault" : { "target_backup_vault_arn" : { "@@assign" : "arn:aws:backup:us-east-1:$account:vault:secondary_vault" }, "lifecycle": { "move_to_cold_storage_after_days": "28", "to_delete_after_days": "180" } } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": "arn:aws:iam::$account:role/MyIamRole", "tag_key": "dataType", "tag_value": [ "PII", "RED" ] } } } }, "Monthly_Backup_Plan": { "regions": [ "us-east-1", "eu-central-1" ], "rules": { "monthly": { "schedule_expression": "cron(0 5 1 * ? *)", "start_backup_window_minutes": "480", "target_backup_vault_name": "Default", "lifecycle": { "to_delete_after_days": "365", "move_to_cold_storage_after_days": "30" }, "copy_actions": { "arn:aws:backup:us-east-1:$account:vault:Default" : { "target_backup_vault_arn": { "@@assign" : "arn:aws:backup:us-east-1:$account:vault:Default" }, "lifecycle": { "move_to_cold_storage_after_days": "30", "to_delete_after_days": "365" } } } } }, "selections": { "tags": { "monthlydatatype": { "iam_role_arn": "arn:aws:iam::&ExampleAWSAccountNo3;:role/MyMonthlyBackupIamRole", "tag_key": "BackupType", "tag_value": [ "MONTHLY", "RED" ] } } } } } }

Beispiel 3: Eine übergeordnete Richtlinie verhindert Änderungen durch eine untergeordnete Richtlinie

Im folgenden Beispiel verwendet eine geerbte übergeordnete Richtlinie die untergeordneten Steuerungsoperatoren, um alle Einstellungen zu erzwingen, und verhindert, dass diese durch eine untergeordnete Richtlinie geändert oder überschrieben werden.

Übergeordnete Richtlinie – Diese Richtlinie kann an den Organisationsstamm oder an eine übergeordnete Organisationseinheit angefügt werden. Das Vorhandensein von "@@operators_allowed_for_child_policies": ["@@none"] an jedem Knoten der Richtlinie bedeutet, dass eine untergeordnete Richtlinie keine Änderungen an dem Plan vornehmen kann. Auch kann eine untergeordnete Richtlinie der effektiven Richtlinie keine zusätzlichen Pläne hinzufügen. Diese Richtlinie wird zur effektiven Richtlinie für jede Organisationseinheit und jedes Konto unter der Organisationseinheit, an die sie angefügt ist.

{ "plans": { "@@operators_allowed_for_child_policies": ["@@none"], "PII_Backup_Plan": { "@@operators_allowed_for_child_policies": ["@@none"], "regions": { "@@operators_allowed_for_child_policies": ["@@none"], "@@append": [ "us-east-1", "ap-northeast-3", "eu-north-1" ] }, "rules": { "@@operators_allowed_for_child_policies": ["@@none"], "Hourly": { "@@operators_allowed_for_child_policies": ["@@none"], "schedule_expression": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "cron(0 0/1 ? * * *)" }, "start_backup_window_minutes": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "60" }, "target_backup_vault_name": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "FortKnox" }, "lifecycle": { "@@operators_allowed_for_child_policies": ["@@none"], "move_to_cold_storage_after_days": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "28" }, "to_delete_after_days": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "180" } }, "copy_actions": { "@@operators_allowed_for_child_policies": ["@@none"], "arn:aws:backup:us-east-1:$account:vault:secondary_vault": { "@@operators_allowed_for_child_policies": ["@@none"], "target_backup_vault_arn": { "@@assign": "arn:aws:backup:us-east-1:$account:vault:secondary_vault", "@@operators_allowed_for_child_policies": ["@@none"] }, "lifecycle": { "@@operators_allowed_for_child_policies": ["@@none"], "to_delete_after_days": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "28" }, "move_to_cold_storage_after_days": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "180" } } } } } }, "selections": { "@@operators_allowed_for_child_policies": ["@@none"], "tags": { "@@operators_allowed_for_child_policies": ["@@none"], "datatype": { "@@operators_allowed_for_child_policies": ["@@none"], "iam_role_arn": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "arn:aws:iam::$account:role/MyIamRole" }, "tag_key": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "dataType" }, "tag_value": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": [ "PII", "RED" ] } } } }, "advanced_backup_settings": { "@@operators_allowed_for_child_policies": ["@@none"], "ec2": { "@@operators_allowed_for_child_policies": ["@@none"], "windows_vss": { "@@assign": "enabled", "@@operators_allowed_for_child_policies": ["@@none"] } } } } } }

Resultierende effektive Richtlinie – Wenn untergeordnete Backup-Richtlinien vorhanden sind, werden sie ignoriert und die übergeordnete Richtlinie wird zur effektiven Richtlinie.

{ "plans": { "PII_Backup_Plan": { "regions": [ "us-east-1", "ap-northeast-3", "eu-north-1" ], "rules": { "hourly": { "schedule_expression": "cron(0 0/1 ? * * *)", "start_backup_window_minutes": "60", "target_backup_vault_name": "FortKnox", "lifecycle": { "to_delete_after_days": "2", "move_to_cold_storage_after_days": "180" }, "copy_actions": { "target_backup_vault_arn": "arn:aws:backup:us-east-1:123456789012:vault:secondary_vault", "lifecycle": { "move_to_cold_storage_after_days": "28", "to_delete_after_days": "180" } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": "arn:aws:iam::123456789012:role/MyIamRole", "tag_key": "dataType", "tag_value": [ "PII", "RED" ] } } }, "advanced_backup_settings": { "ec2": {"windows_vss": "enabled"} } } } }

Beispiel 4: Eine übergeordnete Richtlinie verhindert Änderungen an einem einzelnen Backup-Plan durch eine untergeordnete Richtlinie

Im folgenden Beispiel verwendet eine geerbte übergeordnete Richtlinie die untergeordneten Steuerungsoperatoren, um die Einstellungen für einen einzelnen Plan zu erzwingen, und verhindert, dass diese durch eine untergeordnete Richtlinie geändert oder überschrieben werden. Die untergeordnete Richtlinie kann weiterhin zusätzliche Pläne hinzufügen.

Übergeordnete Richtlinie – Diese Richtlinie kann an den Organisationsstamm oder an eine übergeordnete Organisationseinheit angefügt werden. Dieses Beispiel ähnelt dem vorherigen Beispiel, in dem alle untergeordneten Vererbungsoperatoren blockiert wurden, außer auf der obersten Ebene plans. Mit der Einstellung @@append auf dieser Ebene können untergeordnete Richtlinien der Sammlung in der effektiven Richtlinie weitere Pläne hinzufügen. Alle Änderungen an dem geerbten Plan werden weiterhin blockiert.

Die Abschnitte in dem Plan sind aus Gründen der Übersichtlichkeit abgeschnitten.

{ "plans": { "@@operators_allowed_for_child_policies": ["@@append"], "PII_Backup_Plan": { "@@operators_allowed_for_child_policies": ["@@none"], "regions": { ... }, "rules": { ... }, "selections": { ... } } } }

Untergeordnete Richtlinie – Diese Richtlinie kann direkt an das Konto oder an eine Organisationseinheit auf einer Ebene unterhalb der Organisationseinheit, an die die übergeordnete Richtlinie angefügt ist, angefügt werden. Diese untergeordnete Richtlinie definiert einen neuen Plan.

Die Abschnitte in dem Plan sind aus Gründen der Übersichtlichkeit abgeschnitten.

{ "plans": { "MonthlyBackupPlan": { "regions": { ... }, "rules": { ... }, "selections": { … } } } }

Resultierende effektive Richtlinie – Die effektive Richtlinie umfasst beide Pläne.

{ "plans": { "PII_Backup_Plan": { "regions": { ... }, "rules": { ... }, "selections": { ... } }, "MonthlyBackupPlan": { "regions": { ... }, "rules": { ... }, "selections": { … } } } }

Beispiel 5: Eine untergeordnete Richtlinie überschreibt Einstellungen in einer übergeordneten Richtlinie

Im folgenden Beispiel verwendet eine untergeordnete Richtlinie wertbestimmende Operatoren, um einige der Einstellungen, die von einer übergeordneten Richtlinie geerbt wurden, außer Kraft zu setzen.

Übergeordnete Richtlinie – Diese Richtlinie kann an den Organisationsstamm oder an eine übergeordnete Organisationseinheit angefügt werden. Jede der Einstellungen kann von einer untergeordneten Richtlinie außer Kraft gesetzt werden, da das Standardverhalten in Abwesenheit eines untergeordneten Steuerungsoperators, der dies verhindert, darin besteht, @@assign, @@append oder @@remove durch die untergeordnete Richtlinie zuzulassen. Die übergeordnete Richtlinie enthält alle erforderlichen Elemente für einen gültigen Backup-Plan, sodass Ihre Ressourcen erfolgreich gesichert werden, wenn die Richtlinie unverändert geerbt wird.

{ "plans": { "PII_Backup_Plan": { "regions": { "@@append": [ "us-east-1", "ap-northeast-3", "eu-north-1" ] }, "rules": { "Hourly": { "schedule_expression": {"@@assign": "cron(0 0/1 ? * * *)"}, "start_backup_window_minutes": {"@@assign": "60"}, "target_backup_vault_name": {"@@assign": "FortKnox"}, "lifecycle": { "to_delete_after_days": {"@@assign": "2"}, "move_to_cold_storage_after_days": {"@@assign": "180"} }, "copy_actions": { "arn:aws:backup:us-east-1:$account:vault:t2": { "target_backup_vault_arn": {"@@assign": "arn:aws:backup:us-east-1:$account:vault:t2"}, "lifecycle": { "move_to_cold_storage_after_days": {"@@assign": "28"}, "to_delete_after_days": {"@@assign": "180"} } } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": {"@@assign": "arn:aws:iam::$account:role/MyIamRole"}, "tag_key": {"@@assign": "dataType"}, "tag_value": { "@@assign": [ "PII", "RED" ] } } } } } } }

Untergeordnete Richtlinie – Die untergeordnete Richtlinie enthält nur die Einstellungen, die von der geerbten übergeordneten Richtlinie abweichen müssen. Es muss eine geerbte übergeordnete Richtlinie vorhanden sein, die die anderen erforderlichen Einstellungen bereitstellt, wenn eine Zusammenführung zu einer effektiven Richtlinie erfolgt. Andernfalls enthält die effektive Backup-Richtlinie einen ungültigen Backupplan, der Ihre Ressourcen nicht wie erwartet sichert.

{ "plans": { "PII_Backup_Plan": { "regions": { "@@assign": [ "us-west-2", "eu-central-1" ] }, "rules": { "Hourly": { "schedule_expression": {"@@assign": "cron(0 0/2 ? * * *)"}, "start_backup_window_minutes": {"@@assign": "80"}, "target_backup_vault_name": {"@@assign": "Default"}, "lifecycle": { "move_to_cold_storage_after_days": {"@@assign": "30"}, "to_delete_after_days": {"@@assign": "365"} } } } } } }

Resultierende effektive Richtlinie – Die effektive Richtlinie enthält Einstellungen aus beiden Richtlinien, wobei die von der untergeordneten Richtlinie bereitgestellten Einstellungen die von der übergeordneten Richtlinie geerbten Einstellungen außer Kraft setzen. In diesem Beispiel kommt es zu folgenden Änderungen:

  • Die Liste der Regionen wird durch eine völlig andere Liste ersetzt. Wenn Sie der geerbten Liste eine Region hinzufügen möchten, verwenden Sie in der untergeordneten Richtlinie @@append anstelle von @@assign.

  • AWS Backup führt jede zweite Stunde statt stündlich aus.

  • AWS Backup erlaubt 80 Minuten, bis das Backup gestartet wird, anstatt 60 Minuten.

  • AWS Backup verwendet den Default Tresor anstelle von FortKnox.

  • Der Lebenszyklus wird sowohl für die Übertragung in den Cold Storage als auch für die letztendliche Löschung des Backups verlängert.

{ "plans": { "PII_Backup_Plan": { "regions": [ "us-west-2", "eu-central-1" ], "rules": { "hourly": { "schedule_expression": "cron(0 0/2 ? * * *)", "start_backup_window_minutes": "80", "target_backup_vault_name": "Default", "lifecycle": { "to_delete_after_days": "365", "move_to_cold_storage_after_days": "30" }, "copy_actions": { "arn:aws:backup:us-east-1:$account:vault:secondary_vault": { "target_backup_vault_arn": {"@@assign": "arn:aws:backup:us-east-1:$account:vault:secondary_vault"}, "lifecycle": { "move_to_cold_storage_after_days": "28", "to_delete_after_days": "180" } } } } }, "selections": { "tags": { "datatype": { "iam_role_arn": "arn:aws:iam::$account:role/MyIamRole", "tag_key": "dataType", "tag_value": [ "PII", "RED" ] } } } } } }