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.
# Benutzerdefinierte Amazon Data Lifecycle Manager Manager-Richtlinie für EBS-Snapshots erstellen
Das folgende Verfahren zeigt, wie Sie Amazon Data Lifecycle Manager verwenden, um Amazon-EBS-Snapshot-Lebenszyklen zu automatisieren.
**Topics**
+ [Erstellen einer Snapshot-Lebenszyklusrichtlinie](#create-snap-policy)
+ [Überlegungen zu Snapshot-Lebenszyklusrichtlinien](#snapshot-considerations)
+ [Weitere Ressourcen](#snapshot-additional-resources)
+ [Automatisieren Sie anwendungskonsistente Snapshots](automate-app-consistent-backups.md)
+ [Andere Anwendungsfälle für Vor- und Nach-Skripte](script-other-use-cases.md)
+ [Funktionsweise von Vor- und Nach-Skripten](script-flow.md)
+ [Identifizieren Sie Snapshots, die mit Vor- und Nachskripten erstellt wurden](dlm-script-tags.md)
+ [Überwachen Sie Vor- und Nachskripte](dlm-script-monitoring.md)
## Erstellen einer Snapshot-Lebenszyklusrichtlinie
Verwenden Sie eines der folgenden Verfahren, um eine Snapshot-Lebenszyklusrichtlinie zu erstellen.
------
#### [ Console ]
**So erstellen Sie eine Snapshot-Richtlinie**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Elastic Block Store** und **Lifecycle Manager** aus. Wählen Sie dann **Create lifecycle policy (Lebenszyklusrichtlinie erstellen)** aus.
1. Wählen Sie auf dem Bildschirm **Richtlinientyp auswählen** die Option **EBS-Snapshot-Richtlinie** und dann **Weiter** aus.
1. Gehen Sie im Abschnitt **Zielressourcen** wie folgt vor:
1. Wählen Sie für **Zielressourcentypen** den Typ der zu sichernden Ressource aus. Wählen Sie `Volume`, um Snapshots einzelner Volumes zu erstellen oder `Instance`, um Snapshots mit mehreren Volumes aus den Volumes zu erstellen, die an eine Instance angefügt sind.
1. (*Outpostund nur für Kunden mit lokaler Zone*) Geben Sie an, wo sich die Zielressourcen befinden.
Geben Sie unter **Zielressourcenspeicherort** an, wo sich die Zielressourcen befinden.
+ Um Ressourcen in einer Region als Ziel anzusprechen, wählen Sie **AWS Region** aus. Amazon Data Lifecycle Manager sichert alle Ressourcen des angegebenen Typs, die über übereinstimmende Ziel-Tags verfügen, nur in der aktuellen Region. Snapshots werden in derselben Region erstellt.
+ Um Ressourcen in lokalen Zonen als Ziel zu verwenden, wählen Sie **AWS Local Zones**. Amazon Data Lifecycle Manager sichert alle Ressourcen des angegebenen Typs, die über übereinstimmende Ziel-Tags verfügen, nur in allen Local Zones in der aktuellen Region. Snapshots können in derselben lokalen Zone wie die Quellressource oder in ihrer übergeordneten Region erstellt werden.
+ Um Ressourcen als Ziel zu verwendenOutpost, wählen Sie **AWS Outpost**. Amazon Data Lifecycle Manager sichert alle Ressourcen des angegebenen Typs, für die alle Outposts in Ihrem Konto übereinstimmende Ziel-Tags haben. Snapshots können auf derselben Ressource Outpost wie die Quellressource oder in ihrer übergeordneten Region erstellt werden.
1. Wählen Sie für **Zielressourcen-Tags** die Ressourcen-Tags aus, die die zu sichernden Volumes oder Instances identifizieren. Nur Ressourcen, die die angegebenen Tag (Markierung)-Schlüssel- und Wertepaare haben, werden von der Richtlinie gesichert.
1. Geben Sie unter **Description (Beschreibung)** eine kurze Beschreibung der Richtlinie ein.
1. Wählen Sie für **IAM-Rolle** die IAM-Rolle aus, die über Berechtigungen zum Verwalten von Snapshots und zum Beschreiben von Volumes und Instances verfügt. Um die von Amazon Data Lifecycle Manager bereitgestellte Standardrolle zu verwenden, wählen Sie **Standardrolle**. Um alternativ eine benutzerdefinierte IAM-Rolle zu verwenden, die Sie zuvor erstellt haben, wählen Sie **Andere Rolle auswählen** und dann die zu verwendende Rolle aus.
1. Fügen Sie für **Richtlinien-Tags** die Tags hinzu, die auf die Lebenszyklusrichtlinie angewendet werden sollen. Sie können diese Tags (Markierungen) verwenden, um Ihre Richtlinien zu identifizieren und zu kategorisieren.
1. Wählen Sie für **Policy status** (Richtlinienstatus) die Option **Enable** (Aktivieren) aus, um die Ausführung der Richtlinie zum nächsten geplanten Zeitpunkt zu starten oder **Disable policy** (Richtlinie deaktivieren), um die Ausführung der Richtlinie zu verhindern. Wenn Sie die Richtlinie jetzt nicht aktivieren, beginnt sie erst mit der Erstellung von Snapshots, wenn Sie sie nach der Erstellung manuell aktivieren.
1. (*Richtlinien, die nur auf Instances abzielen*) Schließen Sie Volumes aus Snapshot-Sets mit mehreren Volumes aus.
Standardmäßig erstellt Amazon Data Lifecycle Manager Snapshots aller Volumes, die an die Ziel-Instances angefügt sind. Sie können jedoch Snapshots einer Teilmenge der angehängten Volumes erstellen. Gehen Sie im Abschnitt **Parameters** (Parameter) wie folgt vor:
+ Wenn Sie keine Snapshots der Root-Volumes erstellen möchten, die den Ziel-Instances angefügt sind, wählen Sie **Exclude root volume** (Root-Volume ausschließen). Wenn Sie diese Option wählen, werden nur die Datenvolumes (Nicht-Root), die an die Ziel-Instances angefügt sind, in die Multi-Volume-Snapshot-Sets aufgenommen.
+ Wenn Sie Snapshots von einer Teilmenge der Daten-Volumes (Nicht-Root) erstellen möchten, die an die anvisierten Instances angefügt sind, wählen Sie **Exclude specific data volumes** (Bestimmte Daten-Volumes ausschließen) und geben Sie dann die Tags an, die verwendet werden sollen, um die Daten-Volumes zu identifizieren, die nicht in den Snapshot aufgenommen werden sollen. Amazon Data Lifecycle Manager erstellt keine Snapshots von Daten-Volumes, die über eines der angegebenen Tags verfügen. Amazon Data Lifecycle Manager erstellt nur Snapshots von Daten-Volumes, die keines der angegebenen Tags haben.
1. Wählen Sie **Weiter** aus.
1. Konfigurieren Sie auf dem Bildschirm **Zeitplan konfigurieren** die Richtlinienzeitpläne. Eine Richtlinie kann bis zu 4 Zeitpläne aufweisen. Zeitplan 1 ist obligatorisch. Die Zeitpläne 2, 3 und 4 sind optional. Gehen Sie für jeden Richtlinienzeitplan, den Sie hinzufügen, wie folgt vor:
1. Gehen Sie im Abschnitt **Zeitplandetails** wie folgt vor:
1. Geben Sie für **Zeitplanname** einen beschreibenden Namen für den Zeitplan an.
1. Konfigurieren Sie für **Häufigkeit** und die zugehörigen Felder das Intervall zwischen Richtlinienausführungen.
Sie können Richtlinienausführungen nach einem täglichen, wöchentlichen, monatlichen oder jährlichen Zeitplan konfigurieren. Alternativ können Sie **Custom cron expression (Benutzerdefinierter Cron-Ausdruck)** wählen, um ein Intervall von bis zu 1 Jahr anzugeben. Weitere Informationen finden Sie unter [Cron und Rate Expressions](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html) im * EventBridge Amazon-Benutzerhandbuch*.
**Anmerkung**
Wenn Sie die **Snapshot-Archivierung** für den Zeitplan aktivieren müssen, müssen Sie als Häufigkeit **monthly** (monatlich) oder **yearly** (jährlich) auswählen oder einen Cron-Ausdruck mit einer Erstellungshäufigkeit von mindestens 28 Tagen angeben.
Wenn Sie eine monatliche Häufigkeit angeben, mit der Snapshots an einem bestimmten Tag in einer bestimmten Woche erstellt werden (z. B. am zweiten Donnerstag des Monats), muss für einen anzahlbasierten Zeitplan die Aufbewahrungsanzahl für die Archivstufe mindestens 4 betragen.
1. Geben Sie für **Starten um** die Uhrzeit an, zu der die Richtlinienausführungen für den Start geplant sind. Die erste Richtlinienausführung beginnt innerhalb einer Stunde nach der geplanten Zeit. Die Uhrzeit muss im `hh:mm` UTC-Format eingegeben werden.
1. Geben Sie für **Aufbewahrungstyp** die Aufbewahrungsrichtlinie für Schnappschüsse an, die vom Zeitplan erstellt wurden.
Sie können Snapshots basierend auf ihrer Gesamtzahl oder ihrem Alter aufbewahren.
+ Anzahlbasierte Aufbewahrung
+ Wenn die Snapshot-Archivierung deaktiviert ist, reicht der Bereich von `1` bis `1000`. Wenn der Aufbewahrungsschwellenwert erreicht ist, wird der älteste Snapshot dauerhaft gelöscht.
+ Bei aktivierter Snapshot-Archivierung reicht der Bereich von `0` (Archivierung sofort nach Erstellung) bis `1000`. Wenn der Aufbewahrungsschwellenwert erreicht ist, wird der älteste Snapshot in einen vollständigen Snapshot umgewandelt und in die Archivebene verschoben.
+ Altersbasierte Aufbewahrung
+ Wenn die Snapshot-Archivierung deaktiviert ist, reicht der Bereich von `1` Tagen bis `100` Jahren. Wenn der Aufbewahrungsschwellenwert erreicht ist, wird der älteste Snapshot dauerhaft gelöscht.
+ Bei aktivierter Snapshot-Archivierung reicht der Bereich von `0` Tagen (Archivierung sofort nach Erstellung) bis `100` Jahren. Wenn der Aufbewahrungsschwellenwert erreicht ist, wird der älteste Snapshot in einen vollständigen Snapshot umgewandelt und in die Archivebene verschoben.
**Anmerkung**
Alle Zeitpläne müssen denselben Aufbewahrungstyp aufweisen (alters- oder anzahlbasiert). Sie können den Aufbewahrungstyp nur für Zeitplan 1 angeben. Die Zeitpläne 2, 3 und 4 erben den Aufbewahrungstyp aus Plan 1. Jeder Zeitplan kann über eine eigene Aufbewahrungsanzahl oder einen eigenen Zeitraum verfügen.
Wenn Sie die schnelle Snapshot-Wiederherstellung, das regionsübergreifende Kopieren oder die Snapshot-Freigabe aktivieren, müssen Sie eine Aufbewahrungsanzahl von mindestens `1` oder einen Aufbewahrungszeitraum von mindestens `1` Tag angeben.
1. (*AWS Outposts und nur für Kunden in der lokalen Zone*) Geben Sie das Snapshot-Ziel an.
Geben Sie unter **Snapshot-Ziel ** das Ziel für Snapshots an, die von der Richtlinie erstellt wurden.
+ Wenn die Richtlinie auf Ressourcen in einer Region abzielt, müssen Snapshots in derselben Region erstellt werden. AWS Die Region ist für Sie ausgewählt.
+ Wenn die Richtlinie auf Ressourcen in einer lokalen Zone abzielt, können Sie Snapshots in derselben lokalen Zone wie die Quellressource oder in ihrer übergeordneten Region erstellen.
+ Wenn die Richtlinie auf Ressourcen in einer abzieltOutpost, können Sie Snapshots auf derselben Ressource Outpost wie die Quellressource oder in ihrer übergeordneten Region erstellen.
1. Konfigurieren Sie das Markieren von Snapshots.
Gehen Sie im Abschnitt **Tag (Markierung)** wie folgt vor:
1. Um alle benutzerdefinierten Tags vom Quell-Volume in die vom Zeitplan erstellten Schnappschüsse zu kopieren, wählen Sie **Tags aus Quelle kopieren**.
1. Um zusätzliche Tags (Markierungen) anzugeben, die Snapshots zugewiesen werden sollen, die von diesem Zeitplan erstellt wurden, wählen Sie **Tags (Markierungen) hinzufügen**.
1. Konfigurieren Sie Vor- und Nach-Skripte für anwendungskonsistente Snapshots.
Weitere Informationen finden Sie unter [Automatisieren Sie anwendungskonsistente Snapshots mit Data Lifecycle Manager](automate-app-consistent-backups.md).
1. (*Richtlinien, die nur auf Volumes abzielen*) Konfigurieren Sie die Snapshot-Archivierung.
Gehen Sie im Abschnitt **Snapshot-Archivierung** wie folgt vor:
**Anmerkung**
Die Snapshot-Archivierung lässt sich nur für einen Zeitplan in einer Richtlinie aktivieren.
1. Zum Aktivieren der Snapshot-Archivierung für den Zeitplan wählen Sie **Archive snapshots created by this schedule** (Mit diesem Zeitplan erstellte Snapshots archivieren) aus.
**Anmerkung**
Die Snapshot-Archivierung lässt sich nur aktivieren, wenn Snapshots monatlich oder jährlich erstellt werden oder wenn Sie einen Cron-Ausdruck mit einer Erstellungshäufigkeit von mindestens 28 Tagen angeben.
1. Geben Sie die Aufbewahrungsregel für Snapshots auf der Archivstufe an.
+ Geben Sie für **anzahlbasierte Zeitpläne** die Anzahl der Snapshots an, die auf der Archivstufe aufbewahrt werden sollen. Wenn der Aufbewahrungsschwellenwert erreicht ist, wird der älteste Snapshot dauerhaft aus der Archivstufe gelöscht. Wenn Sie beispielsweise drei angeben, behält der Zeitplan maximal drei Snapshots auf der Archivstufe bei. Bei Archivierung des vierten Snapshots wird der älteste der drei vorhandenen Snapshots auf der Archivstufe gelöscht.
+ Geben Sie für **altersbasierte Zeitpläne** den Zeitraum an, für den Snapshots auf der Archivstufe aufbewahrt werden sollen. Wenn der Aufbewahrungsschwellenwert erreicht ist, wird der älteste Snapshot dauerhaft aus der Archivstufe gelöscht. Wenn Sie beispielsweise 120 Tage angeben, werden Snapshots automatisch aus der Archivstufe gelöscht, wenn sie dieses Alter erreicht haben.
**Wichtig**
Der Mindestaufbewahrungszeitraum für archivierte Snapshots beträgt 90 Tage. Sie müssen eine Aufbewahrungsregel angeben, die den Snapshot mindestens 90 Tage lang aufbewahrt.
1. Aktivieren Sie die schnelle Snapshot-Wiederherstellung.
Um die schnelle Snapshot-Wiederherstellung für vom Zeitplan erstellte Snapshots zu aktivieren, wählen Sie im Abschnitt **Schnelle Snapshot-Wiederherstellung** die Option **Schnelle Snapshot-Wiederherstellung aktivieren** aus. Wenn Sie die schnelle Snapshot-Wiederherstellung aktivieren, müssen Sie die Availability Zones auswählen, in denen sie aktiviert werden soll. Wenn der Zeitplan einen altersbasierten Aufbewahrungszeitplan verwendet, müssen Sie den Zeitraum angeben, für den die schnelle Snapshot-Wiederherstellung für jeden Snapshot aktiviert werden soll. Wenn der Zeitplan eine zahlbasierte Aufbewahrung verwendet, müssen Sie die maximale Anzahl von Snapshots angeben, um die schnelle Snapshot-Wiederherstellung zu aktivieren.
Wenn der Zeitplan Snapshots auf einer erstelltOutpost, können Sie die schnelle Snapshot-Wiederherstellung nicht aktivieren. Die schnelle Snapshot-Wiederherstellung wird bei lokalen Snapshots, die auf einem gespeichert sind, nicht unterstützt. Outpost
**Anmerkung**
Es wird Ihnen jede Minute in Rechnung gestellt, in der die schnelle Snapshot-Wiederherstellung für einen Snapshot in einer bestimmten Availability Zone aktiviert ist. Die Gebühren werden mit mindestens einer Stunde anteilig bewertet.
1. Konfigurieren Sie das regionsübergreifende Kopieren.
Um nach dem Zeitplan erstellte Snapshots in eine Outpost oder in eine andere Region zu kopieren, wählen Sie im Abschnitt Regionsübergreifendes Kopieren die Option **Regionsübergreifendes Kopieren** **aktivieren** aus.
Wenn der Zeitplan Snapshots in einer Region erstellt, können Sie die Snapshots in bis zu drei weitere Regionen oder in Ihr Konto kopieren. Outposts Sie müssen für jede Zielregion oder eine separate Regel für regionsübergreifendes Kopieren angeben. Outpost
Für jede Region oder Outpost können Sie unterschiedliche Aufbewahrungsrichtlinien wählen und wählen, ob Sie alle oder keine Tags kopieren möchten. Wenn der Quell-Snapshot verschlüsselt ist oder wenn die Verschlüsselung standardmäßig aktiviert ist, werden die Snapshots-Kopien verschlüsselt. Wenn der Quell-Snapshot unverschlüsselt ist, können Sie die Verschlüsselung aktivieren. Wenn Sie keinen Verschlüsselung angeben, werden die Snapshots mit der Standard-Verschlüsselung für die EBS-Verschlüsselung in jeder Zielregion verschlüsselt. Wenn Sie einen Verschlüsselung für die Zielregion angeben, muss die ausgewählte IAM-Rolle Zugriff auf das Verschlüsselung haben.
**Anmerkung**
Sie müssen sicherstellen, dass Sie die Anzahl der gleichzeitigen Snapshot-Kopien pro Region nicht überschreiten.
Wenn die Richtlinie Snapshots für eine erstelltOutpost, können Sie die Snapshots nicht in eine Region oder in eine andere kopieren, Outpost und die Einstellungen für regionsübergreifendes Kopieren sind nicht verfügbar.
1. Konfigurieren Sie die kontoübergreifende gemeinsame Nutzung.
Konfigurieren Sie im Bereich **Kontoübergreifendes Teilen** die Richtlinie so, dass die nach dem Zeitplan erstellten Schnappschüsse automatisch mit anderen Konten geteilt werden. AWS Gehen Sie wie folgt vor:
1. Um das Teilen mit anderen AWS Konten zu aktivieren, wählen Sie **Kontoübergreifendes Teilen aktivieren** aus.
1. Um die Konten hinzuzufügen, mit denen die Schnappschüsse geteilt werden sollen, wählen Sie **Konto hinzufügen**, geben Sie die 12-stellige AWS -Konto-ID ein und wählen Sie **Hinzufügen**.
1. Um die Freigabe freigegebener Snapshots nach einem bestimmten Zeitraum automatisch aufzuheben, wählen Sie **Unshare automatically (Freigabe automatisch aufheben)**. Wenn Sie sich dafür entschieden haben, die Freigabe freigegebener Snapshots automatisch aufzuheben, kann der Zeitraum, nach dem die Snapshots automatisch aufgegeben werden, nicht länger sein als der Zeitraum, in dem die Richtlinie ihre Snapshots aufbewahrt. Wenn die Aufbewahrungskonfiguration der Richtlinie beispielsweise Snapshots für einen Zeitraum von 5 Tagen aufbewahrt, können Sie die Richtlinie nur so konfigurieren, dass freigegebene Snapshots automatisch nach Zeiträumen von bis zu 4 Tagen freigegeben werden. Dies gilt für Richtlinien mit alters- und anzahlbasierten Snapshot-Aufbewahrungskonfigurationen.
Wenn Sie die automatische Freigabe nicht aktivieren, wird der Snapshot freigegeben, bis er gelöscht wird.
**Anmerkung**
Sie können nur Snapshots freigeben, die unverschlüsselt oder mit einem Kundenverwalteter Schlüssel verschlüsselt sind. Sie können keine Snapshots freigeben, die mit dem standardmäßigen EBS-Verschlüsselungs-Verschlüsselung verschlüsselt sind. Wenn Sie verschlüsselte Snapshots teilen, müssen Sie auch den Verschlüsselung, der zum Verschlüsseln des Quell-Volumes verwendet wurde, mit den Zielkonten teilen. Weitere Informationen finden Sie unter [Benutzern in anderen Konten die Verwendung eines KMS-Schlüssels erlauben](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) im *AWS Key Management Service -Entwicklerhandbuch*.
1. Um weitere Zeitpläne hinzuzufügen, wählen Sie die Option **Weiteren Zeitplan hinzufügen**, die sich oben auf dem Bildschirm befindet. Füllen Sie für jeden zusätzlichen Zeitplan die Felder wie oben in diesem Thema beschrieben aus.
1. Nachdem Sie die erforderlichen Zeitpläne hinzugefügt haben, wählen Sie **Richtlinie überprüfen** aus.
1. Überprüfen Sie die Richtlinienzusammenfassung und wählen Sie dann **Richtlinie erstellen** aus.
**Anmerkung**
Falls Sie den Fehler `Role with name AWSDataLifecycleManagerDefaultRole already exists` erhalten, finden Sie weitere Informationen unter [Probleme mit Amazon Data Lifecycle Manager beheben](dlm-troubleshooting.md).
------
#### [ Command line ]
Verwenden Sie den [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)Befehl, um eine Snapshot-Lebenszyklusrichtlinie zu erstellen. Legen Sie für `PolicyType` die Option `EBS_SNAPSHOT_MANAGEMENT` fest.
**Anmerkung**
Zur Vereinfachung der Syntax wird in den folgenden Beispielen eine JSON-Datei `policyDetails.json` verwendet, die die Richtliniendetails enthält.
**Beispiel 1 – Snapshot-Lebenszyklusrichtlinie mit zwei Zeitplänen**
In diesem Beispiel wird eine Snapshot-Lebenszyklusrichtlinie erstellt, die Snapshots aller Volumes erstellt, die einen Tag (Markierung)-Schlüssel `costcenter` mit dem Wert von `115` haben. Die Richtlinie enthält zwei Zeitpläne. Der erste Zeitplan erstellt jeden Tag um 03:00 Uhr UTC einen Snapshot. Der zweite Zeitplan erstellt jeden Freitag um 17:00 Uhr UTC einen wöchentlichen Snapshot.
```
aws dlm create-lifecycle-policy \
--description "My volume policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"VOLUME"
],
"TargetTags": [{
"Key": "costcenter",
"Value": "115"
}],
"Schedules": [{
"Name": "DailySnapshots",
"TagsToAdd": [{
"Key": "type",
"Value": "myDailySnapshot"
}],
"CreateRule": {
"Interval": 24,
"IntervalUnit": "HOURS",
"Times": [
"03:00"
]
},
"RetainRule": {
"Count": 5
},
"CopyTags": false
},
{
"Name": "WeeklySnapshots",
"TagsToAdd": [{
"Key": "type",
"Value": "myWeeklySnapshot"
}],
"CreateRule": {
"CronExpression": "cron(0 17 ? * FRI *)"
},
"RetainRule": {
"Count": 5
},
"CopyTags": false
}
]}
```
Wenn die Anforderung erfolgreich ist, gibt der Befehl die ID der neu erstellten Richtlinie zurück. Es folgt eine Beispielausgabe.
```
{
"PolicyId": "policy-0123456789abcdef0"
}
```
**Beispiel 2 – Snapshot-Lebenszyklusrichtlinie, die auf Instances abzielt und Snapshots einer Untergruppe von Datenvolumes (Nicht-Root) erstellt**
In diesem Beispiel wird eine Snapshot-Lebenszyklusrichtlinie erstellt, die Multi-Volume-Snapshot-Sets aus Instaces erstellt, die mit `code=production` gekennzeichnet sind. Die Richtlinie enthält nur einen Zeitplan. Der Zeitplan erstellt keine Snapshots von den Daten-Volumes, die mit `code=temp` gekennzeichnet sind.
```
aws dlm create-lifecycle-policy \
--description "My volume policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "code",
"Value": "production"
}],
"Parameters": {
"ExcludeDataVolumeTags": [{
"Key": "code",
"Value": "temp"
}]
},
"Schedules": [{
"Name": "DailySnapshots",
"TagsToAdd": [{
"Key": "type",
"Value": "myDailySnapshot"
}],
"CreateRule": {
"Interval": 24,
"IntervalUnit": "HOURS",
"Times": [
"03:00"
]
},
"RetainRule": {
"Count": 5
},
"CopyTags": false
}
]}
```
Wenn die Anforderung erfolgreich ist, gibt der Befehl die ID der neu erstellten Richtlinie zurück. Es folgt eine Beispielausgabe.
```
{
"PolicyId": "policy-0123456789abcdef0"
}
```
**Beispiel 3 — Snapshot-Lifecycle-Richtlinie, die lokale Snapshots von Ressourcen automatisiert Outpost**
In diesem Beispiel wird eine Snapshot-Lifecycle-Richtlinie erstellt, die Snapshots von Volumes erstellt, die mit `team=dev` markiert sind. Outposts Die Richtlinie erstellt die Snapshots auf denselben Volumes Outposts wie die Quellvolumes. Die Richtlinie erstellt alle `12` Stunden Snapshots bei `00:00` UTC.
```
aws dlm create-lifecycle-policy \
--description "My local snapshot policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": "VOLUME",
"ResourceLocations": "OUTPOST",
"TargetTags": [{
"Key": "team",
"Value": "dev"
}],
"Schedules": [{
"Name": "on-site backup",
"CreateRule": {
"Interval": 12,
"IntervalUnit": "HOURS",
"Times": [
"00:00"
],
"Location": [
"OUTPOST_LOCAL"
]
},
"RetainRule": {
"Count": 1
},
"CopyTags": false
}
]}
```
**Beispiel 4 — Snapshot-Lifecycle-Richtlinie, die Snapshots in einer Region erstellt und sie in eine kopiert Outpost**
Die folgende Beispielrichtlinie erstellt Snapshots von Volumes, die mit `team=dev` markiert sind. Die Snapshots werden in der gleichen Region erstellt wie das Quell-Volume. Snapshots werden alle `12` Stunden bei `00:00` UTC erstellt und bewahren ein Maximum an Snapshots von `1`. Die Richtlinie kopiert auch die Snapshots in Outpost`arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0`, verschlüsselt die kopierten Snapshots mit dem standardmäßigen KMS-Verschlüsselungsschlüssel und bewahrt die Kopien für einen Monat auf. `1`
```
aws dlm create-lifecycle-policy \
--description "Copy snapshots to Outpost" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": "VOLUME",
"ResourceLocations": "CLOUD",
"TargetTags": [{
"Key": "team",
"Value": "dev"
}],
"Schedules": [{
"Name": "on-site backup",
"CopyTags": false,
"CreateRule": {
"Interval": 12,
"IntervalUnit": "HOURS",
"Times": [
"00:00"
],
"Location": "CLOUD"
},
"RetainRule": {
"Count": 1
},
"CrossRegionCopyRules" : [
{
"Target": "arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0",
"Encrypted": true,
"CopyTags": true,
"RetainRule": {
"Interval": 1,
"IntervalUnit": "MONTHS"
}
}]
}
]}
```
**Beispiel 5 – Snapshot-Lebenszyklusrichtlinie mit einem archivfähigen, altersbasierten Zeitplan**
In diesem Beispiel wird eine Snapshot-Lebenszyklusrichtlinie erstellt, die für mit `Name=Prod` markierte Volumes gilt. Die Richtlinie hat einen altersbasierten Zeitplan, der Snapshots am ersten Tag eines jeden Monats um 09.00 Uhr erstellt. Der Zeitplan bewahrt alle Snapshots auf der Standardstufe einen Tag lang auf. Danach werden sie in die Archivstufe verschoben. Snapshots werden 90 Tage lang auf der Archivstufe gespeichert, bevor sie gelöscht werden.
```
aws dlm create-lifecycle-policy \
--description "Copy snapshots to Outpost" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"ResourceTypes": [ "VOLUME"],
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"Schedules" : [
{
"Name": "sched1",
"TagsToAdd": [
{"Key":"createdby","Value":"dlm"}
],
"CreateRule": {
"CronExpression": "cron(0 9 1 * ? *)"
},
"CopyTags": true,
"RetainRule":{
"Interval": 1,
"IntervalUnit": "DAYS"
},
"ArchiveRule": {
"RetainRule":{
"RetentionArchiveTier": {
"Interval": 90,
"IntervalUnit": "DAYS"
}
}
}
}
],
"TargetTags": [
{
"Key": "Name",
"Value": "Prod"
}
]
}
```
**Beispiel 6 – Snapshot-Lebenszyklusrichtlinie mit einem archivfähigen, anzahlbasierten Zeitplan**
In diesem Beispiel wird eine Snapshot-Lebenszyklusrichtlinie erstellt, die für mit `Purpose=Test` markierte Volumes gilt. Die Richtlinie hat einen anzahlbasierten Zeitplan, der Snapshots am ersten Tag eines jeden Monats um 09.00 Uhr erstellt. Der Zeitplan archiviert Snapshots unmittelbar nach der Erstellung und bewahrt maximal drei Snapshots auf der Archivstufe auf.
```
aws dlm create-lifecycle-policy \
--description "Copy snapshots to Outpost" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Das folgende Beispiel zeigt eine `policyDetails.json`-Datei.
```
{
"ResourceTypes": [ "VOLUME"],
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"Schedules" : [
{
"Name": "sched1",
"TagsToAdd": [
{"Key":"createdby","Value":"dlm"}
],
"CreateRule": {
"CronExpression": "cron(0 9 1 * ? *)"
},
"CopyTags": true,
"RetainRule":{
"Count": 0
},
"ArchiveRule": {
"RetainRule":{
"RetentionArchiveTier": {
"Count": 3
}
}
}
}
],
"TargetTags": [
{
"Key": "Purpose",
"Value": "Test"
}
]
}
```
------
## Überlegungen zu Snapshot-Lebenszyklusrichtlinien
Die folgenden **allgemeinen Überlegungen** gelten für Snapshot-Lebenszyklusrichtlinien:
+ Snapshot-Lebenszyklusrichtlinien zielen nur auf Instances oder Volumes ab, die sich in derselben Region wie die Richtlinie befinden.
+ Der erste Snapshot-Erstellungsvorgang beginnt innerhalb einer Stunde nach der angegebenen Startzeit. Nachfolgende Snapshot-Erstellungsvorgänge beginnen innerhalb einer Stunde nach ihrer geplanten Zeit.
+ Sie können mehrere Richtlinien zum Sichern eines Volumes oder einer Instance erstellen. Wenn ein Volume zwei Tags hat, wobei Tag *A* das Ziel für Richtlinie *A* ist, alle 12 Stunden einen Snapshot zu erstellen, und Tag *B* das Ziel für Richtlinie *B*, alle 24 Stunden einen Snapshot zu erstellen, erstellt Amazon Data Lifecycle Manager Snapshots gemäß den Zeitplänen für beide Richtlinien. Alternativ können Sie dasselbe Ergebnis erzielen, indem Sie eine einzelne Richtlinie mit mehreren Zeitplänen erstellen. Sie können beispielsweise eine einzelne Richtlinie erstellen, die nur auf Tag (Markierung) *A*abzielt, und zwei Zeitpläne angeben – einen für alle 12 Stunden und einen für alle 24 Stunden.
+ Bei Zielressourcen-Tags muss die Groß-/Kleinschreibung beachtet werden.
+ Wenn Sie die Ziel-Tags von einer Ressource entfernen, auf die eine Richtlinie abzielt, verwaltet Amazon Data Lifecycle Manager die vorhandenen Snapshots im Standard-Tier und Archiv-Tier nicht mehr; Sie müssen sie manuell löschen, wenn sie nicht mehr benötigt werden.
+ Wenn Sie eine Richtlinie erstellen, die auf Instances abzielt, und neue Volumes an die Ziel-Instance angefügt werden, nachdem die Richtlinie erstellt wurde, werden die neu hinzugefügten Volumes bei der nächsten Richtlinienausführung in das Backup einbezogen. Alle Volumes, die zum Zeitpunkt der Richtlinienausführung mit der Instance verbunden sind, sind enthalten.
+ Wenn Sie eine Richtlinie mit einem benutzerdefinierten Cron-basierten Zeitplan so erstellen und konfigurieren, dass nur ein Snapshot erstellt wird, wird die Richtlinie diesen Snapshot nicht automatisch löschen, wenn der Aufbewahrungsschwellenwert erreicht ist. Sie müssen den Snapshot manuell löschen, wenn er nicht mehr länger benötigt wird.
+ Wenn Sie eine altersbasierte Richtlinie erstellen, bei der der Aufbewahrungszeitraum kürzer ist als die Erstellungshäufigkeit, behält Amazon Data Lifecycle Manager immer den letzten Snapshot bei, bis der nächste erstellt wird. Wenn zum Beispiel eine altersbasierte Richtlinie jeden Monat einen Snapshot mit einer Aufbewahrungsfrist von sieben Tagen erstellt, behält Amazon Data Lifecycle Manager jeden Snapshot einen Monat lang bei, obwohl die Aufbewahrungsfrist sieben Tage beträgt.
Die folgenden Überlegungen beziehen sich auf die **[Snapshot-Archivierung](snapshot-archive.md)**:
+ Die Snapshot-Archivierung lässt sich nur für Snapshot-Richtlinien aktivieren, die für Volumes gelten.
+ Pro Richtlinie können Sie nur eine Archivierungsregel für einen Zeitplan angeben.
+ Bei Verwendung der Konsole lässt sich die Snapshot-Archivierung nur aktivieren, wenn der Zeitplan eine monatliche oder jährliche Erstellungshäufigkeit oder einen Cron-Ausdruck mit einer Erstellungshäufigkeit von mindestens 28 Tagen aufweist.
Wenn Sie die AWS API oder das AWS SDK verwenden AWS CLI, können Sie die Snapshot-Archivierung nur aktivieren, wenn der Zeitplan einen Cron-Ausdruck mit einer Erstellungshäufigkeit von mindestens 28 Tagen enthält.
+ Der Mindestaufbewahrungszeitraum auf der Archivstufe beträgt 90 Tage.
+ Wenn ein Snapshot archiviert wird, wird er beim Verschieben in die Archivstufe in einen vollständigen Snapshot konvertiert. Dies kann zu höheren Kosten für die Snapshot-Speicherung führen. Weitere Informationen finden Sie unter [Preise und Abrechnung für die Archivierung von Amazon EBS-Snapshots](snapshot-archive-pricing.md).
+ Die schnelle Snapshot-Wiederherstellung und die Snapshot-Freigabe werden für Snapshots deaktiviert, wenn sie archiviert werden.
+ Wenn Ihre Aufbewahrungsregel in einem Schaltjahr zu einem Archivierungszeitraum von weniger als 90 Tagen führt, stellt Amazon Data Lifecycle Manager sicher, dass Snapshots mindestens 90 Tage lang aufbewahrt werden.
+ Wenn Sie einen von Amazon Data Lifecycle Manager erstellten Snapshot manuell archivieren und der Snapshot bei Erreichen des Aufbewahrungsschwellenwerts des Zeitplans immer noch archiviert ist, wird dieser Snapshot nicht mehr von Amazon Data Lifecycle Manager verwaltet. Wenn Sie den Snapshot jedoch vor Erreichen des Aufbewahrungsschwellenwerts des Zeitplans wieder in die Standardstufe verschieben, wird er vom Zeitplan weiterhin gemäß den Aufbewahrungsregeln verwaltet.
+ Wenn Sie einen von Amazon Data Lifecycle Manager archivierten Snapshot dauerhaft oder temporär wieder in die Standardstufe verschieben und der Snapshot sich bei Erreichen des Aufbewahrungsschwellenwerts des Zeitplans immer noch auf der Standardstufe befindet, wird dieser Snapshot nicht mehr von Amazon Data Lifecycle Manager verwaltet. Wenn Sie den Snapshot jedoch vor Erreichen des Aufbewahrungsschwellenwerts des Zeitplans erneut archivieren, wird er vom Zeitplan gelöscht, sobald der Aufbewahrungsschwellenwert erreicht ist.
+ Von Amazon Data Lifecycle Manager archivierte Snapshots werden auf Ihre `Archived snapshots per volume`- und `In-progress snapshot archives per account`-Kontingente angerechnet.
+ Wenn ein Zeitplan einen Snapshot nicht archivieren kann, nachdem dies 24 Stunden lang immer wieder versucht wurde, verbleibt der Snapshot auf der Standardstufe. Seine Löschung wird dann zu dem Zeitpunkt geplant, zu dem er aus der Archivstufe gelöscht worden wäre. Wenn der Zeitplan Snapshots beispielsweise 120 Tage lang archiviert, bleibt der Snapshot nach der fehlgeschlagenen Archivierung 120 Tage lang auf der Standardstufe, bevor er endgültig gelöscht wird. Bei anzahlbasierten Zeitplänen wird der Snapshot nicht auf die Aufbewahrungsanzahl des Zeitplans angerechnet.
+ Snapshots müssen in derselben Region archiviert werden, in der sie erstellt wurden. Wenn Sie das regionsübergreifende Kopieren und die Snapshot-Archivierung aktiviert haben, wird die Snapshot-Kopie von Amazon Data Lifecycle Manager nicht archiviert.
+ Von Amazon Data Lifecycle Manager archivierte Snapshots werden mit dem System-Tag `aws:dlm:archived=true` markiert. Darüber hinaus werden Snapshots, die nach einem für die Archivierung aktivierten, altersbasierten Zeitplan erstellt wurden, mit dem System-Tag `aws:dlm:expirationTime` markiert, das das Datum und die Uhrzeit für die geplante Archivierung des Snapshots angibt.
Die folgenden Überlegungen gelten für das **Ausschließen von Root-Volumes und Daten-Volumes (Nicht-Root)**:
+ Wenn Sie Startvolumes ausschließen und Tags angeben, die folglich alle zusätzlichen Datenvolumes ausschließen, die an eine Instance angehängt sind, erstellt Amazon Data Lifecycle Manager keine Snapshots für die betroffene Instance und gibt eine `SnapshotsCreateFailed` CloudWatch Metrik aus. Weitere Informationen finden Sie unter [Überwachen Sie Richtlinien mithilfe von CloudWatch](monitor-dlm-cw-metrics.md).
Die folgenden Überlegungen gelten für das **Löschen von Volumes oder das Beenden von Instances, die von Snapshot-Lebenszyklus-Richtlinien betroffen sind**:
+ Wenn Sie ein Volume löschen oder eine Instance beenden, für das oder die eine Richtlinie mit einem anzahlbasierten Aufbewahrungszeitplan gilt, werden die Snapshots auf der Standard- und Archivstufe, die von dem gelöschten Volume oder der beendeten Instance erstellt wurden, nicht mehr von Amazon Data Lifecycle Manager verwaltet. Sie müssen diese früheren Snapshots manuell löschen, wenn sie nicht mehr benötigt werden.
+ Wenn Sie ein Volume löschen oder eine Instance beenden, für das oder die eine Richtlinie mit einem altersbasierten Aufbewahrungszeitplan gilt, werden die Snapshots, die von dem gelöschten Volume oder der beendeten Instance erstellt wurden, von der Richtlinie weiterhin nach dem definierten Zeitplan gelöscht, und zwar bis zum letzten Snapshot, aber nicht einschließlich. Sie müssen den letzten Snapshot manuell löschen, wenn er nicht mehr benötigt wird.
Die folgenden Überlegungen gelten für Snapshot-Lebenszyklusrichtlinien und ** [fast snapshot restore](ebs-fast-snapshot-restore.md)** (schnelle Snapshot-Wiederherstellung):
+ Amazon Data Lifecycle Manager kann die schnelle Snapshot-Wiederherstellung nur für Snapshots mit einer Größe von 16 TiB oder weniger ermöglichen. Weitere Informationen finden Sie unter [Schnelle Amazon EBS-Snapshot-Wiederherstellung](ebs-fast-snapshot-restore.md).
+ Ein Snapshot, der für die schnelle Snapshot-Wiederherstellung aktiviert ist, bleibt auch dann aktiviert, wenn Sie die Richtlinie löschen oder deaktivieren, die schnelle Snapshot-Wiederherstellung für die Richtlinie deaktivieren oder die schnelle Snapshot-Wiederherstellung für die Availability Zone deaktivieren. Sie müssen die schnelle Snapshot-Wiederherstellung für diese Snapshots manuell deaktivieren.
+ Wenn Sie die schnelle Snapshot-Wiederherstellung für eine Richtlinie aktivieren und die maximale Anzahl von Snapshots überschreiten, die für die schnelle Snapshot-Wiederherstellung aktiviert werden können, erstellt Amazon Data Lifecycle Manager Snapshots wie geplant, aktiviert sie aber nicht für die schnelle Snapshot-Wiederherstellung. Nachdem ein Snapshot, der zur einer schnellen Snapshot-Wiederherstellung fähig ist, gelöscht wurde, wird der nächste von Amazon Data Lifecycle Manager erstellte Snapshot für die schnelle Snapshot-Wiederherstellung aktiviert.
+ Wenn die schnelle Snapshot-Wiederherstellung für einen Snapshot aktiviert wird, dauert es 60 Minuten pro TiB, bis der Snapshot optimiert ist. Wir empfehlen Ihnen die Konfiguration Ihrer Zeitpläne, sodass jeder Snapshot vollständig optimiert ist, bevor Amazon Data Lifecycle Manager den nächsten Snapshot erstellt.
+ Wenn Sie die schnelle Snapshot-Wiederherstellung für eine Richtlinie aktivieren, die auf Instances abzielt, aktiviert Amazon Data Lifecycle Manager die schnelle Snapshot-Wiederherstellung individuell für jeden Snapshot im Satz von Multi-Volume-Snapshots. Wenn Amazon Data Lifecycle Manager die schnelle Snapshot-Wiederherstellung für einen der Snapshots im Satz von Multi-Volume-Snapshots nicht aktiviert, wird er weiterhin versuchen, die schnelle Snapshot-Wiederherstellung für die verbleibenden Snapshots im Snapshot-Satz zu aktivieren.
+ Es wird Ihnen jede Minute in Rechnung gestellt, in der die schnelle Snapshot-Wiederherstellung für einen Snapshot in einer bestimmten Availability Zone aktiviert ist. Die Gebühren werden mit mindestens einer Stunde anteilig bewertet. Weitere Informationen finden Sie unter [Preise und Fakturierung](ebs-fast-snapshot-restore.md#fsr-pricing).
**Anmerkung**
Abhängig von der Konfiguration Ihrer Lebenszyklusrichtlinien können mehrere Snapshots aktiviert werden, um gleichzeitig eine schnelle Snapshot-Wiederherstellung in mehreren Availability Zones zu ermöglichen.
Die folgenden Überlegungen gelten für Snapshot-Lebenszyklusrichtlinien und für ** [Multi-Attach](ebs-volumes-multi.md)-fähige Volumes**:
+ Wenn Sie eine Lebenszyklusrichtlinie erstellen, die auf Instances abzielt, die über dasselbe Multi-Attach-fähige Volume verfügen, initiiert Amazon Data Lifecycle Manager für jede angefügte Instance einen Snapshot des Volumes. Verwenden Sie das *timestamp*-Tag, um die Menge zeitkonsistenter Snapshots zu bestimmen, die von den angefügten Instances erstellt wurden.
Die folgenden Überlegungen gelten für die **kontoübergreifende Freigabe von Snapshots**:
+ Sie können nur Snapshots freigeben, die unverschlüsselt oder mit einem Kundenverwalteter Schlüssel verschlüsselt sind.
+ Sie können keine Snapshots freigeben, die mit dem standardmäßigen EBS-Verschlüsselungs-Verschlüsselung verschlüsselt sind.
+ Wenn Sie verschlüsselte Snapshots freigeben, müssen Sie auch den KMS-Schlüssel, der zum Verschlüsseln des Quell-Volumes verwendet wurde, für die Zielkonten freigeben. Weitere Informationen finden Sie unter [Benutzern in anderen Konten die Verwendung eines KMS-Schlüssels erlauben](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) im *AWS Key Management Service -Entwicklerhandbuch*.
Die folgenden Überlegungen gelten für Snapshot-Richtlinien und die ** [Snapshot–Archivierung](snapshot-archive.md)**:
+ Wenn Sie einen Snapshot, der von einer Richtlinie erstellt wurde, manuell archivieren und sich dieser Snapshot auf der Archivstufe befindet, wenn der Aufbewahrungsschwellenwert der Richtlinie erreicht wird, löscht Amazon Data Lifecycle Manager den Snapshot nicht. Amazon Data Lifecycle Manager verwaltet keine Snapshots, während sie auf der Archivstufe gespeichert sind. Wenn Sie auf der Archivstufe gespeicherte Snapshots nicht mehr benötigen, müssen Sie sie manuell löschen.
Die folgenden Überlegungen gelten für Snapshot-Richtlinien und den [Papierkorb](recycle-bin.md):
+ Wenn Amazon Data Lifecycle Manager einen Snapshot löscht und ihn an den Papierkorb sendet, wenn der Aufbewahrungsschwellenwert der Richtlinie erreicht wird, und Sie den Snapshot manuell aus dem Papierkorb wiederherstellen, müssen Sie diesen Snapshot manuell löschen, wenn er nicht mehr benötigt wird. Amazon Data Lifecycle Manager verwaltet den Snapshot nicht mehr.
+ Wenn Sie einen Snapshot, der von einer Richtlinie erstellt wurde, manuell löschen und sich dieser Snapshot im Papierkorb befindet, wenn der Aufbewahrungsschwellenwert der Richtlinie erreicht wird, löscht Amazon Data Lifecycle Manager den Snapshot nicht. Amazon Data Lifecycle Manager verwaltet die Snapshots nicht, während sie im Papierkorb gespeichert sind.
Wenn der Snapshot aus dem Papierkorb wiederhergestellt wird, bevor der Aufbewahrungsschwellenwert der Richtlinie erreicht wird, löscht Amazon Data Lifecycle Manager den Snapshot, sobald der Aufbewahrungsschwellenwert der Richtlinie erreicht wird.
Wenn der Snapshot aus dem Papierkorb wiederhergestellt wird, nachdem der Aufbewahrungsschwellenwert der Richtlinie erreicht wurde, löscht Amazon Data Lifecycle Manager den Snapshot nicht mehr. Sie müssen den Snapshot manuell löschen, wenn er nicht mehr benötigt wird.
Die folgenden Überlegungen gelten für Snapshot-Lebenszyklusrichtlinien, die sich im **error**-Status befinden:
+ Bei Richtlinien mit altersbasierten Aufbewahrungszeitplänen werden Snapshots, deren Aufbewahrungszeiträume ablaufen, während sich die Richtlinie im `error`-Status befindet, auf unbestimmte Zeit aufbewahrt. Die Snapshots müssen Sie manuell löschen. Wenn Sie die Richtlinie erneut aktivieren, setzt Amazon Data Lifecycle Manager das Löschen von Snapshots fort, wenn ihre Aufbewahrungszeiträume ablaufen.
+ Bei Richtlinien mit anzahlbasierten Aufbewahrungszeitplänen stoppt die Richtlinie das Erstellen und Löschen von Snapshots, während sie sich im `error`-Status befindet. Wenn Sie die Richtlinie erneut aktivieren, setzt Amazon Data Lifecycle Manager das Erstellen von Snapshots sowie das Löschen von Snapshots bei Erreichen des Aufbewahrungsschwellenwerts fort.
Die folgenden Überlegungen gelten für Snapshot-Richtlinien und das **[Sperren von Snapshots](ebs-snapshot-lock.md)**:
+ Wenn Sie einen von Amazon Data Lifecycle Manager erstellten Snapshot manuell sperren und dieser Snapshot bei Erreichen des Aufbewahrungsschwellenwerts des Zeitplans immer noch gesperrt ist, wird dieser Snapshot nicht mehr von Amazon Data Lifecycle Manager verwaltet. Sie müssen den Snapshot manuell löschen, wenn er nicht mehr länger benötigt wird.
+ Wenn Sie einen von Amazon Data Lifecycle Manager erstellten und für die schnelle Snapshot-Wiederherstellung aktivierten Snapshot manuell sperren und der Snapshot bei Erreichen des Aufbewahrungsschwellenwerts immer noch gesperrt ist, wird Amazon Data Lifecycle Manager die schnelle Snapshot-Wiederherstellung nicht deaktivieren oder den Snapshot löschen. Sie müssen die schnelle Snapshot-Wiederherstellung manuell deaktivieren und den Snapshot löschen, wenn er nicht mehr länger benötigt wird.
+ Wenn Sie einen Snapshot, der von Amazon Data Lifecycle Manager mit einem AMI erstellt wurde, manuell anmelden, diesen Snapshot dann sperren und er immer noch gesperrt und dem AMI zugeordnet ist, wenn der Aufbewahrungsschwellenwert erreicht wird, versucht Amazon Data Lifecycle Manager weiterhin, diesen Snapshot zu löschen. Wenn das AMI abgemeldet ist und der Snapshot entsperrt wurde, löscht Amazon Data Lifecycle Manager den Snapshot automatisch.
## Weitere Ressourcen
Weitere Informationen finden Sie im Blog [Automating Amazon EBS snapshot and AMI management using Amazon Data Lifecycle Manager](https://aws.amazon.com/blogs/storage/automating-amazon-ebs-snapshot-and-ami-management-using-amazon-dlm/) AWS storage.
# Automatisieren Sie anwendungskonsistente Snapshots mit Data Lifecycle Manager
Sie können anwendungskonsistente Snapshots mit Amazon Data Lifecycle Manager automatisieren, indem Sie in Ihren Snapshot-Lebenszyklusrichtlinien Vor- und Nach-Skripts aktivieren, die auf Instances abzielen.
Amazon Data Lifecycle Manager ist in AWS Systems Manager (Systems Manager) integriert, um anwendungskonsistente Snapshots zu unterstützen. Amazon Data Lifecycle Manager verwendet Systems-Manager-Befehlsdokumente (SSM-Befehlsdokumente), die Vor- und Nach-Skripte enthalten, um die Aktionen zu automatisieren, die für die Erstellung anwendungskonsistenter Snapshots erforderlich sind. Bevor Amazon Data Lifecycle Manager die Snapshot-Erstellung initiiert, führt er die Befehle im Pre-Skript zum Einfrieren und Leeren aus. I/O. After Amazon Data Lifecycle Manager initiates snapshot creation, it runs the commands in the post script to thaw I/O
Amazon Data Lifecycle Manager ermöglicht die Automatisierung anwendungskonsistenter Snapshots der folgenden Elemente:
+ Windows-Anwendungen unter Verwendung von Volume Shadow Copy Service (VSS)
+ SAP HANA verwendet ein AWS verwaltetes SSDM-Dokument. Weitere Informationen finden Sie unter [Amazon-EBS-Snapshots für SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/ebs-sap-hana.html).
+ Selbstverwaltete Datenbanken wie MySQL, PostgreSQL oder InterSystems IRIS mit SSM-Dokumentvorlagen
**Topics**
+ [Anforderungen an die Verwendung von Vor- und Nach-Skripten](#app-consistent-prereqs)
+ [Erste Schritte mit anwendungskonsistenten Snapshots](#app-consistent-get-started)
+ [Überlegungen zu VSS-Backups mit Amazon Data Lifecycle Manager](#app-consistent-vss)
+ [Geteilte Verantwortlichkeit für anwendungskonsistente Snapshots](#shared-responsibility)
## Anforderungen an die Verwendung von Vor- und Nach-Skripten
In der folgenden Tabelle werden die Anforderungen an die Verwendung von Vor- und Nach-Skripten mit Amazon Data Lifecycle Manager beschrieben.
| | Anwendungskonsistente Snapshots | |
| --- |--- |--- |
| Anforderung | VSS-Backup | Benutzerdefiniertes SSM-Dokument | Andere Anwendungsfälle |
| --- |--- |--- |--- |
| SSM Agent ist auf Ziel-Instances installiert und wird dort ausgeführt | ✓ | ✓ | ✓ |
| Die VSS-Systemanforderungen auf den Zielinstanzen wurden erfüllt | ✓ | | |
| VSS-fähiges Instanzprofil, das den Zielinstanzen zugeordnet ist | ✓ | | |
| Auf Zielinstanzen installierte VSS-Komponenten | ✓ | | |
| Bereiten Sie das SSM-Dokument mit Pre- und Post-Skriptbefehlen vor | | ✓ | ✓ |
| Vorbereiten der Amazon Data Lifecycle Manager Manager-IAM-Rolle, Ausführen von Vor- und Nachskripten | ✓ | ✓ | ✓ |
| Erstellen Sie eine Snapshot-Richtlinie, die auf Instances abzielt und für Vor- und Nachskripte konfiguriert ist | ✓ | ✓ | ✓ |
## Erste Schritte mit anwendungskonsistenten Snapshots
In diesem Abschnitt werden die Schritte erläutert, die Sie ausführen müssen, um anwendungskonsistente Snapshots mit Amazon Data Lifecycle Manager zu automatisieren.
### Schritt 1: Vorbereiten der Ziel-Instances
Sie müssen die Ziel-Instances für anwendungskonsistente Snapshots mit Amazon Data Lifecycle Manager vorbereiten. Führen Sie je nach Anwendungsfall einen der folgenden Schritte durch.
------
#### [ Prepare for VSS Backups ]
**Zur Vorbereitung Ihrer Ziel-Instances für VSS-Backups**
1. Installieren Sie den SSM-Agent auf Ihren Ziel-Instances, falls noch nicht geschehen. Wenn der SSM-Agent bereits auf Ihren Ziel-Instances installiert ist, überspringen Sie diesen Schritt.
Weitere Informationen finden Sie unter [Arbeiten mit SSM Agent auf EC2-Instances für Windows Server](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html).
1. Stellen Sie sicher, dass der SSM-Agent ausgeführt wird. Weitere Informationen finden Sie unter [Prüfen des Status des SSM-Agents und Starten des Agenten](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Richten Sie Systems Manager für Amazon-EC2-Instances ein. Weitere Informationen finden Sie unter [Einrichtung von Systems Manager für Amazon-EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) im *AWS Systems Manager -Benutzerhandbuch*.
1. [ Stellen Sie sicher, dass die Systemanforderungen für VSS-Backups erfüllt sind](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-prereqs.html).
1. [ Hängen Sie ein VSS-fähiges Instance-Profil an die Ziel-Instances an](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vss-iam-reqs.html).
1. [ Installieren Sie die VSS-Komponenten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-getting-started.html).
------
#### [ Prepare for SAP HANA backups ]
**Zur Vorbereitung Ihrer Ziel-Instances für SAP–HANA-Backups**
1. Bereiten Sie die SAP-HANA-Umgebung auf Ihre Ziel-Instances vor.
1. Richten Sie Ihre Instance mit SAP HANA ein. Wenn Sie noch nicht über eine bestehende SAP-HANA-Umgebung verfügen, finden Sie unter [Einrichtung einer SAP-HANA-Umgebung auf AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/std-sap-hana-environment-setup.html) weitere Informationen.
1. Melden Sie sich als geeigneter Administratorbenutzer bei der SystemDB an.
1. Erstellen Sie einen Datenbank-Backup-Benutzer, der mit Amazon Data Lifecycle Manager verwendet werden soll.
```
CREATE USER username PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
```
Mit dem folgenden Befehl wird beispielsweise ein Benutzer mit dem Namen `dlm_user` und dem Passwort `password` erstellt.
```
CREATE USER dlm_user PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
```
1. Weisen Sie die `BACKUP OPERATOR`-Rolle dem Datenbank-Backup-Benutzer zu, den Sie im vorherigen Schritt erstellt haben.
```
GRANT BACKUP OPERATOR TO username
```
Mit dem folgenden Befehl wird die Rolle beispielsweise einem Benutzer mit dem Namen `dlm_user` zugewiesen.
```
GRANT BACKUP OPERATOR TO dlm_user
```
1. Melden Sie sich als Administrator beim Betriebssystem an, beispielsweise `sidadm`.
1. Erstellen Sie einen `hdbuserstore`-Eintrag zum Speichern von Verbindungsinformationen, sodass das SAP-HANA-SSM-Dokument eine Verbindung zu SAP HANA herstellen kann, ohne dass Benutzer die Informationen eingeben müssen.
```
hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:3hana_instance_number13 username password
```
Beispiel:
```
hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:30013 dlm_user password
```
1. Testen Sie die Verbindung.
```
hdbsql -U DLM_HANADB_SNAPSHOT_USER "select * from dummy"
```
1. Installieren Sie den SSM-Agent auf Ihren Ziel-Instances, falls noch nicht geschehen. Wenn der SSM-Agent bereits auf Ihren Ziel-Instances installiert ist, überspringen Sie diesen Schritt.
Weitere Informationen finden Sie unter [Manuelles Installieren des SSM-Agenten auf EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) für Linux.
1. Stellen Sie sicher, dass der SSM-Agent ausgeführt wird. Weitere Informationen finden Sie unter [Prüfen des Status des SSM-Agents und Starten des Agenten](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Richten Sie Systems Manager für Amazon-EC2-Instances ein. Weitere Informationen finden Sie unter [Einrichtung von Systems Manager für Amazon-EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) im *AWS Systems Manager -Benutzerhandbuch*.
------
#### [ Prepare for custom SSM documents ]
**Vorbereitung benutzerdefinierter SSM-Dokumente für Ihre Ziel-Instances**
1. Installieren Sie den SSM-Agent auf Ihren Ziel-Instances, falls noch nicht geschehen. Wenn der SSM-Agent bereits auf Ihren Ziel-Instances installiert ist, überspringen Sie diesen Schritt.
+ (Linux-Instances) [Manuelles Installieren des SSM-Agenten auf EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) für Linux
+ (Windows-Instanzen) [Arbeiten mit SSM Agent auf EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) für Windows Server
1. Stellen Sie sicher, dass der SSM-Agent ausgeführt wird. Weitere Informationen finden Sie unter [Prüfen des Status des SSM-Agents und Starten des Agenten](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Richten Sie Systems Manager für Amazon-EC2-Instances ein. Weitere Informationen finden Sie unter [Einrichtung von Systems Manager für Amazon-EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) im *AWS Systems Manager -Benutzerhandbuch*.
------
### Schritt 2: Vorbereiten des SSM-Dokuments
**Anmerkung**
Dieser Schritt ist nur für benutzerdefinierte SSM-Dokumente erforderlich. Für VSS-Backup oder SAP HANA ist er nicht erforderlich. Für VSS-Backups und SAP HANA verwendet Amazon Data Lifecycle Manager das AWS verwaltete SSM-Dokument.
Wenn Sie anwendungskonsistente Snapshots für eine selbstverwaltete Datenbank wie MySQL, PostgreSQL oder InterSystems IRIS automatisieren, müssen Sie ein SSM-Befehlsdokument erstellen, das ein Pre-Skript zum Einfrieren und Leeren enthält, I/O bevor die Snapshot-Erstellung initiiert wird, und ein Post-Skript zum Auftauen nach der Snapshot-Erstellung. I/O
Wenn Ihre MySQL-, PostgreSQL- oder InterSystems IRIS-Datenbank Standardkonfigurationen verwendet, können Sie mithilfe des folgenden SSM-Beispieldokuments ein SSM-Befehlsdokument erstellen. Wenn Ihre MySQL-, PostgreSQL- oder InterSystems IRIS-Datenbank eine nicht standardmäßige Konfiguration verwendet, können Sie den folgenden Beispielinhalt als Ausgangspunkt für Ihr SSM-Befehlsdokument verwenden und es dann an Ihre Anforderungen anpassen. Wenn Sie ein SSM-Dokument von Grund auf neu erstellen möchten, können Sie alternativ die leere SSM-Dokumentvorlage unten verwenden und Ihre Vor- und Nach-Befehle in den entsprechenden Dokumentabschnitten hinzufügen.
**Beachten Sie Folgendes:**
Sie müssen sicherstellen, dass das SSM-Dokument die richtigen und erforderlichen Aktionen für Ihre Datenbankkonfiguration ausführt.
Snapshots sind nur dann garantiert anwendungskonsistent, wenn die Vor- und Nach-Skripte in Ihrem SSM-Dokument die I/O erfolgreich einfrieren, leeren und wieder auftauen können.
Das SSM-Dokument muss die erforderlichen Felder für `allowedValues` enthalten, einschließlich `pre-script`, `post-script` und `dry-run`. Amazon Data Lifecycle Manager führt Befehle auf Ihrer Instance basierend auf den Inhalten dieser Abschnitte aus. Wenn Ihr SSM-Dokument diese Abschnitte nicht enthält, behandelt Amazon Data Lifecycle Manager dies als fehlgeschlagene Ausführung.
------
#### [ MySQL sample document content ]
```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: Amazon Data Lifecycle Manager Pre/Post script for MySQL databases
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run MySQL Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###=================================================================###
### Global variables
###=================================================================###
START=$(date +%s)
# For testing this script locally, replace the below with OPERATION=$1.
OPERATION={{ command }}
FS_ALREADY_FROZEN_ERROR='freeze failed: Device or resource busy'
FS_ALREADY_THAWED_ERROR='unfreeze failed: Invalid argument'
FS_BUSY_ERROR='mount point is busy'
# Auto thaw is a fail safe mechanism to automatically unfreeze the application after the
# duration specified in the global variable below. Choose the duration based on your
# database application's tolerance to freeze.
export AUTO_THAW_DURATION_SECS="60"
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
# Check if filesystem is already frozen. No error code indicates that filesystem
# is not currently frozen and that the pre-script can proceed with freezing the filesystem.
check_fs_freeze
# Execute the DB commands to flush the DB in preparation for snapshot
snap_db
# Freeze the filesystem. No error code indicates that filesystem was succefully frozen
freeze_fs
echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds."
$(nohup bash -c execute_schedule_auto_thaw >/dev/null 2>&1 &)
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
# Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen.
unfreeze_fs
thaw_db
}
# Execute Auto Thaw to automatically unfreeze the application after the duration configured
# in the AUTO_THAW_DURATION_SECS global variable.
execute_schedule_auto_thaw() {
sleep ${AUTO_THAW_DURATION_SECS}
execute_post_script
}
# Disable Auto Thaw if it is still enabled
execute_disable_auto_thaw() {
echo "INFO: Attempting to disable auto thaw if enabled"
auto_thaw_pgid=$(pgrep -f execute_schedule_auto_thaw | xargs -i ps -hp {} -o pgid)
if [ -n "${auto_thaw_pgid}" ]; then
echo "INFO: execute_schedule_auto_thaw process found with pgid ${auto_thaw_pgid}"
sudo pkill -g ${auto_thaw_pgid}
rc=$?
if [ ${rc} != 0 ]; then
echo "ERROR: Unable to kill execute_schedule_auto_thaw process. retval=${rc}"
else
echo "INFO: Auto Thaw has been disabled"
fi
fi
}
# Iterate over all the mountpoints and check if filesystem is already in freeze state.
# Return error code 204 if any of the mount points are already frozen.
check_fs_freeze() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, we will skip the root and boot mountpoints while checking if filesystem is in freeze state.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
error_message=$(sudo mount -o remount,noatime $target 2>&1)
# Remount will be a no-op without a error message if the filesystem is unfrozen.
# However, if filesystem is already frozen, remount will fail with busy error message.
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_BUSY_ERROR"* ]];then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
exit 204
fi
# If the check filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to check_fs_freeze on mountpoint $target due to error - $errormessage"
exit 201
fi
done
}
# Iterate over all the mountpoints and freeze the filesystem.
freeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze
# operations for root and boot mountpoints.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Freezing $target"
error_message=$(sudo fsfreeze -f $target 2>&1)
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
sudo mysql -e 'UNLOCK TABLES;'
exit 204
fi
# If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage"
thaw_db
exit 201
fi
echo "INFO: Freezing complete on $target"
done
}
# Iterate over all the mountpoints and unfreeze the filesystem.
unfreeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, will skip the root and boot mountpoints during unfreeze as well.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Thawing $target"
error_message=$(sudo fsfreeze -u $target 2>&1)
# Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen.
if [ $? -ne 0 ]; then
if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205"
exit 205
fi
# If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202
echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage"
exit 202
fi
echo "INFO: Thaw complete on $target"
done
}
snap_db() {
# Run the flush command only when MySQL DB service is up and running
sudo systemctl is-active --quiet mysqld.service
if [ $? -eq 0 ]; then
echo "INFO: Execute MySQL Flush and Lock command."
sudo mysql -e 'FLUSH TABLES WITH READ LOCK;'
# If the MySQL Flush and Lock command did not succeed, return error code 201 to indicate pre-script failure
if [ $? -ne 0 ]; then
echo "ERROR: MySQL FLUSH TABLES WITH READ LOCK command failed."
exit 201
fi
sync
else
echo "INFO: MySQL service is inactive. Skipping execution of MySQL Flush and Lock command."
fi
}
thaw_db() {
# Run the unlock command only when MySQL DB service is up and running
sudo systemctl is-active --quiet mysqld.service
if [ $? -eq 0 ]; then
echo "INFO: Execute MySQL Unlock"
sudo mysql -e 'UNLOCK TABLES;'
else
echo "INFO: MySQL service is inactive. Skipping execution of MySQL Unlock command."
fi
}
export -f execute_schedule_auto_thaw
export -f execute_post_script
export -f unfreeze_fs
export -f thaw_db
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
execute_disable_auto_thaw
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```
------
#### [ PostgreSQL sample document content ]
```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: Amazon Data Lifecycle Manager Pre/Post script for PostgreSQL databases
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run PostgreSQL Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###===============================================================================###
### Global variables
###===============================================================================###
START=$(date +%s)
OPERATION={{ command }}
FS_ALREADY_FROZEN_ERROR='freeze failed: Device or resource busy'
FS_ALREADY_THAWED_ERROR='unfreeze failed: Invalid argument'
FS_BUSY_ERROR='mount point is busy'
# Auto thaw is a fail safe mechanism to automatically unfreeze the application after the
# duration specified in the global variable below. Choose the duration based on your
# database application's tolerance to freeze.
export AUTO_THAW_DURATION_SECS="60"
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
# Check if filesystem is already frozen. No error code indicates that filesystem
# is not currently frozen and that the pre-script can proceed with freezing the filesystem.
check_fs_freeze
# Execute the DB commands to flush the DB in preparation for snapshot
snap_db
# Freeze the filesystem. No error code indicates that filesystem was succefully frozen
freeze_fs
echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds."
$(nohup bash -c execute_schedule_auto_thaw >/dev/null 2>&1 &)
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
# Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen
unfreeze_fs
}
# Execute Auto Thaw to automatically unfreeze the application after the duration configured
# in the AUTO_THAW_DURATION_SECS global variable.
execute_schedule_auto_thaw() {
sleep ${AUTO_THAW_DURATION_SECS}
execute_post_script
}
# Disable Auto Thaw if it is still enabled
execute_disable_auto_thaw() {
echo "INFO: Attempting to disable auto thaw if enabled"
auto_thaw_pgid=$(pgrep -f execute_schedule_auto_thaw | xargs -i ps -hp {} -o pgid)
if [ -n "${auto_thaw_pgid}" ]; then
echo "INFO: execute_schedule_auto_thaw process found with pgid ${auto_thaw_pgid}"
sudo pkill -g ${auto_thaw_pgid}
rc=$?
if [ ${rc} != 0 ]; then
echo "ERROR: Unable to kill execute_schedule_auto_thaw process. retval=${rc}"
else
echo "INFO: Auto Thaw has been disabled"
fi
fi
}
# Iterate over all the mountpoints and check if filesystem is already in freeze state.
# Return error code 204 if any of the mount points are already frozen.
check_fs_freeze() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, we will skip the root and boot mountpoints while checking if filesystem is in freeze state.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
error_message=$(sudo mount -o remount,noatime $target 2>&1)
# Remount will be a no-op without a error message if the filesystem is unfrozen.
# However, if filesystem is already frozen, remount will fail with busy error message.
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_BUSY_ERROR"* ]];then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
exit 204
fi
# If the check filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to check_fs_freeze on mountpoint $target due to error - $errormessage"
exit 201
fi
done
}
# Iterate over all the mountpoints and freeze the filesystem.
freeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze
# operations for root and boot mountpoints.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Freezing $target"
error_message=$(sudo fsfreeze -f $target 2>&1)
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204
if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
exit 204
fi
# If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201
echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage"
exit 201
fi
echo "INFO: Freezing complete on $target"
done
}
# Iterate over all the mountpoints and unfreeze the filesystem.
unfreeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems.
# Hence, will skip the root and boot mountpoints during unfreeze as well.
if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Thawing $target"
error_message=$(sudo fsfreeze -u $target 2>&1)
# Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen.
if [ $? -ne 0 ]; then
if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205"
exit 205
fi
# If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202
echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage"
exit 202
fi
echo "INFO: Thaw complete on $target"
done
}
snap_db() {
# Run the flush command only when PostgreSQL DB service is up and running
sudo systemctl is-active --quiet postgresql
if [ $? -eq 0 ]; then
echo "INFO: Execute Postgres CHECKPOINT"
# PostgreSQL command to flush the transactions in memory to disk
sudo -u postgres psql -c 'CHECKPOINT;'
# If the PostgreSQL Command did not succeed, return error code 201 to indicate pre-script failure
if [ $? -ne 0 ]; then
echo "ERROR: Postgres CHECKPOINT command failed."
exit 201
fi
sync
else
echo "INFO: PostgreSQL service is inactive. Skipping execution of CHECKPOINT command."
fi
}
export -f execute_schedule_auto_thaw
export -f execute_post_script
export -f unfreeze_fs
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
execute_disable_auto_thaw
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```
------
#### [ InterSystems IRIS sample document content ]
```
###===============================================================================###
# MIT License
#
# Copyright (c) 2024 InterSystems
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature for InterSystems IRIS.
parameters:
executionId:
type: String
default: None
description: Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
type: String
# Data Lifecycle Manager will trigger the pre-script and post-script actions. You can also use this SSM document with 'dry-run' for manual testing purposes.
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
#The following allowedValues will allow Data Lifecycle Manager to successfully trigger pre and post script actions.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run InterSystems IRIS Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Global variables
###===============================================================================###
DOCKER_NAME=iris
LOGDIR=./
EXIT_CODE=0
OPERATION={{ command }}
START=$(date +%s)
# Check if Docker is installed
# By default if Docker is present, script assumes that InterSystems IRIS is running in Docker
# Leave only the else block DOCKER_EXEC line, if you run InterSystems IRIS non-containerised (and Docker is present).
# Script assumes irissys user has OS auth enabled, change the OS user or supply login/password depending on your configuration.
if command -v docker &> /dev/null
then
DOCKER_EXEC="docker exec $DOCKER_NAME"
else
DOCKER_EXEC="sudo -i -u irissys"
fi
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
# find all iris running instances
iris_instances=$($DOCKER_EXEC iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}')
echo "`date`: Running iris instances $iris_instances"
# Only for running instances
for INST in $iris_instances; do
echo "`date`: Attempting to freeze $INST"
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
#check Freeze status before starting
$DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).IsWDSuspendedExt()"
freeze_status=$?
if [ $freeze_status -eq 5 ]; then
echo "`date`: ERROR: $INST IS already FROZEN"
EXIT_CODE=204
else
echo "`date`: $INST is not frozen"
# Freeze
# Docs: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreeze
$DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).ExternalFreeze(\"$LOGFILE\",,,,,,600,,,300)"
status=$?
case $status in
5) echo "`date`: $INST IS FROZEN"
;;
3) echo "`date`: $INST FREEZE FAILED"
EXIT_CODE=201
;;
*) echo "`date`: ERROR: Unknown status code: $status"
EXIT_CODE=201
;;
esac
echo "`date`: Completed freeze of $INST"
fi
done
echo "`date`: Pre freeze script finished"
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
# find all iris running instances
iris_instances=$($DOCKER_EXEC iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}')
echo "`date`: Running iris instances $iris_instances"
# Only for running instances
for INST in $iris_instances; do
echo "`date`: Attempting to thaw $INST"
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
#check Freeze status befor starting
$DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).IsWDSuspendedExt()"
freeze_status=$?
if [ $freeze_status -eq 5 ]; then
echo "`date`: $INST is in frozen state"
# Thaw
# Docs: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreeze
$DOCKER_EXEC irissession $INST -U%SYS "##Class(Backup.General).ExternalThaw(\"$LOGFILE\")"
status=$?
case $status in
5) echo "`date`: $INST IS THAWED"
$DOCKER_EXEC irissession $INST -U%SYS "##Class(Backup.General).ExternalSetHistory(\"$LOGFILE\")"
;;
3) echo "`date`: $INST THAW FAILED"
EXIT_CODE=202
;;
*) echo "`date`: ERROR: Unknown status code: $status"
EXIT_CODE=202
;;
esac
echo "`date`: Completed thaw of $INST"
else
echo "`date`: ERROR: $INST IS already THAWED"
EXIT_CODE=205
fi
done
echo "`date`: Post thaw script finished"
}
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
# return failure
EXIT_CODE=1
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
exit $EXIT_CODE
```
[Weitere Informationen finden Sie im Repository. GitHub ](https://github.com/intersystems-community/aws/blob/master/README.md)
------
#### [ Empty document template ]
```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###===============================================================================###
### Global variables
###===============================================================================###
START=$(date +%s)
# For testing this script locally, replace the below with OPERATION=$1.
OPERATION={{ command }}
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
}
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```
------
Sobald Sie über den Inhalt Ihres SSM-Dokuments verfügen, verwenden Sie eines der folgenden Verfahren, um das benutzerdefinierte SSM-Dokument zu erstellen.
------
#### [ Console ]
**Erstellen eines SSM-Befehlsdokuments**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com//systems-manager/](https://console.aws.amazon.com//systems-manager/).
1. Wählen Sie im Navigationsbereich **Dokumente** und dann **Dokument erstellen**, **Befehl oder Sitzung** aus.
1. Geben Sie unter **Name** einen aussagekräftigen Namen für das Dokument ein.
1. Wählen Sie als **Zieltyp** die Option**/**ausAWS::EC2::Instance.
1. Wählen Sie als **Dokumenttyp** **Befehl**.
1. Wählen Sie im Feld **Inhalt** die Option **YAML** aus und fügen Sie dann den Inhalt des Dokuments ein.
1. Fügen Sie im Abschnitt **Dokument-Tags** ein Tag mit einem Tag-Schlüssel von `DLMScriptsAccess` und einem Tag-Wert von `true` hinzu.
**Wichtig**
Das `DLMScriptsAccess:true` Tag ist für die in *Schritt 3: Vorbereiten der Amazon Data Lifecycle AWS Manager-IAM-Rolle verwendete **AWSDataLifecycleManagerSSMFullAccess** Manager-Richtlinie* erforderlich. Die Richtlinie verwendet den `aws:ResourceTag`-Bedingungsschlüssel, um den Zugriff auf SSM-Dokumente mit diesem Tag einzuschränken.
1. Wählen Sie **Create document** (Dokument erstellen) aus.
------
#### [ AWS CLI ]
**Erstellen eines SSM-Befehlsdokuments**
Verwenden Sie den Befehl [create-document](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html). Geben Sie für `--name` einen beschreibenden Namen für das Dokument ein. Legen Sie für `--document-type` die Option `Command` fest. Geben Sie für `--content` den Pfad zur .yaml-Datei mit dem SSM-Dokumentinhalt an. Legen Sie für `--tags` die Option `"Key=DLMScriptsAccess,Value=true"` fest.
```
$ aws ssm create-document \
--content file://path/to/file/documentContent.yaml \
--name "document_name" \
--document-type "Command" \
--document-format YAML \
--tags "Key=DLMScriptsAccess,Value=true"
```
------
### Schritt 3: Vorbereiten der IAM-Rolle für Amazon Data Lifecycle Manager
**Anmerkung**
Dieser Schritt ist erforderlich, wenn:
Sie erstellen oder aktualisieren eine pre/post skriptfähige Snapshot-Richtlinie, die eine benutzerdefinierte IAM-Rolle verwendet.
Sie verwenden die Befehlszeile, um eine pre/post skriptfähige Snapshot-Richtlinie zu erstellen oder zu aktualisieren, die den Standard verwendet.
Wenn Sie die Konsole verwenden, um eine pre/post skriptfähige Snapshot-Richtlinie zu erstellen oder zu aktualisieren, die die Standardrolle für die Verwaltung von Snapshots (**AWSDataLifecycleManagerDefaultRole**) verwendet, überspringen Sie diesen Schritt. In diesem Fall hängen wir die **AWSDataLifecycleManagerSSMFullZugriffsrichtlinie** automatisch an diese Rolle an.
Sie müssen sicherstellen, dass die für die Richtlinie verwendete IAM-Rolle Amazon Data Lifecycle Manager die Erlaubnis erteilt, die SSM-Aktionen auszuführen, die für die Ausführung von Vor- und Nach-Skripten auf Instances, auf die die Richtlinie abzielt, erforderlich sind.
Amazon Data Lifecycle Manager bietet eine verwaltete Richtlinie (**AWSDataLifecycleManagerSSMFullAccess**), die die erforderlichen Berechtigungen beinhaltet. Sie können diese Richtlinie an Ihre IAM-Rolle für die Verwaltung von Snapshots anhängen, um sicherzustellen, dass sie die entsprechenden Berechtigungen beinhaltet.
**Wichtig**
Die verwaltete AWSData LifecycleManager SSMFull Access-Richtlinie verwendet den `aws:ResourceTag` Bedingungsschlüssel, um den Zugriff auf bestimmte SSM-Dokumente einzuschränken, wenn Pre- und Post-Skripte verwendet werden. Damit Amazon Data Lifecycle Manager auf die SSM-Dokumente zugreifen kann, müssen Sie sicherstellen, dass Ihre SSM-Dokumente das Tag `DLMScriptsAccess:true` enthalten.
Alternativ können Sie manuell eine benutzerdefinierte Richtlinie erstellen oder die erforderlichen Berechtigungen direkt der von Ihnen verwendeten IAM-Rolle zuweisen. Sie können dieselben Berechtigungen verwenden, die in der verwalteten AWSData LifecycleManager SSMFull Access-Richtlinie definiert sind, der `aws:ResourceTag` Bedingungsschlüssel ist jedoch optional. Wenn Sie sich dafür entscheiden, diesen Bedingungsschlüssel nicht zu verwenden, müssen Sie Ihre SSM-Dokumente nicht mit `DLMScriptsAccess:true` markieren.
Verwenden Sie eine der folgenden Methoden, um die **AWSDataLifecycleManagerSSMFullAccess-Richtlinie** zu Ihrer IAM-Rolle hinzuzufügen.
------
#### [ Console ]
**So hängen Sie die verwaltete Richtlinie an Ihre benutzerdefinierte Rolle an**
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im Navigationspanel **Rollen** aus.
1. Suchen Sie nach Ihrer benutzerdefinierten Rolle zur Verwaltung von Snapshots und wählen Sie sie aus.
1. Wählen Sie auf der Registerkarte **Berechtigungen** **Berechtigungen hinzufügen** und dann **Richtlinien anfügen** aus.
1. Suchen Sie nach der verwalteten **AWSDataLifecycleManagerSSMFullAccess-Richtlinie**, wählen Sie sie aus und klicken Sie dann auf **Berechtigungen hinzufügen**.
------
#### [ AWS CLI ]
**So hängen Sie die verwaltete Richtlinie an Ihre benutzerdefinierte Rolle an**
Verwenden Sie den Befehl [ attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Geben Sie für `---role-name` den Namen Ihrer benutzerdefinierten Rolle an. Legen Sie für `--policy-arn` die Option `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess` fest.
```
$ aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
```
------
### Schritt 4: Erstellen der Snapshot-Lebenszyklusrichtlinie
Um anwendungskonsistente Snapshots zu automatisieren, müssen Sie eine Snapshot-Lebenszyklusrichtlinie für Instances erstellen und Vor- und Nach-Skripte für diese Richtlinie konfigurieren.
------
#### [ Console ]
**So erstellen Sie die Snapshot-Lebenszyklusrichtlinie**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Elastic Block Store** und **Lifecycle Manager** aus. Wählen Sie dann **Create lifecycle policy (Lebenszyklusrichtlinie erstellen)** aus.
1. Wählen Sie auf dem Bildschirm **Richtlinientyp auswählen** die Option **EBS-Snapshot-Richtlinie** und dann **Weiter** aus.
1. Gehen Sie im Abschnitt **Zielressourcen** wie folgt vor:
1. Wählen Sie für **Ziel-Ressourcentypen** die Option `Instance`.
1. Geben Sie für **Zielressourcen-Tags** die Ressourcen-Tags an, die die zu sichernden Instances identifizieren. Nur Ressourcen mit den angegebenen Tags werden gesichert.
1. Wählen Sie für die **IAM-Rolle** entweder **AWSDataLifecycleManagerDefaultRole**(die Standardrolle für die Verwaltung von Snapshots) oder eine benutzerdefinierte Rolle, die Sie für Vor- und Nachskripte erstellt und vorbereitet haben.
1. Konfigurieren Sie die Zeitpläne und zusätzlichen Optionen nach Bedarf. Wir empfehlen Ihnen, die Snapshot-Erstellung für Zeiträume einzuplanen, die Ihrem Workload entsprechen, z. B. während Wartungsfenstern.
Für SAP HANA empfehlen wir, die schnelle Snapshot-Wiederherstellung zu aktivieren.
**Anmerkung**
Wenn Sie einen Zeitplan für VSS-Backups aktivieren, können Sie die Optionen **Ausschließen bestimmter Daten-Volumes** oder **Tags aus der Quelle kopieren** nicht aktivieren.
1. Wählen Sie im Abschnitt **Vor- und Nach-Skripte** die Option **Vor- und Nach-Skripte aktivieren** aus und gehen Sie dann je nach Workload wie folgt vor:
+ Um anwendungskonsistente Snapshots Ihrer Windows-Anwendungen zu erstellen, wählen Sie **VSS-Backup**.
+ Um anwendungskonsistente Snapshots Ihrer SAP-HANA-Workloads zu erstellen, wählen Sie **SAP HANA**.
+ **Um mithilfe eines benutzerdefinierten SSM-Dokuments anwendungskonsistente Snapshots aller anderen Datenbanken und Workloads zu erstellen, einschließlich Ihrer selbstverwalteten MySQL-, PostgreSQL- oder InterSystems IRIS-Datenbanken, wählen Sie Benutzerdefiniertes SSM-Dokument aus.**
1. Wählen Sie für **Option automatisieren** **Vor- und Nach-Skripte** aus.
1. Wählen Sie unter **SSM-Dokument** das SSM-Dokument aus, das Sie vorbereitet haben.
1. Konfigurieren Sie je nach der ausgewählten Option die folgenden zusätzlichen Optionen:
+ **Timeout für das Skript** – (*nur benutzerdefiniertes SSM-Dokument*) Der Timeout-Zeitraum, nach dem Amazon Data Lifecycle Manager die versuchte Skriptausführung als fehlgeschlagen behandelt, wenn sie nicht abgeschlossen wurde. Wenn ein Skript nicht innerhalb des Timeout-Zeitraums abgeschlossen wird, schlägt der Versuch von Amazon Data Lifecycle Manager fehl. Der Timeout-Zeitraum gilt für die Vor- und Nach-Skripte einzeln. Der Minimal- und Standardwert für den Timeout beträgt 10 Sekunden. Die maximale Timeout-Zeit beträgt 120 Sekunden.
+ **Fehlgeschlagene Skripte erneut versuchen** – Wählen Sie diese Option, um Skripte zu wiederholen, die nicht innerhalb ihres Timeouts abgeschlossen werden. Wenn das Vor-Skript fehlschlägt, wiederholt Amazon Data Lifecycle Manager den gesamten Snapshot-Erstellungsprozess, einschließlich der Ausführung der Vor- und Nach-Skripte. Wenn das Nach-Skript fehlschlägt, wiederholt Amazon Data Lifecycle Manager nur das Nach-Skript. In diesem Fall ist das Vor-Skript abgeschlossen und der Snapshot wurde möglicherweise erstellt.
+ **Standardmäßig absturzkonsistente Snapshots** – Wählen Sie diese Option, um standardmäßig absturzkonsistente Snapshots zu verwenden, falls das Vor-Skript nicht ausgeführt werden kann. Dies ist das Standardverhalten bei der Snapshot-Erstellung für Amazon Data Lifecycle Manager, wenn Vor- und Nach-Skripte nicht aktiviert sind. Wenn Sie Wiederholungen aktiviert haben, verwendet Amazon Data Lifecycle Manager standardmäßig nur dann absturzkonsistente Snapshots, wenn alle Wiederholungsversuche ausgeschöpft sind. Wenn das Vor-Skript fehlschlägt und Sie nicht standardmäßig absturzkonsistente Snapshots verwenden, erstellt Amazon Data Lifecycle Manager während dieser geplanten Ausführung keine Snapshots für die Instance.
**Anmerkung**
Wenn Sie Snapshots für SAP HANA erstellen, sollten Sie diese Option unter Umständen deaktivieren. Absturzkonsistente Snapshots von SAP-HANA-Workloads können nicht auf dieselbe Weise wiederhergestellt werden.
1. Wählen Sie **Standardrichtlinie erstellen**.
**Anmerkung**
Falls Sie den Fehler `Role with name AWSDataLifecycleManagerDefaultRole already exists` erhalten, finden Sie weitere Informationen unter [Probleme mit Amazon Data Lifecycle Manager beheben](dlm-troubleshooting.md).
------
#### [ AWS CLI ]
**So erstellen Sie die Snapshot-Lebenszyklusrichtlinie**
Verwenden Sie den Befehl und fügen Sie die Parameter in ein. [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)`Scripts``CreateRule` Weitere Informationen finden Sie in der [https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html](https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html).
```
$ aws dlm create-lifecycle-policy \
--description "policy_description" \
--state ENABLED \
--execution-role-arn iam_role_arn \
--policy-details file://policyDetails.json
```
Wenn `policyDetails.json` einen der folgenden Aspekte beinhaltet, gehen Sie je nach Anwendungsfall wie folgt vor:
+ **VSS-Backup**
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key",
"Value": "tag_value"
}],
"Schedules": [{
"Name": "schedule_name",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency",
"Scripts": [{
"ExecutionHandler":"AWS_VSS_BACKUP",
"ExecuteOperationOnScriptFailure":true|false,
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
```
+ **SAP-HANA-Backups**
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key",
"Value": "tag_value"
}],
"Schedules": [{
"Name": "schedule_name",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency",
"Scripts": [{
"Stages": ["PRE","POST"],
"ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
"ExecutionHandler":"AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA",
"ExecuteOperationOnScriptFailure":true|false,
"ExecutionTimeout":timeout_in_seconds (10-120),
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
```
+ **Benutzerdefiniertes SSM-Dokument**
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key",
"Value": "tag_value"
}],
"Schedules": [{
"Name": "schedule_name",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency",
"Scripts": [{
"Stages": ["PRE","POST"],
"ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
"ExecutionHandler":"ssm_document_name|arn",
"ExecuteOperationOnScriptFailure":true|false,
"ExecutionTimeout":timeout_in_seconds (10-120),
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
```
------
## Überlegungen zu VSS-Backups mit Amazon Data Lifecycle Manager
Mit Amazon Data Lifecycle Manager können Sie VSS-fähige Windows-Anwendungen (Volume Shadow Copy Service), die auf Amazon-EC2-Instances ausgeführt werden, sichern und wiederherstellen. Wenn für die Anwendung ein VSS-Schreiber bei Windows VSS registriert ist, erstellt Amazon Data Lifecycle Manager einen Snapshot, der für diese Anwendung anwendungskonsistent ist.
**Anmerkung**
Amazon Data Lifecycle Manager unterstützt derzeit nur anwendungskonsistente Snapshots von Ressourcen, die auf Amazon EC2 ausgeführt werden, insbesondere für Sicherungsszenarien, in denen Anwendungsdaten wiederhergestellt werden können, indem eine bestehende Instance durch eine neue, aus der Sicherung erstellte Instance ersetzt wird. Nicht alle Instance-Typen oder Anwendungen werden für VSS-Backups unterstützt. Weitere Informationen finden Sie unter [Anwendungskonsistente Windows VSS-Snapshots](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html) im *Amazon* EC2 EC2-Benutzerhandbuch.
**Nicht unterstützte Instance-Typen**
Die folgenden Instance-Typen von Amazon EC2 werden für VSS-Backups nicht unterstützt. Wenn Ihre Richtlinie auf einen dieser Instance-Typen abzielt, erstellt Amazon Data Lifecycle Manager möglicherweise trotzdem VSS-Backups, aber die Snapshots sind unter Umständen nicht mit den erforderlichen System-Tags gekennzeichnet. Ohne diese Tags werden die Snapshots nach der Erstellung nicht von Amazon Data Lifecycle Manager verwaltet. Sie müssen diese Snapshots möglicherweise manuell löschen.
+ T3: `t3.nano` \$1 `t3.micro`
+ T3a: `t3a.nano` \$1 `t3a.micro`
+ T2: `t2.nano` \$1 `t2.micro`
## Geteilte Verantwortlichkeit für anwendungskonsistente Snapshots
**Sie müssen Folgendes sicherstellen:**
+ Der SSM-Agent ist installiert und wird auf Ihren Ziel-Instances up-to-date ausgeführt
+ Systems Manager verfügt über Berechtigungen zum Ausführen der erforderlichen Aktionen auf den Ziel-Instances.
+ Amazon Data Lifecycle Manager ist berechtigt, die Systems-Manager-Aktionen auszuführen, die für die Ausführung von Vor- und Nach-Skripten auf den Ziel-Instances erforderlich sind.
+ Für benutzerdefinierte Workloads, wie z. B. selbstverwaltete MySQL-, PostgreSQL- oder InterSystems IRIS-Datenbanken, enthält das von Ihnen verwendete SSM-Dokument die richtigen und erforderlichen Aktionen zum Einfrieren, Leeren und Auftauen für Ihre Datenbankkonfiguration. I/O
+ Die Zeiten für die Snapshot-Erstellung richten sich nach Ihrem Workload-Zeitplan. Versuchen Sie beispielsweise, die Snapshot-Erstellung für geplante Wartungsfenster einzuplanen.
**Amazon Data Lifecycle Manager stellt sicher, dass:**
+ Die Snapshot-Erstellung wird innerhalb von 60 Minuten nach der geplanten Snapshot-Erstellung initiiert.
+ Vor-Skripte werden ausgeführt, bevor die Snapshot-Erstellung initiiert wird.
+ Nach-Skripte werden ausgeführt, nachdem das Vor-Skript erfolgreich war und die Snapshot-Erstellung initiiert wurde. Amazon Data Lifecycle Manager führt das Nach-Skript nur aus, wenn das Vor-Skript erfolgreich war. Wenn das Vor-Skript fehlschlägt, führt Amazon Data Lifecycle Manager das Nach-Skript nicht aus.
+ Snapshots werden bei der Erstellung mit den passenden Tags versehen.
+ CloudWatch Metriken und Ereignisse werden ausgegeben, wenn Skripts initiiert werden und wenn sie fehlschlagen oder erfolgreich sind.
# Andere Anwendungsfälle für Data Lifecycle Manager vor und nach Skripten
Neben der Verwendung von Vor- und Nach-Skripten zur Automatisierung anwendungskonsistenter Snapshots können Sie Vor- und Nach-Skripte zusammen oder einzeln verwenden, um andere Verwaltungsaufgaben vor oder nach der Snapshot-Erstellung zu automatisieren. Beispiel:
+ Verwenden Sie ein Vor-Skript, um Patches vor dem Erstellen von Snapshots anzuwenden. Dies ist hilfreich bei der Snapshot-Erstellung, nachdem Sie Ihre regulären wöchentlichen oder monatlichen Softwareupdates installiert haben.
**Anmerkung**
Wenn Sie nur ein Vor-Skript ausführen möchten, ist die Option **Standardmäßig absturzkonsistente Snapshots** standardmäßig aktiviert.
+ Verwenden eines Nach-Skripts zum Anwenden von Patches nach der Snapshot-Erstellung Dies ist bei der Snapshot-Erstellung hilfreich, bevor Sie Ihre regulären wöchentlichen oder monatlichen Softwareupdates installieren.
## Erste Schritte für andere Anwendungsfälle
In diesem Abschnitt werden die Schritte erläutert, die Sie ausführen müssen, wenn Sie and/or Pre-Post-Skripte für **andere Anwendungsfälle als anwendungskonsistente** Snapshots verwenden.
### Schritt 1: Vorbereiten der Ziel-Instances
**So bereiten Sie Ihre Ziel-Instances für Pre-Post-Skripte vor and/or**
1. Installieren Sie den SSM-Agent auf Ihren Ziel-Instances, falls noch nicht geschehen. Wenn der SSM-Agent bereits auf Ihren Ziel-Instances installiert ist, überspringen Sie diesen Schritt.
+ (Linux-Instances) [Manuelles Installieren des SSM-Agenten auf EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) für Linux
+ (Windows-Instanzen) [Arbeiten mit SSM Agent auf EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) für Windows Server
1. Stellen Sie sicher, dass der SSM-Agent ausgeführt wird. Weitere Informationen finden Sie unter [Prüfen des Status des SSM-Agents und Starten des Agenten](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Richten Sie Systems Manager für Amazon-EC2-Instances ein. Weitere Informationen finden Sie unter [Einrichtung von Systems Manager für Amazon-EC2-Instances](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) im *AWS Systems Manager -Benutzerhandbuch*.
### Schritt 2: Vorbereiten des SSM-Dokuments
Sie müssen ein SSM-Befehlsdokument erstellen, das die and/or Pre-Post-Skripts mit den Befehlen enthält, die Sie ausführen möchten.
Sie können mithilfe der unten stehenden leeren SSM-Dokumentvorlage ein SSM-Dokument erstellen und Ihre Vor- und Nach-Skriptbefehle in den entsprechenden Dokumentabschnitten hinzufügen.
**Beachten Sie Folgendes:**
Sie müssen sicherstellen, dass das SSM-Dokument die richtigen und erforderlichen Aktionen für Ihren Workload ausführt.
Das SSM-Dokument muss die erforderlichen Felder für `allowedValues` enthalten, einschließlich `pre-script`, `post-script` und `dry-run`. Amazon Data Lifecycle Manager führt Befehle auf Ihrer Instance basierend auf den Inhalten dieser Abschnitte aus. Wenn Ihr SSM-Dokument diese Abschnitte nicht enthält, behandelt Amazon Data Lifecycle Manager dies als fehlgeschlagene Ausführung.
```
###===============================================================================###
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
###===============================================================================###
schemaVersion: '2.2'
description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature
parameters:
executionId:
type: String
default: None
description: (Required) Specifies the unique identifier associated with a pre and/or post execution
allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$
command:
# Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution.
# 'dry-run' option is intended for validating the document execution without triggering any commands
# on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully
# trigger pre and post script actions.
type: String
default: 'dry-run'
description: (Required) Specifies whether pre-script and/or post-script should be executed.
allowedValues:
- pre-script
- post-script
- dry-run
mainSteps:
- action: aws:runShellScript
description: Run Database freeze/thaw commands
name: run_pre_post_scripts
precondition:
StringEquals:
- platformType
- Linux
inputs:
runCommand:
- |
#!/bin/bash
###===============================================================================###
### Error Codes
###===============================================================================###
# The following Error codes will inform Data Lifecycle Manager of the type of error
# and help guide handling of the error.
# The Error code will also be emitted via AWS Eventbridge events in the 'cause' field.
# 1 Pre-script failed during execution - 201
# 2 Post-script failed during execution - 202
# 3 Auto thaw occurred before post-script was initiated - 203
# 4 Pre-script initiated while post-script was expected - 204
# 5 Post-script initiated while pre-script was expected - 205
# 6 Application not ready for pre or post-script initiation - 206
###===============================================================================###
### Global variables
###===============================================================================###
START=$(date +%s)
# For testing this script locally, replace the below with OPERATION=$1.
OPERATION={{ command }}
# Add all pre-script actions to be performed within the function below
execute_pre_script() {
echo "INFO: Start execution of pre-script"
}
# Add all post-script actions to be performed within the function below
execute_post_script() {
echo "INFO: Start execution of post-script"
}
# Debug logging for parameters passed to the SSM document
echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}"
# Based on the command parameter value execute the function that supports
# pre-script/post-script operation
case ${OPERATION} in
pre-script)
execute_pre_script
;;
post-script)
execute_post_script
;;
dry-run)
echo "INFO: dry-run option invoked - taking no action"
;;
*)
echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run."
exit 1 # return failure
;;
esac
END=$(date +%s)
# Debug Log for profiling the script time
echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
```
### Schritt 3: Vorbereiten der IAM-Rolle für Amazon Data Lifecycle Manager
**Anmerkung**
Dieser Schritt ist erforderlich, wenn:
Sie erstellen oder aktualisieren eine pre/post skriptfähige Snapshot-Richtlinie, die eine benutzerdefinierte IAM-Rolle verwendet.
Sie verwenden die Befehlszeile, um eine pre/post skriptfähige Snapshot-Richtlinie zu erstellen oder zu aktualisieren, die den Standard verwendet.
Wenn Sie die Konsole verwenden, um eine pre/post skriptfähige Snapshot-Richtlinie zu erstellen oder zu aktualisieren, die die Standardrolle für die Verwaltung von Snapshots (**AWSDataLifecycleManagerDefaultRole**) verwendet, überspringen Sie diesen Schritt. In diesem Fall hängen wir die **AWSDataLifecycleManagerSSMFullZugriffsrichtlinie** automatisch an diese Rolle an.
Sie müssen sicherstellen, dass die für die Richtlinie verwendete IAM-Rolle Amazon Data Lifecycle Manager die Erlaubnis erteilt, die SSM-Aktionen auszuführen, die für die Ausführung von Vor- und Nach-Skripten auf Instances, auf die die Richtlinie abzielt, erforderlich sind.
Amazon Data Lifecycle Manager bietet eine verwaltete Richtlinie (**AWSDataLifecycleManagerSSMFullAccess**), die die erforderlichen Berechtigungen beinhaltet. Sie können diese Richtlinie an Ihre IAM-Rolle für die Verwaltung von Snapshots anhängen, um sicherzustellen, dass sie die entsprechenden Berechtigungen beinhaltet.
**Wichtig**
Die verwaltete AWSData LifecycleManager SSMFull Access-Richtlinie verwendet den `aws:ResourceTag` Bedingungsschlüssel, um den Zugriff auf bestimmte SSM-Dokumente einzuschränken, wenn Pre- und Post-Skripte verwendet werden. Damit Amazon Data Lifecycle Manager auf die SSM-Dokumente zugreifen kann, müssen Sie sicherstellen, dass Ihre SSM-Dokumente das Tag `DLMScriptsAccess:true` enthalten.
Alternativ können Sie manuell eine benutzerdefinierte Richtlinie erstellen oder die erforderlichen Berechtigungen direkt der von Ihnen verwendeten IAM-Rolle zuweisen. Sie können dieselben Berechtigungen verwenden, die in der verwalteten AWSData LifecycleManager SSMFull Access-Richtlinie definiert sind, der `aws:ResourceTag` Bedingungsschlüssel ist jedoch optional. Wenn Sie sich dafür entscheiden, diesen Bedingungsschlüssel nicht zu verwenden, müssen Sie Ihre SSM-Dokumente nicht mit `DLMScriptsAccess:true` markieren.
Verwenden Sie eine der folgenden Methoden, um die **AWSDataLifecycleManagerSSMFullAccess-Richtlinie** zu Ihrer IAM-Rolle hinzuzufügen.
------
#### [ Console ]
**So hängen Sie die verwaltete Richtlinie an Ihre benutzerdefinierte Rolle an**
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im Navigationspanel **Rollen** aus.
1. Suchen Sie nach Ihrer benutzerdefinierten Rolle zur Verwaltung von Snapshots und wählen Sie sie aus.
1. Wählen Sie auf der Registerkarte **Berechtigungen** **Berechtigungen hinzufügen** und dann **Richtlinien anfügen** aus.
1. Suchen Sie nach der verwalteten **AWSDataLifecycleManagerSSMFullAccess-Richtlinie**, wählen Sie sie aus und klicken Sie dann auf **Berechtigungen hinzufügen**.
------
#### [ AWS CLI ]
**So hängen Sie die verwaltete Richtlinie an Ihre benutzerdefinierte Rolle an**
Verwenden Sie den Befehl [ attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Geben Sie für `---role-name` den Namen Ihrer benutzerdefinierten Rolle an. Legen Sie für `--policy-arn` die Option `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess` fest.
```
$ aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
```
------
### Snapshot-Lebenszyklusrichtlinie erstellen
------
#### [ Console ]
**So erstellen Sie die Snapshot-Lebenszyklusrichtlinie**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Elastic Block Store** und **Lifecycle Manager** aus. Wählen Sie dann **Create lifecycle policy (Lebenszyklusrichtlinie erstellen)** aus.
1. Wählen Sie auf dem Bildschirm **Richtlinientyp auswählen** die Option **EBS-Snapshot-Richtlinie** und dann **Weiter** aus.
1. Gehen Sie im Abschnitt **Zielressourcen** wie folgt vor:
1. Wählen Sie für **Ziel-Ressourcentypen** die Option `Instance`.
1. Geben Sie für **Zielressourcen-Tags** die Ressourcen-Tags an, die die zu sichernden Instances identifizieren. Nur Ressourcen mit den angegebenen Tags werden gesichert.
1. Wählen Sie für die **IAM-Rolle** entweder **AWSDataLifecycleManagerDefaultRole**(die Standardrolle für die Verwaltung von Snapshots) oder eine benutzerdefinierte Rolle, die Sie für Vor- und Nachskripte erstellt und vorbereitet haben.
1. Konfigurieren Sie die Zeitpläne und zusätzlichen Optionen nach Bedarf. Wir empfehlen Ihnen, die Snapshot-Erstellung für Zeiträume einzuplanen, die Ihrem Workload entsprechen, z. B. während Wartungsfenstern.
1. Wählen Sie im Abschnitt **Vor- und Nach-Skripte** die Option **Vor- und Nach-Skripte aktivieren** und gehen Sie dann wie folgt vor:
1. Wählen Sie **Benutzerdefiniertes SSM-Dokument**.
1. Wählen Sie unter **Option automatisieren** die Option aus, die den auszuführenden Skripten entspricht.
1. Wählen Sie unter **SSM-Dokument** das SSM-Dokument aus, das Sie vorbereitet haben.
1. Konfigurieren Sie bei Bedarf die folgenden zusätzlichen Optionen:
+ **Timeout für das Skript** – Der Timeout-Zeitraum, nach dem Amazon Data Lifecycle Manager die versuchte Skriptausführung als fehlgeschlagen behandelt, wenn sie nicht abgeschlossen wurde. Wenn ein Skript nicht innerhalb des Timeout-Zeitraums abgeschlossen wird, schlägt der Versuch von Amazon Data Lifecycle Manager fehl. Der Timeout-Zeitraum gilt für die Vor- und Nach-Skripte einzeln. Der Minimal- und Standardwert für den Timeout beträgt 10 Sekunden. Die maximale Timeout-Zeit beträgt 120 Sekunden.
+ **Fehlgeschlagene Skripte erneut versuchen** – Wählen Sie diese Option, um Skripte zu wiederholen, die nicht innerhalb ihres Timeouts abgeschlossen werden. Wenn das Vor-Skript fehlschlägt, wiederholt Amazon Data Lifecycle Manager den gesamten Snapshot-Erstellungsprozess, einschließlich der Ausführung der Vor- und Nach-Skripte. Wenn das Nach-Skript fehlschlägt, wiederholt Amazon Data Lifecycle Manager nur das Nach-Skript. In diesem Fall ist das Vor-Skript abgeschlossen und der Snapshot wurde möglicherweise erstellt.
+ **Standardmäßig absturzkonsistente Snapshots** – Wählen Sie diese Option, um standardmäßig absturzkonsistente Snapshots zu verwenden, falls das Vor-Skript nicht ausgeführt werden kann. Dies ist das Standardverhalten bei der Snapshot-Erstellung für Amazon Data Lifecycle Manager, wenn Vor- und Nach-Skripte nicht aktiviert sind. Wenn Sie Wiederholungen aktiviert haben, verwendet Amazon Data Lifecycle Manager standardmäßig nur dann absturzkonsistente Snapshots, wenn alle Wiederholungsversuche ausgeschöpft sind. Wenn das Vor-Skript fehlschlägt und Sie nicht standardmäßig absturzkonsistente Snapshots verwenden, erstellt Amazon Data Lifecycle Manager während dieser geplanten Ausführung keine Snapshots für die Instance.
1. Wählen Sie **Standardrichtlinie erstellen**.
**Anmerkung**
Falls Sie den Fehler `Role with name AWSDataLifecycleManagerDefaultRole already exists` erhalten, finden Sie weitere Informationen unter [Probleme mit Amazon Data Lifecycle Manager beheben](dlm-troubleshooting.md).
------
#### [ AWS CLI ]
**So erstellen Sie die Snapshot-Lebenszyklusrichtlinie**
Verwenden Sie den [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)Befehl und fügen Sie die `Scripts` Parameter in ein. `CreateRule` Weitere Informationen finden Sie in der [https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html](https://docs.aws.amazon.com/dlm/latest/APIReference/API_Script.html).
```
$ aws dlm create-lifecycle-policy \
--description "policy_description" \
--state ENABLED \
--execution-role-arn iam_role_arn \
--policy-details file://policyDetails.json
```
Wenn `policyDetails.json` Folgendes umfasst.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "tag_key",
"Value": "tag_value"
}],
"Schedules": [{
"Name": "schedule_name",
"CreateRule": {
"CronExpression": "cron_for_creation_frequency",
"Scripts": [{
"Stages": ["PRE" | "POST" | "PRE","POST"],
"ExecutionHandlerService":"AWS_SYSTEMS_MANAGER",
"ExecutionHandler":"ssm_document_name|arn",
"ExecuteOperationOnScriptFailure":true|false,
"ExecutionTimeout":timeout_in_seconds (10-120),
"MaximumRetryCount":retries (0-3)
}]
},
"RetainRule": {
"Count": retention_count
}
}]
}
```
------
# So funktionieren Vor- und Nachskripte für Amazon Data Lifecycle Manager
Die folgende Abbildung zeigt den Prozessablauf für Vor- und Nach-Skripte bei der Verwendung benutzerdefinierter SSM-Dokumente. Dies gilt nicht für VSS-Backups.
![\[Prozessablauf für Vor- und Nach-Skripte für Amazon Data Lifecycle Manager\]](http://docs.aws.amazon.com/de_de/ebs/latest/userguide/images/dlm-scripts.png)
Zum geplanten Zeitpunkt der Snapshot-Erstellung finden die folgenden Aktionen und dienstübergreifenden Interaktionen statt.
1. Amazon Data Lifecycle Manager initiiert die Vor-Skript-Aktion durch Aufrufen des SSM-Dokuments und Übergeben des Parameters `pre-script`.
**Anmerkung**
Die Schritte 1 bis 3 finden nur statt, wenn Sie Vor-Skripte ausführen. Wenn Sie nur Nach-Skripte ausführen, werden die Schritte 1 bis 3 übersprungen.
1. Systems Manager sendet Vor-Skript-Befehle an den SSM-Agent, der auf den Ziel-Instances ausgeführt wird. Der SSM-Agent führt die Befehle auf der Instance aus und sendet Statusinformationen zurück an Systems Manager.
Wenn das SSM-Dokument beispielsweise verwendet wird, um anwendungskonsistente Snapshots zu erstellen, kann das Pre-Skript einfrieren und geleert werden, I/O um sicherzustellen, dass alle gepufferten Daten auf das Volume geschrieben werden, bevor der Snapshot erstellt wird.
1. Systems Manager sendet Statusaktualisierungen zu dem Vor-Skript-Befehl an Amazon Data Lifecycle Manager. Wenn das Vor-Skript fehlschlägt, führt Amazon Data Lifecycle Manager je nachdem, wie Sie die Optionen vor und nach dem Skript konfigurieren, eine der folgenden Aktionen aus:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/ebs/latest/userguide/script-flow.html)
1. Amazon Data Lifecycle Manager initiiert die Snapshot-Erstellung.
1. Amazon Data Lifecycle Manager initiiert die Nach-Skript-Aktion durch Aufrufen des SSM-Dokuments und Übergeben des Parameters `post-script`.
**Anmerkung**
Die Schritte 5 bis 7 finden nur statt, wenn Sie Vor-Skripte ausführen. Wenn Sie nur Nach-Skripte ausführen, werden die Schritte 1 bis 3 übersprungen.
1. Systems Manager sendet Nach-Skript-Befehle an den SSM-Agent, der auf den Ziel-Instances ausgeführt wird. Der SSM-Agent führt die Befehle auf der Instance aus und sendet Statusinformationen zurück an Systems Manager.
Wenn das SSM-Dokument beispielsweise anwendungskonsistente Snapshots ermöglicht, kann dieses Post-Skript auftauen, I/O um sicherzustellen, dass Ihre Datenbanken nach der Erstellung des Snapshots wieder normale I/O-Operationen aufnehmen.
1. Wenn Sie ein Nach-Skript ausführen und Systems Manager anzeigt, dass es erfolgreich abgeschlossen wurde, ist der Vorgang abgeschlossen.
Wenn das Nach-Skript fehlschlägt, führt Amazon Data Lifecycle Manager je nachdem, wie Sie die Optionen vor und nach dem Skript konfigurieren, eine der folgenden Aktionen aus:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/ebs/latest/userguide/script-flow.html)
Hinweis: Wenn das Nach-Skript fehlschlägt, wurde das Vor-Skript (falls aktiviert) erfolgreich abgeschlossen und die Snapshots wurden möglicherweise erstellt. Unter Umständen müssen Sie weitere Maßnahmen für die Instance ergreifen, um sicherzustellen, dass sie wie erwartet funktioniert. Zum Beispiel, wenn das Pre-Skript angehalten und geleert wurde. I/O, but the post script failed to thaw I/O, you might need to configure your database to auto-thaw I/O or you need to manually thaw I/O
1. Der Snapshot-Erstellungsprozess wird möglicherweise abgeschlossen, nachdem das Nach-Skript abgeschlossen ist. Wie viel Zeit das Abschließen des Snapshots in Anspruch nimmt, hängt von der Snapshot-Größe ab.
# Identifizieren Sie Snapshots, die mit Data Lifecycle Manager-Vor- und Nachskripten erstellt wurden
Amazon Data Lifecycle Manager weist Snapshots, die mit Vor- und Nach-Skripten erstellt wurden, automatisch die folgenden System-Tags zu.
+ Schlüssel: `aws:dlm:pre-script`; Wert: `SUCCESS`\$1`FAILED`
Der Tag-Wert von `SUCCESS` gibt an, dass das Vor-Skript erfolgreich ausgeführt wurde. Der Tag-Wert von `FAILED` gibt an, dass das Vor-Skript nicht erfolgreich ausgeführt wurde.
+ Schlüssel: `aws:dlm:post-script`; Wert: `SUCCESS`\$1`FAILED`
Der Tag-Wert von `SUCCESS` gibt an, dass das Nach-Skript erfolgreich ausgeführt wurde. Der Tag-Wert von `FAILED` gibt an, dass das Nach-Skript nicht erfolgreich ausgeführt wurde.
Bei benutzerdefinierten SSM-Dokumenten und SAP HANA-Sicherungen können Sie auf eine erfolgreiche anwendungskonsistente Snapshot-Erstellung schließen, wenn der Snapshot sowohl mit `aws:dlm:pre-script:SUCCESS` als auch `aws:dlm:post-script:SUCCESS` getaggt ist.
Darüber hinaus werden anwendungskonsistente Snapshots, die mit VSS-Backup erstellt wurden, automatisch mit folgenden Tags versehen:
+ Schlüssel: `AppConsistent tag`; Wert: `true`\$1`false`
Ein Tag-Wert von `true` gibt an, dass das VSS-Backup erfolgreich war und die Snapshots anwendungskonsistent sind. Ein Tag-Wert von `false` gibt an, dass das VSS-Backup nicht erfolgreich war und die Snapshots nicht anwendungskonsistent sind.
# Vor- und Nachskripte von Amazon Data Lifecycle Manager überwachen
**CloudWatch Amazon-Metriken**
Amazon Data Lifecycle Manager veröffentlicht die folgenden CloudWatch Metriken, wenn Vor- und Nachskripte fehlschlagen und erfolgreich sind und wenn VSS-Backups fehlschlagen und erfolgreich sind.
+ `PreScriptStarted`
+ `PreScriptCompleted`
+ `PreScriptFailed`
+ `PostScriptStarted`
+ `PostScriptCompleted`
+ `PostScriptFailed`
+ `VSSBackupStarted`
+ `VSSBackupCompleted`
+ `VSSBackupFailed`
Weitere Informationen finden Sie unter [Überwachen Sie die Data Lifecycle Manager-Richtlinien mit CloudWatch](monitor-dlm-cw-metrics.md).
**Amazon EventBridge**
Amazon Data Lifecycle Manager gibt das folgende EventBridge Amazon-Ereignis aus, wenn ein Pre- oder Post-Skript initiiert wird, erfolgreich ist oder fehlschlägt
+ `DLM Pre Post Script Notification`
Weitere Informationen finden Sie unter [Überwachen Sie die Data Lifecycle Manager-Richtlinien mit EventBridge](monitor-cloudwatch-events.md).