Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Création d'une politique personnalisée Amazon Data Lifecycle Manager pour les instantanés EBS
La procédure suivante montre comment utiliser Amazon Data Lifecycle Manager pour automatiser les cycles de vie des instantanés Amazon EBS.
**Topics**
+ [Pour créer une stratégie de cycle de vie d’instantané](#create-snap-policy)
+ [Considérations relatives aux stratégies de cycle de vie des instantanés](#snapshot-considerations)
+ [Ressources supplémentaires](#snapshot-additional-resources)
+ [Automatisez les instantanés cohérents avec les applications](automate-app-consistent-backups.md)
+ [Autres cas d’utilisation pour les pré-scripts et les post-scripts](script-other-use-cases.md)
+ [Fonctionnement des pré-scripts et des post-scripts](script-flow.md)
+ [Identifiez les instantanés créés à l'aide de scripts pré et post](dlm-script-tags.md)
+ [Surveillez les pré-scripts et les post-scripts](dlm-script-monitoring.md)
## Pour créer une stratégie de cycle de vie d’instantané
Suivez l’une des procédures suivantes pour créer une politique de cycle de vie des instantanés.
------
#### [ Console ]
**Pour créer une politique d’instantané**
1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Dans le panneau de navigation, sélectionnez **Elastic Block Store**, **Gestionnaire de cycle de vie**, puis **Créer une stratégie de cycle de vie d’instantané**.
1. Dans la page **Sélectionner un type de stratégie**, choisissez **Stratégie d’instantané EBS**, puis **Suivant**.
1. Dans la section **Ressources cibles**, effectuez les opérations suivantes :
1. Pour **Types de ressource cibles**, choisissez le type de ressource à sauvegarder. Sélectionnez `Volume` pour créer des instantanés de volumes individuels, ou `Instance` pour créer des instantanés multi-volume à partir des volumes d’une instance.
1. (*Outpostet clients de la zone locale uniquement*) Spécifiez l'emplacement des ressources cibles.
Pour **Emplacement de la ressource cible**, spécifiez l’emplacement des ressources cibles.
+ Pour cibler les ressources d'une région, sélectionnez **AWS Région**. Amazon Data Lifecycle Manager sauvegardera toutes les ressources du type spécifié qui ont des balises cibles correspondantes dans la région actuelle uniquement. Les instantanés sont créés dans la même région.
+ Pour cibler les ressources dans les zones locales, choisissez **AWS Local Zones**. Amazon Data Lifecycle Manager sauvegardera toutes les ressources du type spécifié qui ont des balises cibles correspondantes dans toutes les Zones Locales de la région actuelle uniquement. Les instantanés peuvent être créés dans la même zone locale que la ressource source ou dans sa région parent.
+ Pour cibler les ressources Outpost et, choisissez **AWS Outpost**. Amazon Data Lifecycle Manager sauvegardera toutes les ressources du type spécifié dont les balises cibles sont identiques sur l'ensemble Outposts de votre compte. Les instantanés peuvent être créés sur la même ressource Outpost que la ressource source ou dans sa région parente.
1. Pour **Etiquettes de ressources cibles**, choisissez les étiquettes de ressources qui identifient les volumes ou les instances à sauvegarder. Seules les ressources qui ont la clé de balise et les paires de valeurs spécifiées sont sauvegardées par la politique.
1. Pour **Description**, saisissez une brève description pour la stratégie.
1. Pour **Rôle IAM**, choisissez le rôle IAM autorisé à gérer des instantanés, ainsi qu’à décrire des volumes et des instances. Pour utiliser le rôle par défaut fourni par Amazon Data Lifecycle Manager, choisissez **Rôle par défaut**. Autrement, pour utiliser un rôle IAM personnalisé que vous avez créé précédemment, sélectionnez **Choisir un autre rôle**, puis sélectionnez le rôle à utiliser.
1. Pour **Etiquettes de stratégie**, ajoutez les étiquettes à appliquer à la stratégie de cycle de vie. Vous pouvez utiliser ces étiquettes pour identifier et catégoriser vos politiques.
1. Pour **Policy status** (Statut de la politique), choisissez **Enable** (Activer) pour lancer l’exécution de la politique à la prochaine heure planifiée, ou **Disable policy** (Désactiver la politique) pour empêcher l’exécution de la politique. Si vous n’activez pas la politique maintenant, elle ne commencera à créer des instantanés que quand vous l’aurez activée manuellement après sa création.
1. (*Politiques qui ciblent uniquement les instances*) Excluez les volumes des ensembles d’instantanés multi-volumes.
Par défaut, Amazon Data Lifecycle Manager créera des instantanés de tous les volumes attachés aux instances ciblées. Cependant, vous pouvez choisir de créer des instantanés d’un sous-ensemble des volumes attachés. Dans la section **Parameters** (Paramètres), procédez comme suit :
+ Si vous ne voulez pas créer d’instantanés des volumes racines attachés aux instances ciblées, sélectionnez **Exclude root volume** (Exclure le volume racine). Si vous sélectionnez cette option, seuls les volumes de données (non racine) attachés aux instances ciblées seront inclus dans les ensembles instantanés multi-volumes.
+ Si vous voulez créer des instantanés d’un sous-ensemble de volumes de données (non racine) attachés aux instances ciblées, sélectionnez **Exclude specific data volumes** (Exclure des volumes de données spécifiques), puis spécifiez les identifications à utiliser pour identifier les volumes de données qui ne doivent pas faire l’objet d’un instantané. Amazon Data Lifecycle Manager ne créera pas d’instantanés des volumes de données qui ont l’une des identifications spécifiées. Amazon Data Lifecycle Manager créera uniquement des instantanés des volumes de données qui n’ont aucune des identifications spécifiées.
1. Choisissez **Suivant**.
1. Dans l’écran **Configurer une planification**, configurez les planifications de stratégie. Une politique peut avoir jusqu’à 4 planifications. La planification 1 est obligatoire. Les planifications 2, 3 et 4 sont facultatives. Pour chaque planification de politique que vous ajoutez, procédez comme suit :
1. Dans la section **Détails de la planification**, procédez comme suit :
1. Pour **Nom de la planification**, spécifiez un nom descriptif pour la planification.
1. Pour **Fréquence** et les champs associés, configurez l’intervalle entre les exécutions de stratégie.
Vous pouvez configurer les exécutions de politique selon une planification quotidienne, hebdomadaire, mensuelle ou annuelle. Vous pouvez également sélectionner **Expression cron personnalisée** pour spécifier un intervalle allant jusqu’à un an. Pour plus d'informations, consultez les [sections Cron et rate dans](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html) le *guide de l' EventBridge utilisateur Amazon*.
**Note**
Si vous devez activer l’**archivage des instantanés** pour la planification, vous devez sélectionner la fréquence **mensuelle** ou **annuelle**, ou vous devez spécifier une expression cron avec une fréquence de création d’au moins 28 jours.
Si vous spécifiez une fréquence mensuelle qui crée des instantanés un jour spécifique d’une semaine spécifique (par exemple, le deuxième jeudi du mois), alors pour une planification basée sur le nombre, le nombre de rétention du niveau d’archivage doit être de 4 ou plus.
1. Pour **Démarrage à**, spécifiez l’heure de démarrage planifiée des exécutions de la stratégie. La première exécution de politique commence dans l’heure qui suit l’heure programmée. L’heure doit être au format UTC `hh:mm`.
1. Pour **Type de rétention**, spécifiez la stratégie de rétention des instantanés créés par la planification.
Vous pouvez retenir les instantanés en fonction de leur nombre total ou de leur âge.
+ Rétention basée sur le nombre
+ Lorsque l’archivage des instantanés est désactivé, la plage s’étend de `1` à `1000`. Lorsque le seuil de rétention est atteint, l’instantané le plus ancien est définitivement supprimé du niveau d’archivage.
+ Lorsque l’archivage des instantanés est activé, la plage s’étend de `0` (archiver immédiatement après la création) à `1000`. Une fois le seuil de rétention du niveau standard atteint, l’instantané est converti en instantané complet et est déplacé vers le niveau d’archivage.
+ Rétention basée sur l'âge
+ Lorsque l’archivage des instantanés est désactivé, la plage s’étend de `1` jour à `100` ans. Lorsque le seuil de rétention est atteint, l’instantané le plus ancien est définitivement supprimé du niveau d’archivage.
+ Lorsque l’archivage des instantanés est activé, la plage s’étend de `0` jour (archivage immédiat après la création) à `100` ans. Une fois le seuil de rétention du niveau standard atteint, l’instantané est converti en instantané complet et est déplacé vers le niveau d’archivage.
**Note**
Toutes les planifications doivent avoir le même type de rétention (basé sur l’âge ou sur le nombre). Vous pouvez spécifier le type de conservation pour la planification 1 uniquement. Les planifications 2, 3 et 4 héritent du type de conservation de la planification 1. Chaque planification peut avoir son propre nombre ou sa propre période de conservation.
Si vous activez la restauration rapide des instantanés, la copie inter-régions ou le partage d’instantanés, vous devez spécifier un nombre de rétention de `1` ou plus, ou une durée de conservation de `1` jour ou plus.
1. (*AWS Outposts et uniquement pour les clients de la zone locale*) Spécifiez la destination du cliché.
Pour **Destination des instantanés**, spécifiez la destination des instantanés créés par la politique.
+ Si la politique cible les ressources d'une région, les instantanés doivent être créés dans la même région. AWS La région est sélectionnée pour vous.
+ Si la politique cible les ressources d'une zone locale, vous pouvez créer des instantanés dans la même zone locale que la ressource source ou dans sa région parent.
+ Si la politique cible les ressources sur unOutpost, vous pouvez créer des instantanés sur la même ressource Outpost que la ressource source ou dans sa région parente.
1. Configurez le balisage pour les instantanés.
Dans la section **Etiquetage**, procédez comme suit :
1. Pour copier toutes les étiquettes définies par l’utilisateur à partir du volume source vers les instantanés créés par la planification, sélectionnez **Copier les étiquettes à partir de la source**.
1. Pour spécifier des étiquettes supplémentaires à attribuer aux instantanés créés par cette planification, choisissez **Ajouter des étiquettes**.
1. Configurez les scripts pré-scripts et les post-scripts pour des instantanés cohérents avec les applications.
Pour de plus amples informations, veuillez consulter [Automatisez les instantanés cohérents avec les applications avec Data Lifecycle Manager](automate-app-consistent-backups.md).
1. (*Politiques ciblant uniquement les volumes*) Configurez l’archivage des instantanés.
Dans la section **Archivage des instantanés**, procédez comme suit :
**Note**
Vous ne pouvez activer l’archivage des instantanés que pour une seule planification dans une politique.
1. Pour activer l’archivage des instantanés pour la planification, sélectionnez **Archive snapshots created by this schedule** (Instantanés d’archives créés selon cette planification).
**Note**
Vous pouvez activer l’archivage des instantanés uniquement si la fréquence de création des instantanés est mensuelle ou annuelle, ou si vous spécifiez une expression cron avec une fréquence de création d’au moins 28 jours.
1. Spécifiez la règle de rétention pour les instantanés dans le niveau d’archivage.
+ Pour les **planifications basées sur le nombre**, spécifiez le nombre d’instantanés à retenir dans le niveau d’archivage. Lorsque le seuil de rétention est atteint, l’instantané le plus ancien est définitivement supprimé du niveau d’archivage. Par exemple, si vous spécifiez le chiffre 3, la planification retiendra un maximum de 3 instantanés dans le niveau d’archivage. Lorsque le quatrième instantané est archivé, le plus ancien des trois instantanés existants dans le niveau d’archivage est supprimé.
+ Pour les **planifications basées sur l’âge**, spécifiez la période pour laquelle il convient de retenir les instantanés dans le niveau d’archivage. Lorsque le seuil de rétention est atteint, l’instantané le plus ancien est définitivement supprimé du niveau d’archivage. Par exemple, si vous spécifiez une période de 120 jours, la planification supprimera automatiquement les instantanés du niveau d’archivage lorsqu’ils atteignent cet âge.
**Important**
La période de rétention minimale pour les instantanés archivés est de 90 jours. Vous devez spécifier une règle de rétention qui retient l’instantané pendant au moins 90 jours.
1. Activez la restauration rapide des instantanés.
Pour activer la restauration rapide des instantanés créés par la planification, dans la section **Restauration d’instantané rapide**, sélectionnez **Activer la restauration d’instantané rapide**. Si vous activez la restauration d’instantané rapide, vous devez choisir les zones de disponibilité dans lesquelles le faire. Si la planification utilise une planification de rétention basée sur l’âge, vous devez spécifier la période pendant laquelle activer la restauration d’instantané rapide pour chaque instantané. Si la planification utilise une rétention basée sur le nombre, vous devez spécifier le nombre maximum d’instantanés à activer pour la restauration d’instantané rapide.
Si le calendrier crée des instantanés sur unOutpost, vous ne pouvez pas activer la restauration rapide des instantanés. La restauration rapide des instantanés n'est pas prise en charge avec les instantanés locaux stockés sur unOutpost.
**Note**
Vous êtes facturé pour chaque minute pendant laquelle la restauration d’instantané rapide est activée pour un instantané dans une zone de disponibilité particulière. Les frais sont calculés au prorata avec un minimum d’une heure.
1. Configurez la copie entre régions.
Pour copier les instantanés créés par le calendrier dans une Outpost ou plusieurs régions, dans la **section Copie entre régions, sélectionnez Activer la copie** **entre** régions.
Si le calendrier crée des instantanés dans une région, vous pouvez les copier dans un maximum de trois régions supplémentaires ou Outposts dans votre compte. Vous devez spécifier une règle de copie entre régions distincte pour chaque région de destination ouOutpost.
Pour chaque région ou régionOutpost, vous pouvez choisir différentes politiques de rétention et choisir de copier toutes les balises ou de ne pas les copier. Si l’instantané source est chiffré ou si le chiffrement par défaut est activé, les instantanés copiés sont chiffrés. Si l’instantané source n’est pas chiffré, vous pouvez activer le chiffrement. Si vous ne spécifiez pas de clé KMS, les instantanés sont chiffrés à l’aide de la clé KMS par défaut pour le chiffrement EBS dans chaque région de destination. Si vous spécifiez une clé KMS pour la Région de destination, le rôle IAM sélectionné doit avoir accès à la clé KMS.
**Note**
Vous devez vous assurer que vous ne dépassez pas le nombre de copies d’instantanés simultanées par région.
Si la politique crée des instantanés sur unOutpost, vous ne pouvez pas copier les instantanés dans une région ou dans une autre Outpost et les paramètres de copie entre régions ne sont pas disponibles.
1. Configurez le partage entre comptes.
Dans le **partage entre comptes**, configurez la politique pour partager automatiquement les instantanés créés par le planning avec d'autres AWS comptes. Procédez comme suit :
1. Pour activer le partage avec d'autres AWS comptes, sélectionnez **Activer le partage entre comptes**.
1. Pour ajouter les comptes avec lesquels partager les instantanés, choisissez **Ajouter un compte**, entrez l’ID de compte AWS de 12 chiffres, puis choisissez **Ajouter**.
1. Pour annuler automatiquement le partage d’instantanés partagés après une période spécifique, sélectionnez **Unshare automatically** (Annuler le partage automatiquement). Si vous choisissez d’annuler automatiquement le partage d’instantanés partagés, la période à l’issue de laquelle le partage est annulé ne peut pas être plus longue que la période pendant laquelle la politique retient ses instantanés. Par exemple, si la politique est configurée pour retenir les instantanés pendant 5 jours, vous pouvez configurer la politique de façon à ce qu’elle annule automatiquement le partage des instantanés partagés après jusqu’à 4 jours. Cela s’applique aux politiques avec des configurations de rétention d’instantanés basées sur l’âge et le nombre.
Si vous n’activez pas l’annulation automatique du partage, l’instantané est partagé jusqu’à sa suppression.
**Note**
Seuls les instantanés non chiffrés ou chiffrés à l’aide d’une clé gérée par le client peuvent être partagés. Vous ne pouvez pas partager d’instantanés chiffrés à l’aide de la clé KMS de chiffrement EBS par défaut. Si vous partagez des instantanés chiffrés, vous devez également partager la clé KMS utilisée pour chiffrer le volume source avec les comptes cibles. Pour plus d’informations, consultez [Autoriser des utilisateurs d’autres comptes à utiliser une clé KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) dans le *Guide du développeur AWS Key Management Service *.
1. Pour ajouter des planifications, choisissez l’option **Ajouter une planification** en haut de l’écran. Pour chaque planification supplémentaire, remplissez les champs comme décrit précédemment dans cette rubrique.
1. Après avoir ajouté les planifications requises, choisissez **Examiner une stratégie**.
1. Examinez le récapitulatif de la stratégie, puis choisissez **Créer une stratégie**.
**Note**
Si vous obtenez l’erreur `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consultez [Résoudre les problèmes liés à Amazon Data Lifecycle Manager](dlm-troubleshooting.md) pour plus d’informations.
------
#### [ Command line ]
Utilisez la [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)commande pour créer une politique de cycle de vie des instantanés. Pour `PolicyType`, spécifiez `EBS_SNAPSHOT_MANAGEMENT`.
**Note**
Pour simplifier la syntaxe, les exemples suivants utilisent un fichier JSON, `policyDetails.json`, qui comportent les détails de la stratégie.
**Exemple 1 — Politique de cycle de vie des instantanés avec deux planifications**
Cet exemple montre comment créer une stratégie de cycle de vie des instantanés qui crée des instantanés de tous les volumes dont la clé de balise `costcenter` comporte une valeur de `115`. La politique comprend deux planifications. La première planification crée un instantané tous les jours à 3h00 UTC. La deuxième planification crée un instantané hebdomadaire tous les vendredis à 17h00 UTC.
```
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
```
Voici un exemple du fichier `policyDetails.json`.
```
{
"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
}
]}
```
Si la demande aboutit, la commande renvoie l’ID de la politique nouvellement créée. Voici un exemple de sortie.
```
{
"PolicyId": "policy-0123456789abcdef0"
}
```
**Exemple 2 : politique de cycle de vie des instantanés qui cible les instances et crée des instantanés d’un sous-ensemble de volumes de données (non racine)**
Cet exemple crée une politique de cycle de vie des instantanés qui crée des ensembles d’instantanés multi-volumes à partir d’instances ayant l’identification `code=production`. La politique ne comprend qu’une seule planification. La planification ne crée pas d’instantanés des volumes de données ayant l’identification `code=temp`.
```
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
```
Voici un exemple du fichier `policyDetails.json`.
```
{
"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
}
]}
```
Si la demande aboutit, la commande renvoie l’ID de la politique nouvellement créée. Voici un exemple de sortie.
```
{
"PolicyId": "policy-0123456789abcdef0"
}
```
**Exemple 3 : Politique de cycle de vie des instantanés qui automatise les instantanés locaux des ressources Outpost**
Cet exemple crée une politique de cycle de vie des instantanés qui crée des instantanés des volumes balisés `team=dev` dans l'ensemble de votre Outposts entreprise. La politique crée les instantanés sur les mêmes volumes Outposts que les volumes source. La stratégie crée des instantanés toutes les `12` heures à partir de `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
```
Voici un exemple du fichier `policyDetails.json`.
```
{
"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
}
]}
```
**Exemple 4 : politique de cycle de vie des instantanés qui crée des instantanés dans une région et les copie dans un Outpost**
L’exemple de stratégie suivant crée des instantanés de volumes balisés avec `team=dev`. Les instantanés sont créés dans la même Région que le volume source. Les instantanés sont créés toutes les `12` heures à partir de `00:00` UTC et conservent un maximum d’`1` instantané. La politique copie également les instantanés vers Outpost`arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0`, chiffre les instantanés copiés à l'aide de la clé KMS de chiffrement par défaut et conserve les copies pendant un mois. `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
```
Voici un exemple du fichier `policyDetails.json`.
```
{
"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"
}
}]
}
]}
```
**Exemple 5 – Politique de cycle de vie des instantanés avec une planification basée sur l’archivage et sur l’âge**
Cet exemple montre comment créer une politique de cycle de vie des instantanés ciblant les volumes balisés avec `Name=Prod`. La politique comporte une planification basée sur l’âge qui crée des instantanés le premier jour de chaque mois à 9 h. La planification retient chaque instantané du niveau standard pendant un jour, après quoi elle les déplace vers le niveau d’archivage. Les instantanés sont stockés dans le niveau d’archivage pendant 90 jours avant d’être supprimés.
```
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
```
Voici un exemple du fichier `policyDetails.json`.
```
{
"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"
}
]
}
```
**Exemple 6 – Politique de cycle de vie des instantanés avec une planification basée sur l’archivage et sur le nombre**
Cet exemple montre comment créer une politique de cycle de vie des instantanés ciblant les volumes balisés avec `Purpose=Test`. La politique comporte une planification basée sur le nombre qui crée des instantanés le premier jour de chaque mois à 9 h. La planification archive les instantanés immédiatement après leur création et retient un maximum de trois instantanés dans le niveau d’archivage.
```
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
```
Voici un exemple du fichier `policyDetails.json`.
```
{
"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"
}
]
}
```
------
## Considérations relatives aux stratégies de cycle de vie des instantanés
Les **considérations générales** suivantes s’appliquent aux politiques de cycle de vie des instantanés :
+ Les politiques de cycle de vie des instantanés ciblent uniquement les instances ou les volumes qui se trouvent dans la même région que la politique.
+ La première opération de création d’instantané démarre dans l’heure suivant l’heure de début spécifiée. Les opérations suivantes de création d’instantanés démarrent dans l’heure suivant leur heure planifiée.
+ Vous pouvez créer plusieurs stratégies pour sauvegarder un volume ou une instance . Par exemple, si un volume EBS comporte deux identifications, l’identification *A* étant la cible de la politique *A* qui permet de créer un instantané toutes les 12 heures et l’identification *B* étant la cible de la politique *B* qui permet de créer un instantané toutes les 24 heures, Amazon Data Lifecycle Manager crée des instantanés en fonction des planifications des deux politiques. Vous pouvez également obtenir le même résultat en créant une seule politique comportant plusieurs planifications. Par exemple, vous pouvez créer une politique unique qui cible uniquement la balise *A* et spécifier deux planifications : l’une pour toutes les 12 heures et l’autre pour toutes les 24 heures.
+ Les balises de ressource cible sont sensibles à la casse.
+ Si vous supprimez les balises cibles d’une ressource ciblée par une politique, Amazon Data Lifecycle Manager ne gère plus les instantanés existants dans le niveau standard et le niveau d’archivage. Vous devez les supprimer manuellement s’ils ne sont plus nécessaires.
+ Si vous créez une politique qui cible des instances et que de nouveaux volumes sont attachés à l’instance après la création de la politique, les volumes nouvellement ajoutés sont inclus dans la sauvegarde lors de la prochaine exécution de la politique. Tous les volumes attachés à l’instance au moment de l’exécution de la politique sont inclus.
+ Si une politique avec une planification personnalisée basée sur les crons est configurée pour créer un seul instantané, la politique ne supprime pas automatiquement cet instantané lorsque le seuil de rétention est atteint. Vous devez supprimer manuellement l’instantané s’il n’est plus nécessaire.
+ Si vous créez une politique basée sur l’âge dans laquelle la période de conservation est plus courte que la fréquence de création, Amazon Data Lifecycle Manager conservera toujours le dernier instantané jusqu’à la création du suivant. Par exemple, si une politique basée sur l'âge crée un instantané par mois avec une période de conservation de sept jours, Amazon Data Lifecycle Manager conservera chaque pendant un mois, même si la période de conservation est de sept jours.
Les considérations suivantes s’appliquent à l’**[archivage des instantanés](snapshot-archive.md)** :
+ Vous pouvez activer l’archivage des instantanés uniquement pour les politiques d’instantanés qui ciblent les volumes
+ Vous ne pouvez spécifier une règle d’archivage que pour une seule planification par politique.
+ Si vous utilisez la console, vous pouvez activer l’archivage des instantanés uniquement si la planification possède une fréquence de création mensuelle ou annuelle, ou si elle possède une expression cron avec une fréquence de création d’au moins 28 jours.
Si vous utilisez l' AWS API ou le AWS CLI AWS SDK, vous ne pouvez activer l'archivage des instantanés que si le planning comporte une expression cron avec une fréquence de création d'au moins 28 jours.
+ La période de rétention minimale dans le niveau d’archivage est de 90 jours.
+ Lorsqu’un instantané est archivé, il est converti en instantané complet lorsqu’il est déplacé vers le niveau d’archivage. Cela peut entraîner des coûts de stockage d’instantanés plus élevés. Pour de plus amples informations, veuillez consulter [Tarification et facturation pour l'archivage des instantanés Amazon EBS](snapshot-archive-pricing.md).
+ La restauration rapide d’instantané et le partage d’instantanés sont désactivés pour les instantanés lorsqu’ils sont archivés.
+ Si, dans le cas d’une année bissextile, votre règle de rétention résulte en une période de rétention d’archivage inférieure à 90 jours, Amazon Data Lifecycle Manager garantit la rétention des instantanés pendant la période minimale de 90 jours.
+ Si vous archivez manuellement un instantané créé par Amazon Data Lifecycle Manager et que l’instantané est toujours archivé lorsque le seuil de rétention de la planification est atteint, Amazon Data Lifecycle Manager ne gère plus cet instantané. Toutefois, si vous restaurez l’instantané au niveau standard avant que le seuil de rétention de la planification ne soit atteint, la planification continuera à gérer l’instantané conformément aux règles de rétention.
+ Si vous restaurez de façon permanente ou temporaire un instantané archivé par Amazon Data Lifecycle Manager et que l’instantané se trouve toujours dans le niveau standard lorsque le seuil de rétention de la planification est atteint, Amazon Data Lifecycle Manager ne gère plus l’instantané. Toutefois, si vous réarchivez l’instantané avant que le seuil de rétention de la planification soit atteint, la planification supprime l’instantané lorsque le seuil de rétention est atteint.
+ Les instantanés archivés par Amazon Data Lifecycle Manager sont comptabilisés dans vos quotas `Archived snapshots per volume` et `In-progress snapshot archives per account`.
+ Si une planification ne parvient pas à archiver un instantané après de nouvelles tentatives pendant 24 heures, l’instantané reste au niveau standard et sa suppression est planifiée en fonction de l’heure à laquelle il aurait été supprimé du niveau d’archivage. Par exemple, si la planification archive les instantanés pendant 120 jours, ceux-ci restent au niveau standard pendant 120 jours après l’échec de l’archivage avant d’être supprimés définitivement. Pour les planifications basées sur le nombre, l’instantané n’est pas comptabilisé dans le nombre de rétention de la planification.
+ Les instantanés doivent être archivés dans la région dans laquelle ils ont été créés. Si vous avez activé la copie inter-régions et l’archivage des instantanés, Amazon Data Lifecycle Manager n’archive pas la copie d’instantané.
+ Les instantanés archivés par Amazon Data Lifecycle Manager sont balisés avec la balise système `aws:dlm:archived=true`. De plus, les instantanés créés par une planification basée sur l’archivage et sur l’âge sont balisés avec la balise système `aws:dlm:expirationTime`, qui indique la date et l’heure auxquelles l’archivage de l’instantané est prévu.
Les considérations suivantes s’appliquent à **l’exclusion des volumes racine et des volumes de données (non racine)** :
+ Si vous choisissez d'exclure les volumes de démarrage et que vous spécifiez des balises qui excluent par conséquent tous les volumes de données supplémentaires attachés à une instance, Amazon Data Lifecycle Manager ne créera aucun instantané pour l'instance concernée et émettra une `SnapshotsCreateFailed` CloudWatch métrique. Pour de plus amples informations, veuillez consulter [Surveillez les politiques à l'aide CloudWatch](monitor-dlm-cw-metrics.md).
Les considérations suivantes s’appliquent à la **suppression de volumes ou à la résiliation d’instances ciblées par les politiques de cycle de vie des instantanés** :
+ Si vous supprimez un volume ou résiliez une instance ciblée par une politique avec une planification de rétention basée sur le nombre, Amazon Data Lifecycle Manager ne gère plus les instantanés dans le niveau standard et le niveau d’archivage créés à partir du volume supprimé ou de l’instance résiliée. Vous devez supprimer ces instantanés précédents manuellement lorsqu’ils ne sont plus nécessaires.
+ Si vous supprimez un volume ou résiliez une instance ciblée par une politique avec une planification de rétention basée sur l’âge, la politique continue de supprimer les instantanés du niveau standard et du niveau d’archivage créés à partir du volume supprimé ou de l’instance résiliée selon la planification définie, jusqu’au dernier instantané, mais sans l’inclure. Vous devez supprimer manuellement le dernier instantané s’il n’est plus nécessaire.
Les considérations suivantes s’appliquent aux politiques de cycle de vie des instantanés et ** [à la restauration d’instantané rapide](ebs-fast-snapshot-restore.md)** :
+ Amazon Data Lifecycle Manager peut activer la restauration rapide des instantanés uniquement pour les instantanés d’une taille inférieure ou égale à 16 Tio. Pour de plus amples informations, veuillez consulter [Restauration d’instantané rapide Amazon EBS](ebs-fast-snapshot-restore.md).
+ Un instantané qui est activé pour la restauration d’instantané rapide reste activé, même si vous supprimez ou désactivez la politique, si vous désactivez la restauration d’instantané rapide pour la politique ou si vous désactivez la restauration d’instantané rapide pour la zone de disponibilité. Vous devez désactiver manuellement la restauration d’instantané rapide pour ces instantanés.
+ Si vous activez la restauration d’instantané rapide pour une politique et que vous dépassez le nombre maximum d’instantanés pouvant être activés pour la restauration d’instantané rapide, Amazon Data Lifecycle Manager crée des instantanés comme prévu, mais ne les active pas pour la restauration d’instantané rapide. Une fois qu’un instantané activé pour la restauration d’instantané rapide est supprimé, l’instantané suivant créé par Amazon Data Lifecycle Manager est activé pour la restauration rapide d’instantané.
+ Lorsque la restauration d’instantané rapide pour un instantané, l’optimisation de ce dernier dure 60 minutes par Tio. Nous vous recommandons de configurer vos planifications de stratégie qui assurent l’optimisation complète de chaque instantané avant que Amazon Data Lifecycle Manager ne crée l’instantané suivant.
+ Si vous activez la restauration rapide des instantanés pour une stratégie ciblant les instances, Amazon Data Lifecycle Manager permet une restauration rapide des instantanés pour chaque instantané du cliché multivolume défini individuellement. Si Amazon Data Lifecycle Manager ne parvient pas à activer la restauration rapide des instantanés pour l’un des instantanés du jeu d’instantanés multi-volumes, il tentera toujours d’activer la restauration rapide des instantanés pour les instantanés restants du jeu de d’instantanés.
+ Vous êtes facturé pour chaque minute pendant laquelle la restauration d’instantané rapide est activée pour un instantané dans une zone de disponibilité particulière. Les frais sont calculés au prorata avec un minimum d’une heure. Pour plus d’informations, consultez [Tarification et facturation](ebs-fast-snapshot-restore.md#fsr-pricing).
**Note**
Selon la configuration de vos politiques de cycle de vie, plusieurs instantanés peuvent être activés pour une restauration rapide dans de multiples zones de disponibilité en simultanée.
Les considérations suivantes s’appliquent aux politiques de cycle de vie des instantanés et aux ** [volumes compatibles ](ebs-volumes-multi.md)Multi-Attach** :
+ Lors de la création d’une politique de cycle de vie qui cible des instances qui ont les mêmes volumes activés par multi-Attach, Amazon Data Lifecycle Manager lance un instantané du volume pour chaque instance attachée. Utilisez la balise *timestamp* pour identifier l’ensemble d’instantanés temporels créés à partir des instances attachées.
Les considérations suivantes s’appliquent au **partage des instantanés entre comptes **:
+ Seuls les instantanés non chiffrés ou chiffrés à l’aide d’une clé gérée par le client peuvent être partagés.
+ Vous ne pouvez pas partager d’instantanés chiffrés à l’aide de la clé KMS de chiffrement EBS par défaut.
+ Si vous partagez des instantanés chiffrés, vous devez également partager la clé KMS utilisée pour chiffrer le volume source avec les comptes cibles. Pour plus d’informations, consultez [Autoriser des utilisateurs d’autres comptes à utiliser une clé KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) dans le *Guide du développeur AWS Key Management Service *.
Les considérations suivantes s’appliquent aux politiques des instantanés et à ** [l’archivage des instantanés](snapshot-archive.md)** :
+ Si vous archivez manuellement un instantané créé par une politique et que cet instantané se trouve dans le niveau d’archivage lorsque le seuil de rétention de la politique est atteint, Amazon Data Lifecycle Manager ne supprime pas l’instantané. Amazon Data Lifecycle Manager ne gère pas les instantanés lorsqu’ils sont stockés dans le niveau d’archivage. Si vous n'avez plus besoin des instantanés qui sont stockés dans le niveau d'archivage, vous devez les supprimer manuellement.
Les considérations suivantes s'appliquent aux politiques relatives aux instantanés et à la [corbeille](recycle-bin.md) :
+ Si Amazon Data Lifecycle Manager supprime un instantané et l’envoie à la corbeille lorsque le seuil de rétention de la politique est atteint, et que vous restaurez manuellement l’instantané à partir de la corbeille, vous devez supprimer manuellement cet instantané s’il n’est plus nécessaire. Amazon Data Lifecycle Manager ne gérera plus l’instantané.
+ Si vous supprimez manuellement un instantané créé par une politique et que cet instantané se trouve dans la corbeille lorsque le seuil de rétention de la politique est atteint, Amazon Data Lifecycle Manager ne supprime pas l’instantané. Amazon Data Lifecycle Manager ne gère pas les instantanés lorsqu’ils sont stockés dans la corbeille.
Si l’instantané est restauré à partir de la corbeille avant que le seuil de rétention de la politique soit atteint, Amazon Data Lifecycle Manager supprime l’instantané lorsque le seuil de rétention de la politique est atteint.
Si l’instantané est restauré à partir de la corbeille après que le seuil de rétention de la politique soit atteint, Amazon Data Lifecycle Manager ne supprime plus l’instantané. Vous devez supprimer manuellement l’instantané s’il n’est plus nécessaire.
Les considérations suivantes s’appliquent aux politiques de cycle de vie des instantanés qui sont dans l’état d’**erreur** :
+ Pour les politiques avec des planifications de rétention basées sur l’âge, les instantanés qui sont configurés pour expirer alors que la politique est dans l’état `error` sont conservés indéfiniment. Vous devez supprimer les instantanés manuellement. Lorsque vous réactivez la politique, Amazon Data Lifecycle Manager reprend la suppression des instantanés à mesure que leurs périodes de rétention expirent.
+ Pour les politiques avec des planifications de rétention basée sur le nombre, la politique arrête de créer et de supprimer des instantanés pendant qu’elle est dans l’état `error`. Lorsque vous réactivez la politique, Amazon Data Lifecycle Manager reprend la création d’instantanés, ainsi que la suppression d’instantanés lorsque le seuil de rétention est atteint.
Les considérations suivantes s’appliquent aux politiques d’instantanés et au **[verrouillage d’instantanés](ebs-snapshot-lock.md)** :
+ Si vous verrouillez manuellement un instantané créé par Amazon Data Lifecycle Manager et que l’instantané est toujours verrouillé lorsque son seuil de conservation est atteint, Amazon Data Lifecycle Manager ne gère plus cet instantané. Vous devez supprimer manuellement l’instantané s’il n’est plus nécessaire.
+ Si vous verrouillez manuellement un instantané qui a été créé par Amazon Data Lifecycle Manager avec la restauration rapide activée et que l’instantané est toujours verrouillé lorsque son seuil de conservation est atteint, Amazon Data Lifecycle Manager ne désactive pas la restauration rapide de l’instantané et ne supprime pas l’instantané. Vous devez désactiver la restauration d’instantané rapide et supprimer manuellement l’instantané s’il n’est plus nécessaire.
+ Si vous inscrivez manuellement un instantané qui a été créé par Amazon Data Lifecycle Manager avec une AMI puis que vous verrouillez cet instantané, et que l’instantané est toujours verrouillé et associé à l’AMI lorsque son seuil de conservation est atteint, Amazon Data Lifecycle Manager continue de tenter de supprimer l’instantané. Lorsque l’inscription de l’AMI est annulée et que l’instantané est déverrouillé, Amazon Data Lifecycle Manager supprime automatiquement l’instantané.
## Ressources supplémentaires
Pour plus d'informations, consultez le blog [Automating Amazon EBS snapshot and AMI management using Amazon Data Lifecycle Manager AWS storage](https://aws.amazon.com/blogs/storage/automating-amazon-ebs-snapshot-and-ami-management-using-amazon-dlm/).
# Automatisez les instantanés cohérents avec les applications avec Data Lifecycle Manager
Vous pouvez automatiser les instantanés cohérents par rapport à l’application avec Amazon Data Lifecycle Manager en activant les pré-scripts et les post-scripts dans vos politiques de cycle de vie des instantanés qui ciblent les instances.
Amazon Data Lifecycle Manager s'intègre à AWS Systems Manager (Systems Manager) pour prendre en charge des instantanés cohérents avec les applications. Amazon Data Lifecycle Manager utilise les documents de commande Systems Manager (SSM) qui incluent des pré-scripts et des post-scripts pour automatiser les actions nécessaires pour créer des instantanés cohérents par rapport à l’application. Avant qu'Amazon Data Lifecycle Manager ne lance la création d'un instantané, il exécute les commandes du pré-script pour les bloquer et les viderI/O. After Amazon Data Lifecycle Manager initiates snapshot creation, it runs the commands in the post script to thaw I/O.
Avec Amazon Data Lifecycle Manager, vous pouvez automatiser les instantanés cohérents par rapport à l’application pour les applications suivantes :
+ applications Windows avec Volume Shadow Copy Service (VSS) ;
+ SAP HANA à l'aide d'un AWS document SSDM géré. pour plus d’informations, consultez [Amazon EBS snapshots for SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/ebs-sap-hana.html).
+ Bases de données autogérées, telles que MySQL, PostgreSQL InterSystems ou IRIS, à l'aide de modèles de documents SSM
**Topics**
+ [Exigences relatives à l’utilisation des pré-scripts et post-scripts](#app-consistent-prereqs)
+ [Démarrage avec les instantanés cohérents par rapport à l’application](#app-consistent-get-started)
+ [Considérations relatives aux sauvegardes VSS avec Amazon Data Lifecycle Manager](#app-consistent-vss)
+ [Responsabilité partagée pour les instantanés cohérents par rapport à l’application](#shared-responsibility)
## Exigences relatives à l’utilisation des pré-scripts et post-scripts
Le tableau suivant décrit les exigences relatives à l’utilisation des pré-scripts et des post-scripts avec Amazon Data Lifecycle Manager.
| | Instantanés cohérents par rapport à l’application | |
| --- |--- |--- |
| Exigence | Sauvegarde VSS | Document SSM personnalisé | Autres cas d’utilisation |
| --- |--- |--- |--- |
| Agent SSM installé et exécuté sur les instances cibles | ✓ | ✓ | ✓ |
| Les exigences du système VSS sont satisfaites sur les instances cibles | ✓ | | |
| Profil d'instance compatible VSS associé aux instances cibles | ✓ | | |
| Composants VSS installés sur les instances cibles | ✓ | | |
| Préparer un document SSM avec des commandes de script pré et post | | ✓ | ✓ |
| Préparer le rôle IAM d'Amazon Data Lifecycle Manager, exécuter des scripts avant et après | ✓ | ✓ | ✓ |
| Créez une politique de capture instantanée qui cible les instances et qui est configurée pour les pré-scripts et les post-scripts | ✓ | ✓ | ✓ |
## Démarrage avec les instantanés cohérents par rapport à l’application
Cette section explique les étapes à suivre pour automatiser les instantanés cohérents par rapport à l’application à l’aide d’Amazon Data Lifecycle Manager.
### Étape 1 : Préparer les instances cibles
Vous devez préparer les instances ciblées pour les instantanés cohérents par rapport à l’application à l’aide d’Amazon Data Lifecycle Manager. Effectuez l’une des actions suivantes en fonction de votre cas d’utilisation.
------
#### [ Prepare for VSS Backups ]
**Pour préparer vos instances cibles pour les sauvegardes VSS**
1. Installez l’agent SSM sur vos instances cibles, s’il n’est pas déjà installé. Si l’agent SSM est déjà installé sur vos instances cibles, ignorez cette étape.
Pour plus d'informations, consultez la section [Utilisation de l'agent SSM sur les instances EC2 pour Windows Server](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html).
1. Assurez-vous que l’agent SSM est en cours d’exécution. Pour plus d’informations, consultez [Vérification du statut de l’SSM Agent et démarrage de l’agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Configurez Systems Manager pour des instances Amazon EC2. Pour plus d’informations, consultez [Configuration de Systems Manager pour des instances Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) dans le *Guide de l’utilisateur AWS Systems Manager *.
1. [ Assurez-vous que la configuration système requise pour les sauvegardes VSS est respectée](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-prereqs.html).
1. [ Attachez un profil d’instance compatible avec VSS aux instances cibles](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vss-iam-reqs.html).
1. [ Installez les composants VSS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-getting-started.html).
------
#### [ Prepare for SAP HANA backups ]
**Pour préparer vos instances cibles pour les sauvegardes SAP HANA**
1. Préparez l’environnement SAP HANA sur vos instances cibles.
1. Configurez votre instance avec SAP HANA. Si vous ne possédez pas encore d’environnement SAP HANA, vous pouvez consulter la rubrique [SAP HANA Environment Setup on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/std-sap-hana-environment-setup.html).
1. Connectez-vous à SystemDB en tant qu’utilisateur administrateur approprié.
1. Créez un utilisateur de sauvegarde de base de données à utiliser avec Amazon Data Lifecycle Manager.
```
CREATE USER username PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
```
Par exemple, la commande suivante crée un utilisateur nommé `dlm_user` avec le mot de passe `password`.
```
CREATE USER dlm_user PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
```
1. Attribuez le rôle `BACKUP OPERATOR` à l’utilisateur de sauvegarde de base de données que vous avez créé à l’étape précédente.
```
GRANT BACKUP OPERATOR TO username
```
Par exemple, la commande suivante attribue le rôle à un utilisateur nommé `dlm_user`.
```
GRANT BACKUP OPERATOR TO dlm_user
```
1. Connectez-vous au système d’exploitation en tant qu’administrateur, par exemple `sidadm`.
1. Créez une entrée `hdbuserstore` pour stocker les informations de connexion afin que le document SSM SAP HANA puisse se connecter à SAP HANA sans que les utilisateurs aient à saisir ces informations.
```
hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:3hana_instance_number13 username password
```
Par exemple :
```
hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:30013 dlm_user password
```
1. Testez la connexion.
```
hdbsql -U DLM_HANADB_SNAPSHOT_USER "select * from dummy"
```
1. Installez l’agent SSM sur vos instances cibles, s’il n’est pas déjà installé. Si l’agent SSM est déjà installé sur vos instances cibles, ignorez cette étape.
Pour plus d'informations, voir [Installation manuelle de l'agent SSM sur les instances EC2 pour Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html).
1. Assurez-vous que l’agent SSM est en cours d’exécution. Pour plus d’informations, consultez [Vérification du statut de l’SSM Agent et démarrage de l’agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Configurez Systems Manager pour des instances Amazon EC2. Pour plus d’informations, consultez [Configuration de Systems Manager pour des instances Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) dans le *Guide de l’utilisateur AWS Systems Manager *.
------
#### [ Prepare for custom SSM documents ]
**Pour préparer les documents SSM personnalisés de vos instances cibles**
1. Installez l’agent SSM sur vos instances cibles, s’il n’est pas déjà installé. Si l’agent SSM est déjà installé sur vos instances cibles, ignorez cette étape.
+ (Instances Linux) [Installation manuelle de l'agent SSM sur les instances EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) pour Linux
+ (instances Windows) [Utilisation de l'agent SSM sur les instances EC2 pour](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) Windows Server
1. Assurez-vous que l’agent SSM est en cours d’exécution. Pour plus d’informations, consultez [Vérification du statut de l’SSM Agent et démarrage de l’agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Configurez Systems Manager pour des instances Amazon EC2. Pour plus d’informations, consultez [Configuration de Systems Manager pour des instances Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) dans le *Guide de l’utilisateur AWS Systems Manager *.
------
### Étape 2 : Préparer le document SSM
**Note**
Cette étape est requise uniquement pour les documents SSM personnalisés. Elle n’est pas nécessaire pour les sauvegardes VSS ou SAP HANA. Pour les sauvegardes VSS et SAP HANA, Amazon Data Lifecycle Manager utilise le document AWS SSM géré.
Si vous automatisez des instantanés cohérents avec les applications pour une base de données autogérée, telle que MySQL, PostgreSQL ou InterSystems IRIS, vous devez créer un document de commande SSM qui inclut un pré-script à figer et à vider I/O avant le lancement de la création de snapshots, et un post-script à décongeler après le lancement de la création de snapshots. I/O
Si votre base de données MySQL, PostgreSQL InterSystems ou IRIS utilise des configurations standard, vous pouvez créer un document de commande SSM à l'aide de l'exemple de contenu du document SSM ci-dessous. Si votre base de données MySQL, PostgreSQL InterSystems ou IRIS utilise une configuration non standard, vous pouvez utiliser l'exemple de contenu ci-dessous comme point de départ pour votre document de commande SSM, puis le personnaliser en fonction de vos besoins. Si vous souhaitez créer un nouveau document SSM à partir de zéro, vous pouvez également utiliser le modèle de document SSM vide ci-dessous et ajouter vos commandes pré et post dans les sections de document appropriées.
**Notez ce qui suit :**
Il est de votre responsabilité de vous assurer que le document SSM exécute les actions correctes et requises pour la configuration de votre base de données.
La cohérence des instantanés par rapport à l’application est garantie uniquement si les pré-scripts et les post-scripts de votre document SSM parviennent à geler, à vider et à dégeler les E/S.
Le document SSM doit inclure les champs obligatoires pour `allowedValues`, notamment `pre-script`, `post-script` et `dry-run`. Amazon Data Lifecycle Manager exécutera des commandes sur votre instance en fonction du contenu de ces sections. Si votre document SSM ne contient pas ces sections, Amazon Data Lifecycle Manager le considérera comme un échec d’exécution.
------
#### [ 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
```
Pour plus d'informations, consultez le [GitHub référentiel](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."
```
------
Une fois que vous avez obtenu le contenu de votre document SSM, utilisez l’une des procédures suivantes pour créer le document SSM personnalisé.
------
#### [ Console ]
**Pour créer un document de commande SSM**
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com//systems-manager/](https://console.aws.amazon.com//systems-manager/).
1. Dans le volet de navigation, choisissez **Documents**, puis sélectionnez **Créer un document**, **Commande ou session**.
1. Pour **Name (Nom)**, saisissez un nom évocateur pour le document.
1. Pour **Type de cible**, sélectionnez**/AWS::EC2::Instance**.
1. Pour **Type de document**, sélectionnez **Commande**.
1. Dans le champ **Contenu**, sélectionnez **YAML**, puis collez le contenu du document.
1. Dans la section **Balises du document**, ajoutez une balise avec une clé de balise `DLMScriptsAccess` et une valeur de balise `true`.
**Important**
La `DLMScriptsAccess:true` balise est requise par la politique de AWS gestion des **AWSDataLifecycleManagerSSMFullaccès** utilisée à l'*étape 3 : préparation du rôle IAM Amazon Data Lifecycle Manager*. La politique utilise la clé de condition `aws:ResourceTag` pour limiter l’accès aux documents SSM dotés de cette balise.
1. Sélectionnez **Créer un document**.
------
#### [ AWS CLI ]
**Pour créer un document de commande SSM**
Utilisez la commande [create-document](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html). Pour `--name`, saisissez un nom descriptif pour le document Pour `--document-type`, spécifiez `Command`. Pour `--content`, spécifiez le chemin d’accès au fichier .yaml avec le contenu du document SSM. Pour `--tags`, spécifiez `"Key=DLMScriptsAccess,Value=true"`.
```
$ 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"
```
------
### Étape 3 : Préparer le rôle IAM d’Amazon Data Lifecycle Manager
**Note**
Cette étape est nécessaire si :
Vous créez ou mettez à jour une politique de capture instantanée pre/post activée par script qui utilise un rôle IAM personnalisé.
Vous utilisez la ligne de commande pour créer ou mettre à jour une politique de capture instantanée pre/post activée par script qui utilise la valeur par défaut.
Si vous utilisez la console pour créer ou mettre à jour une politique d'instantanés pre/post activée par script qui utilise le rôle par défaut pour la gestion des instantanés (**AWSDataLifecycleManagerDefaultRole**), ignorez cette étape. Dans ce cas, nous associons automatiquement la politique **AWSDataLifecycleManagerSSMFulld'accès** à ce rôle.
Vous devez vous assurer que le rôle IAM que vous utilisez pour la politique accorde à Amazon Data Lifecycle Manager l’autorisation d’effectuer les actions SSM requises pour exécuter les pré-scripts et les post-scripts sur les instances ciblées par la politique.
Amazon Data Lifecycle Manager fournit une politique gérée (**AWSDataLifecycleManagerSSMFullAccess**) qui inclut les autorisations requises. Vous pouvez associer cette politique à votre rôle IAM pour gérer les instantanés afin de vous assurer qu’elle inclut les autorisations.
**Important**
La politique AWSData LifecycleManager SSMFull d'accès géré utilise la clé de `aws:ResourceTag` condition pour restreindre l'accès à des documents SSM spécifiques lors de l'utilisation de scripts pré et post. Pour autoriser Amazon Data Lifecycle Manager à accéder aux documents SSM, vous devez vous assurer que vos documents SSM sont balisés avec `DLMScriptsAccess:true`.
Vous pouvez également créer manuellement une politique personnalisée ou attribuer les autorisations requises directement au rôle IAM que vous utilisez. Vous pouvez utiliser les mêmes autorisations que celles définies dans la politique AWSData LifecycleManager SSMFull d'accès géré, mais la clé de `aws:ResourceTag` condition est facultative. Si vous décidez de ne pas inclure cette clé de condition, vous n’avez pas besoin de baliser vos documents SSM avec `DLMScriptsAccess:true`.
Utilisez l'une des méthodes suivantes pour ajouter la politique **AWSDataLifecycleManagerSSMFulld'accès** à votre rôle IAM.
------
#### [ Console ]
**Pour attacher la politique gérée à votre rôle personnalisé**
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Dans le panneau de navigation, choisissez **Roles (Rôles)**.
1. Recherchez et sélectionnez votre rôle personnalisé pour la gestion des instantanés.
1. Sous l’onglet **Permissions** (Autorisations), choisissez **Add Permissions** (Ajouter des autorisations), **Attach policies (Attacher des politiques)**.
1. Recherchez et sélectionnez la politique **AWSDataLifecycleManagerSSMFulld'accès** géré, puis choisissez **Ajouter des autorisations**.
------
#### [ AWS CLI ]
**Pour attacher la politique gérée à votre rôle personnalisé**
Utilisez la commande [ attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Pour `---role-name`, spécifiez le nom de votre rôle personnalisé. Pour `--policy-arn`, spécifiez `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess`.
```
$ aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
```
------
### Étape 4 : Créer une politique de cycle de vie des instantanés
Pour automatiser les instantanés cohérents par rapport à l’application, vous devez créer une politique de cycle de vie des instantanés qui cible les instances, et configurer des pré-scripts et post-scripts pour cette politique.
------
#### [ Console ]
**Pour créer la politique de cycle de vie des instantanés**
1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Dans le panneau de navigation, sélectionnez **Elastic Block Store**, **Gestionnaire de cycle de vie**, puis **Créer une stratégie de cycle de vie d’instantané**.
1. Dans la page **Sélectionner un type de stratégie**, choisissez **Stratégie d’instantané EBS**, puis **Suivant**.
1. Dans la section **Ressources cibles**, effectuez les opérations suivantes :
1. Pour **Types de ressources cibles**, choisissez `Instance`.
1. Pour **Balises de ressource cible**, spécifiez les balises de ressource qui identifient les instances à sauvegarder. Seules les ressources possédant les balises spécifiées seront sauvegardées.
1. Pour le **rôle IAM**, choisissez **AWSDataLifecycleManagerDefaultRole**(le rôle par défaut pour la gestion des instantanés) ou choisissez un rôle personnalisé que vous avez créé et préparé pour les pré-scripts et les post-scripts.
1. Configurez les planifications et les options supplémentaires selon les besoins. Nous vous recommandons de planifier les heures de création des instantanés pour des périodes correspondant à votre charge de travail, par exemple pendant les fenêtres de maintenance.
Pour SAP HANA, nous vous recommandons d’activer la restauration d’instantané rapide.
**Note**
Si vous activez une planification pour les sauvegardes VSS, vous ne pouvez pas activer **Exclure des volumes de données spécifiques** ou **Copier les balises depuis la source**.
1. Dans la section **Pré-scripts et post-scripts**, sélectionnez **Activer les pré-scripts et post-scripts**, puis effectuez les opérations suivantes, en fonction de votre charge de travail :
+ Pour créer des instantanés cohérents par rapport à l’application de vos applications Windows, sélectionnez **Sauvegarde VSS**.
+ Pour créer des instantanés cohérents par rapport à l’application de vos charges de travail SAP HANA, sélectionnez **SAP HANA**.
+ **Pour créer des instantanés cohérents avec les applications de toutes les autres bases de données et charges de travail, y compris vos bases de données MySQL, PostgreSQL ou InterSystems IRIS autogérées, à l'aide d'un document SSM personnalisé, sélectionnez Document SSM personnalisé.**
1. Pour **Option d’automatisation**, choisissez **Pré-scripts et post-scripts**.
1. Pour **Document SSM**, sélectionnez le document SSM que vous avez préparé.
1. En fonction de l’option que vous avez sélectionnée, configurez les options supplémentaires suivantes :
+ **Délai d’expiration du script** : (*document SSM personnalisé uniquement*) délai d’expiration au terme duquel Amazon Data Lifecycle Manager échoue à exécuter le script si celui-ci n’est pas terminé. Si un script ne s’exécute pas dans le délai imparti, Amazon Data Lifecycle Manager échoue. Le délai d’expiration s’applique aux pré-scripts et post-scripts individuellement. Le délai d’expiration minimum et par défaut est de 10 secondes. Et le délai d’expiration maximum est de 120 secondes.
+ **Relancer les scripts en échec** : sélectionnez cette option pour relancer les scripts qui ne se terminent pas dans le délai imparti. En cas d’échec du pré-script, Amazon Data Lifecycle Manager relance l’intégralité du processus de création d’instantanés, y compris l’exécution des pré-scripts et post-scripts. Si le post-script échoue, Amazon Data Lifecycle Manager relance uniquement le post-script ; dans ce cas, le pré-script sera terminé et l’instantané aura peut-être été créé.
+ **Prise par défaut d’instantanés en cas de panne** : sélectionnez cette option pour utiliser par défaut des instantanés en cas de panne si le pré-script ne s’exécute pas. Il s’agit du comportement de création d’instantanés par défaut pour Amazon Data Lifecycle Manager si les pré-scripts et post-scripts ne sont pas activés. Si vous avez activé les relances, Amazon Data Lifecycle Manager utilise par défaut des instantanés en cas de panne uniquement une fois que toutes les relances ont été épuisées. Si le pré-script échoue et que vous n’utilisez pas par défaut des instantanés en cas de panne, Amazon Data Lifecycle Manager ne crée pas d’instantanés pour l’instance pendant cette exécution planifiée.
**Note**
Si vous créez des instantanés pour SAP HANA, vous souhaiterez peut-être désactiver cette option. Les instantanés en cas de panne des charges de travail SAP HANA ne peuvent pas être restaurés de la même manière.
1. Choisissez **Créer une politique par défaut**.
**Note**
Si vous obtenez l’erreur `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consultez [Résoudre les problèmes liés à Amazon Data Lifecycle Manager](dlm-troubleshooting.md) pour plus d’informations.
------
#### [ AWS CLI ]
**Pour créer la politique de cycle de vie des instantanés**
Utilisez la [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)commande et incluez les `Scripts` paramètres dans`CreateRule`. Pour plus d’informations sur les paramètres, consultez la [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
```
Lorsque `policyDetails.json` inclut l’un des éléments suivants, selon votre cas d’utilisation :
+ **Sauvegarde VSS**
```
{
"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
}
}]
}
```
+ **Sauvegardes SAP HANA**
```
{
"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
}
}]
}
```
+ **Document SSM personnalisé**
```
{
"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
}
}]
}
```
------
## Considérations relatives aux sauvegardes VSS avec Amazon Data Lifecycle Manager
Avec Amazon Data Lifecycle Manager, vous pouvez sauvegarder et restaurer les applications Windows compatibles avec VSS (Volume Shadow Copy Service) exécutées sur des instances Amazon EC2. Si l’application possède un enregistreur VSS enregistré auprès de Windows VSS, Amazon Data Lifecycle Manager crée un instantané qui sera cohérent avec l’application pour cette application.
**Note**
Amazon Data Lifecycle Manager ne prend actuellement en charge que les instantanés cohérents par rapport à l’application des ressources exécutées sur Amazon EC2, en particulier pour les scénarios de sauvegarde dans lesquels les données d’application peuvent être restaurées en remplaçant une instance existante par une nouvelle instance créée à partir de la sauvegarde. Les types d’instances ou applications ne sont pas tous pris en charge pour les sauvegardes VSS. *Pour plus d'informations, consultez la section [Instantanés Windows VSS cohérents avec les applications](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html) dans le guide de l'utilisateur Amazon EC2.*
**Types d’instance non pris en charge**
Les types d’instances Amazon EC2 suivants ne sont pas pris en charge pour les sauvegardes VSS. Si votre politique cible l’un de ces types d’instances, Amazon Data Lifecycle Manager peut toujours créer des sauvegardes VSS, mais les instantanés risquent de ne pas être balisés avec les balises système requises. Sans ces balises, les instantanés ne seront pas gérés par Amazon Data Lifecycle Manager après leur création. Vous aurez peut-être besoin de supprimer ces instantanés manuellement.
+ T3 : `t3.nano` \$1 `t3.micro`
+ T3a : `t3a.nano` \$1 `t3a.micro`
+ T2 : `t2.nano` \$1 `t2.micro`
## Responsabilité partagée pour les instantanés cohérents par rapport à l’application
**Vous devez vous assurer que :**
+ L'agent SSM est installé et up-to-date s'exécute sur vos instances cibles
+ Systems Manager est autorisé à effectuer les actions requises sur les instances cibles
+ Amazon Data Lifecycle Manager est autorisé à effectuer les actions Systems Manager requises pour exécuter des pré-scripts et des post-scripts sur les instances cibles.
+ Pour les charges de travail personnalisées, telles que les bases de données MySQL, PostgreSQL ou InterSystems IRIS autogérées, le document SSM que vous utilisez inclut les actions correctes et requises pour geler, vider et décongeler la configuration de votre base de données. I/O
+ Les délais de création d’instantanés correspondent à votre planification de charge de travail. Par exemple, essayez de planifier la création d’instantanés pendant les fenêtres de maintenance planifiées.
**Amazon Data Lifecycle Manager garantit que :**
+ la création d’instantanés démarre dans les 60 minutes suivant l’heure de création d’instantanés prévue ;
+ les pré-scripts s’exécutent avant le lancement de la création d’instantanés ;
+ les post-scripts s’exécutent une fois que le pré-script a réussi et que la création d’instantanés a été lancée ; Amazon Data Lifecycle Manager exécute le post-script uniquement si le pré-script aboutit ; si le pré-script échoue, Amazon Data Lifecycle Manager n’exécute pas le post-script ;
+ les instantanés sont balisés avec les balises appropriées lors de leur création ;
+ CloudWatch les métriques et les événements sont émis lorsque les scripts sont lancés et lorsqu'ils échouent ou réussissent.
# Autres cas d'utilisation des scripts antérieurs et postérieurs à Data Lifecycle Manager
Outre l’automatisation des instantanés cohérents par rapport à l’application, vous pouvez utiliser les pré-scripts et les post-scripts ensemble ou séparément pour automatiser d’autres tâches administratives avant ou après la création des instantanés. Par exemple :
+ Utilisation d’un pré-script pour appliquer des correctifs avant la création d’instantanés. Cela peut vous aider à créer des instantanés après avoir appliqué vos mises à jour logicielles hebdomadaires ou mensuelles régulières.
**Note**
Si vous choisissez d’exécuter uniquement un pré-script, l’option **Prise par défaut d’instantanés en cas de panne** est activée par défaut.
+ Utilisation d’un post-script pour appliquer des correctifs après la création d’instantanés. Cela peut vous aider à créer des instantanés avant d’appliquer vos mises à jour logicielles hebdomadaires ou mensuelles régulières.
## Démarrage pour d’autres cas d’utilisation
Cette section explique les étapes à suivre lorsque vous utilisez des scripts de and/or pré-publication pour des **cas d'utilisation autres que des instantanés cohérents avec les applications**.
### Étape 1 : Préparer les instances cibles
**Pour préparer vos instances cibles pour les scripts de and/or pré-publication**
1. Installez l’agent SSM sur vos instances cibles, s’il n’est pas déjà installé. Si l’agent SSM est déjà installé sur vos instances cibles, ignorez cette étape.
+ (Instances Linux) [Installation manuelle de l'agent SSM sur les instances EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) pour Linux
+ (instances Windows) [Utilisation de l'agent SSM sur les instances EC2 pour](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) Windows Server
1. Assurez-vous que l’agent SSM est en cours d’exécution. Pour plus d’informations, consultez [Vérification du statut de l’SSM Agent et démarrage de l’agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Configurez Systems Manager pour des instances Amazon EC2. Pour plus d’informations, consultez [Configuration de Systems Manager pour des instances Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) dans le *Guide de l’utilisateur AWS Systems Manager *.
### Étape 2 : Préparer le document SSM
Vous devez créer un document de commande SSM qui inclut les scripts de and/or pré-publication avec les commandes que vous souhaitez exécuter.
Vous pouvez créer un document SSM à l’aide du modèle de document SSM vide ci-dessous et ajouter vos commandes pré-script et post-script dans les sections de document appropriées.
**Notez ce qui suit :**
Il est de votre responsabilité de vous assurer que le document SSM exécute les actions correctes et requises pour votre charge de travail.
Le document SSM doit inclure les champs obligatoires pour `allowedValues`, notamment `pre-script`, `post-script` et `dry-run`. Amazon Data Lifecycle Manager exécutera des commandes sur votre instance en fonction du contenu de ces sections. Si votre document SSM ne contient pas ces sections, Amazon Data Lifecycle Manager le considérera comme un échec d’exécution.
```
###===============================================================================###
# 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."
```
### Étape 3 : Préparer le rôle IAM d’Amazon Data Lifecycle Manager
**Note**
Cette étape est nécessaire si :
Vous créez ou mettez à jour une politique de capture instantanée pre/post activée par script qui utilise un rôle IAM personnalisé.
Vous utilisez la ligne de commande pour créer ou mettre à jour une politique de capture instantanée pre/post activée par script qui utilise la valeur par défaut.
Si vous utilisez la console pour créer ou mettre à jour une politique d'instantanés pre/post activée par script qui utilise le rôle par défaut pour la gestion des instantanés (**AWSDataLifecycleManagerDefaultRole**), ignorez cette étape. Dans ce cas, nous associons automatiquement la politique **AWSDataLifecycleManagerSSMFulld'accès** à ce rôle.
Vous devez vous assurer que ce rôle IAM que vous utilisez pour la politique accorde à Amazon Data Lifecycle Manager l’autorisation d’effectuer les actions SSM requises pour exécuter les pré-scripts et les post-scripts sur les instances ciblées par la politique.
Amazon Data Lifecycle Manager fournit une politique gérée (**AWSDataLifecycleManagerSSMFullAccess**) qui inclut les autorisations requises. Vous pouvez associer cette politique à votre rôle IAM pour gérer les instantanés afin de vous assurer qu’elle inclut les autorisations.
**Important**
La politique AWSData LifecycleManager SSMFull d'accès géré utilise la clé de `aws:ResourceTag` condition pour restreindre l'accès à des documents SSM spécifiques lors de l'utilisation de scripts pré et post. Pour autoriser Amazon Data Lifecycle Manager à accéder aux documents SSM, vous devez vous assurer que vos documents SSM sont balisés avec `DLMScriptsAccess:true`.
Vous pouvez également créer manuellement une politique personnalisée ou attribuer les autorisations requises directement au rôle IAM que vous utilisez. Vous pouvez utiliser les mêmes autorisations que celles définies dans la politique AWSData LifecycleManager SSMFull d'accès géré, mais la clé de `aws:ResourceTag` condition est facultative. Si vous décidez de ne pas utiliser cette clé de condition, vous n’avez pas besoin de baliser vos documents SSM avec `DLMScriptsAccess:true`.
Utilisez l'une des méthodes suivantes pour ajouter la politique **AWSDataLifecycleManagerSSMFulld'accès** à votre rôle IAM.
------
#### [ Console ]
**Pour attacher la politique gérée à votre rôle personnalisé**
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Dans le panneau de navigation, choisissez **Roles (Rôles)**.
1. Recherchez et sélectionnez votre rôle personnalisé pour la gestion des instantanés.
1. Sous l’onglet **Permissions** (Autorisations), choisissez **Add Permissions** (Ajouter des autorisations), **Attach policies (Attacher des politiques)**.
1. Recherchez et sélectionnez la politique **AWSDataLifecycleManagerSSMFulld'accès** géré, puis choisissez **Ajouter des autorisations**.
------
#### [ AWS CLI ]
**Pour attacher la politique gérée à votre rôle personnalisé**
Utilisez la commande [ attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Pour `---role-name`, spécifiez le nom de votre rôle personnalisé. Pour `--policy-arn`, spécifiez `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess`.
```
$ aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
```
------
### Création d’une politique de cycle de vie des instantanés
------
#### [ Console ]
**Pour créer la politique de cycle de vie des instantanés**
1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Dans le panneau de navigation, sélectionnez **Elastic Block Store**, **Gestionnaire de cycle de vie**, puis **Créer une stratégie de cycle de vie d’instantané**.
1. Dans la page **Sélectionner un type de stratégie**, choisissez **Stratégie d’instantané EBS**, puis **Suivant**.
1. Dans la section **Ressources cibles**, effectuez les opérations suivantes :
1. Pour **Types de ressources cibles**, choisissez `Instance`.
1. Pour **Balises de ressource cible**, spécifiez les balises de ressource qui identifient les instances à sauvegarder. Seules les ressources possédant les balises spécifiées seront sauvegardées.
1. Pour le **rôle IAM**, choisissez **AWSDataLifecycleManagerDefaultRole**(le rôle par défaut pour la gestion des instantanés) ou choisissez un rôle personnalisé que vous avez créé et préparé pour les pré-scripts et les post-scripts.
1. Configurez les planifications et les options supplémentaires selon les besoins. Nous vous recommandons de planifier les heures de création des instantanés pour des périodes correspondant à votre charge de travail, par exemple pendant les fenêtres de maintenance.
1. Dans la section **Pré-scripts et post-scripts**, sélectionnez **Activer les pré-scripts et post-scripts**, puis effectuez les opérations suivantes :
1. Sélectionnez **Document SSM personnalisé**.
1. Pour **Option d’automatisation**, choisissez l’option qui correspond aux scripts que vous souhaitez exécuter.
1. Pour **Document SSM**, sélectionnez le document SSM que vous avez préparé.
1. Configurez les options supplémentaires suivantes au besoin :
+ **Délai d’expiration du script** : délai d’expiration au terme duquel Amazon Data Lifecycle Manager échoue à exécuter le script si celui-ci n’est pas terminé. Si un script ne s’exécute pas dans le délai imparti, Amazon Data Lifecycle Manager échoue. Le délai d’expiration s’applique aux pré-scripts et post-scripts individuellement. Le délai d’expiration minimum et par défaut est de 10 secondes. Et le délai d’expiration maximum est de 120 secondes.
+ **Relancer les scripts en échec** : sélectionnez cette option pour relancer les scripts qui ne se terminent pas dans le délai imparti. En cas d’échec du pré-script, Amazon Data Lifecycle Manager relance l’intégralité du processus de création d’instantanés, y compris l’exécution des pré-scripts et post-scripts. Si le post-script échoue, Amazon Data Lifecycle Manager relance uniquement le post-script ; dans ce cas, le pré-script sera terminé et l’instantané aura peut-être été créé.
+ **Prise par défaut d’instantanés en cas de panne** : sélectionnez cette option pour utiliser par défaut des instantanés en cas de panne si le pré-script ne s’exécute pas. Il s’agit du comportement de création d’instantanés par défaut pour Amazon Data Lifecycle Manager si les pré-scripts et post-scripts ne sont pas activés. Si vous avez activé les relances, Amazon Data Lifecycle Manager utilise par défaut des instantanés en cas de panne uniquement une fois que toutes les relances ont été épuisées. Si le pré-script échoue et que vous n’utilisez pas par défaut des instantanés en cas de panne, Amazon Data Lifecycle Manager ne crée pas d’instantanés pour l’instance pendant cette exécution planifiée.
1. Choisissez **Créer une politique par défaut**.
**Note**
Si vous obtenez l’erreur `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consultez [Résoudre les problèmes liés à Amazon Data Lifecycle Manager](dlm-troubleshooting.md) pour plus d’informations.
------
#### [ AWS CLI ]
**Pour créer la politique de cycle de vie des instantanés**
Utilisez la [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)commande et incluez les `Scripts` paramètres dans`CreateRule`. Pour plus d’informations sur les paramètres, consultez la [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
```
Où `policyDetails.json` inclut les éléments suivants.
```
{
"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
}
}]
}
```
------
# Comment fonctionnent les scripts avant et après Amazon Data Lifecycle Manager
L’image suivante montre le flux de processus pour les pré-scripts et les post-scripts lors de l’utilisation de documents SSM personnalisés. Cela ne s’applique pas aux sauvegardes VSS.
![\[Flux de processus pré-scripts et post-scripts Amazon Data Lifecycle Manager\]](http://docs.aws.amazon.com/fr_fr/ebs/latest/userguide/images/dlm-scripts.png)
Au moment prévu de la création d’instantanés, les actions et interactions entre services suivantes se produisent.
1. Amazon Data Lifecycle Manager lance l’action de pré-script en appelant le document SSM et en transmettant le paramètre `pre-script`.
**Note**
Les étapes 1 à 3 se produisent uniquement si vous exécutez des pré-scripts. Si vous exécutez uniquement des post-scripts, les étapes 1 à 3 sont ignorées.
1. Systems Manager envoie des commandes de pré-script à l’agent SSM exécuté sur les instances cibles. L’agent SSM exécute les commandes sur l’instance et renvoie les informations sur les statuts à Systems Manager.
Par exemple, si le document SSM est utilisé pour créer des instantanés cohérents avec les applications, le pré-script peut se figer et se vider I/O pour garantir que toutes les données mises en mémoire tampon sont écrites sur le volume avant la prise de l'instantané.
1. Systems Manager envoie des mises à jour du statut des commandes pré-script à Amazon Data Lifecycle Manager. Si le pré-script échoue, Amazon Data Lifecycle Manager effectue l’une des actions suivantes, en fonction de votre configuration des options de pré-script et de post-script :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ebs/latest/userguide/script-flow.html)
1. Amazon Data Lifecycle Manager lance la création d’instantanés.
1. Amazon Data Lifecycle Manager lance l’action de post-script en appelant le document SSM et en transmettant le paramètre `post-script`.
**Note**
Les étapes 5 à 7 se produisent uniquement si vous exécutez des pré-scripts. Si vous exécutez uniquement des post-scripts, les étapes 1 à 3 sont ignorées.
1. Systems Manager envoie des commandes de post-script à l’agent SSM exécuté sur les instances cibles. L’agent SSM exécute les commandes sur l’instance et renvoie les informations sur les statuts à Systems Manager.
Par exemple, si le document SSM permet des instantanés cohérents avec les applications, ce post-script peut être dégelé I/O pour garantir que vos bases de données reprennent leurs opérations d'E/S normales après la prise de l'instantané.
1. Si vous exécutez un post-script et que Systems Manager indique qu’il s’est correctement terminé, le processus se termine.
Si le post-script échoue, Amazon Data Lifecycle Manager effectue l’une des actions suivantes, en fonction de votre configuration des options de pré-script et de post-script :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ebs/latest/userguide/script-flow.html)
N’oubliez pas qu’en cas d’échec du post-script, le pré-script (s’il est activé) se termine avec succès et les instantanés ont peut-être été créés. Vous devrez peut-être prendre d’autres mesures sur l’instance pour vous assurer qu’elle fonctionne comme prévu. Par exemple, si le pré-script était suspendu et vidé. 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. Le processus de création d’instantanés peut se terminer une fois le post-script terminé. Le temps nécessaire pour terminer l’instantané dépend de la taille de l’instantané.
# Identifiez les instantanés créés avec les scripts pré et post de Data Lifecycle Manager
Amazon Data Lifecycle Manager attribue automatiquement les balises système suivantes aux instantanés créés à l’aide de pré-scripts et de post-scripts.
+ Clé : `aws:dlm:pre-script` ; Valeur : `SUCCESS`\$1`FAILED`
Une valeur de balise de `SUCCESS` indique que le pré-script a été exécuté correctement. Une valeur de balise de `FAILED` indique que le pré-script n’a pas été exécuté correctement.
+ Clé : `aws:dlm:post-script` ; Valeur : `SUCCESS`\$1`FAILED`
Une valeur de balise de `SUCCESS` indique que le post-script a été exécuté correctement. Une valeur de balise de `FAILED` indique que le post-script n’a pas été exécuté correctement.
Pour les documents SSM personnalisés et les sauvegardes SAP HANA, vous pouvez déduire la création réussie d’un instantané cohérent par rapport à l’application si l’instantané est balisé avec `aws:dlm:pre-script:SUCCESS` et `aws:dlm:post-script:SUCCESS`.
En outre, les instantanés cohérents par rapport à l’application créés à l’aide de la sauvegarde VSS sont automatiquement balisés avec :
+ Clé : `AppConsistent tag` ; Valeur : `true`\$1`false`
Une valeur de balise égale à `true` indique que la sauvegarde VSS a réussi et que les instantanés sont cohérents avec l’application. Une valeur de balise égale à `false` indique que la sauvegarde VSS n’a pas réussi et que les instantanés ne sont pas cohérents avec l’application.
# Surveillez les scripts avant et après Amazon Data Lifecycle Manager
**CloudWatch Métriques Amazon**
Amazon Data Lifecycle Manager publie les CloudWatch indicateurs suivants lorsque les scripts pré et post échouent et réussissent et lorsque les sauvegardes VSS échouent et réussissent.
+ `PreScriptStarted`
+ `PreScriptCompleted`
+ `PreScriptFailed`
+ `PostScriptStarted`
+ `PostScriptCompleted`
+ `PostScriptFailed`
+ `VSSBackupStarted`
+ `VSSBackupCompleted`
+ `VSSBackupFailed`
Pour de plus amples informations, veuillez consulter [Surveillez les politiques de Data Lifecycle Manager à l'aide CloudWatch](monitor-dlm-cw-metrics.md).
**Amazon EventBridge**
Amazon Data Lifecycle Manager émet l' EventBridge événement Amazon suivant lorsqu'un pré-script ou un post-script est lancé, réussit ou échoue
+ `DLM Pre Post Script Notification`
Pour de plus amples informations, veuillez consulter [Surveillez les politiques de Data Lifecycle Manager à l'aide EventBridge](monitor-cloudwatch-events.md).