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
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-PlansPII_Backup_Plan
. In einer Richtlinie kann es mehrere Pläne geben, jeweils mit eigenenrules
,regions
,selections
undtags
.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 Elementeregions
undselections
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 angegebenenregions
), die durch die angegebenenrules
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üsselRules
in einem AWS Backup -Plan zugeordnet. Unter dem Schlüsselrules
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 demScheduleExpression
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 voncron(0 0/1 ? * * *)
wird der Backup stündlich zur vollen Stunde an jedem Wochentag gestartet. -
target_backup_vault_name
– Dieser Richtlinienschlüssel wird demTargetBackupVaultName
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 demStartWindowMinutes
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üsselCompletionWindowMinutes
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 demEnableContinuousBackup
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 demLifecycle
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 demMoveToColdStorageAfterDays
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 demDeleteAfterDays
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 demCopyActions
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üsselDestinationBackupVaultArn
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 demLifecycle
Schlüssel unter demCopyAction
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üsselMoveToColdStorageAfterDays
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üsselDeleteAfterDays
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 demRecoveryPointTags
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 wenntag_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 NamenOwner
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 isttag_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 imselections
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üsselselections
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 NamenMy_Backup_Assignment
bezeichnet. Jeder Bezeichner untertags
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 angegebenenregions
-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, wenntag_key
sowohl als auchtag_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 entwederenabled
oderdisabled
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 isttag_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 vonFortKnox
. -
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" ] } } } } } }