Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Crea policy personalizzate di Amazon Data Lifecycle Manager per gli snapshot EBS La procedura seguente illustra come utilizzare Amazon Data Lifecycle Manager per automatizzare i cicli di vita degli snapshot Amazon EBS. **Topics** + [ ## Creare una policy del ciclo di vita dello snapshot ](#create-snap-policy) + [ ## Considerazioni sulle policy del ciclo di vita degli snapshot ](#snapshot-considerations) + [ ## Risorse aggiuntive ](#snapshot-additional-resources) + [Automatizza le istantanee coerenti con l'applicazione](automate-app-consistent-backups.md) + [Altri casi d'uso per gli script pre e post](script-other-use-cases.md) + [Come funzionano gli script pre e post](script-flow.md) + [Identifica le istantanee create con script precedenti e successivi](dlm-script-tags.md) + [Monitora gli script precedenti e successivi](dlm-script-monitoring.md) ## Creare una policy del ciclo di vita dello snapshot Per creare una policy del ciclo di vita dello snapshot, attenersi a una delle procedure descritte di seguito. ------ #### [ Console ] **Come creare una policy di snapshot** 1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Nel riquadro di navigazione, scegliere **Elastic Block Store**, **Lifecycle Manager**, quindi selezionare **Create lifecycle policy (Crea policy del ciclo di vita)**. 1. Nella schermata **Seleziona il tipo di policy**, seleziona **Policy di snapshot EBS** e quindi **Successivo**. 1. Nella sezione **Risorse di destinazione**, procedere come segue: 1. Per **Tipi di risorse di destinazione** seleziona il tipo di risorsa di cui eseguire il backup. Scegliere `Volume` per creare snapshot di singoli volumi oppure `Instance` per creare snapshot a più volumi dai volumi collegati a un'istanza. 1. (*Outposte solo per i clienti della zona locale*) Specificate dove si trovano le risorse di destinazione. Per **Posizione delle risorse interessate**, specifica dove sono collocate le risorse di destinazione. + Per indirizzare le risorse in una regione, scegli **AWS Regione**. Amazon Data Lifecycle Manager eseguirà il backup di tutte le risorse del tipo specificato con tag di destinazione corrispondenti solo nella regione corrente. Le istantanee vengono create nella stessa regione. + Per indirizzare le risorse in Local Zones, scegli **AWS Local Zones**. Amazon Data Lifecycle Manager eseguirà il backup di tutte le risorse del tipo specificato con tag di destinazione corrispondenti solo in tutte le Local Zones della regione corrente. Le istantanee possono essere create nella stessa zona locale della risorsa di origine o nella sua regione principale. + Per indirizzare le risorse eOutpost, scegli **AWS Outpost**. Amazon Data Lifecycle Manager eseguirà il backup di tutte le risorse del tipo specificato con tag di destinazione corrispondenti in tutto Outposts il tuo account. Le istantanee possono essere create sulla Outpost stessa risorsa di origine o nella regione madre. 1. Per **Tag della risorsa di destinazione**, seleziona i tag delle risorse che identificano i volumi o le istanze di cui eseguire il backup. La policy esegue il backup solo delle risorse che dispongono delle coppie di chiave tag e valore specificate. 1. In **Description (Descrizione)** immettere una breve descrizione della policy. 1. Per **Ruolo IAM**, seleziona il ruolo IAM che dispone delle autorizzazioni per gestire gli snapshot e per descrivere volumi e istanze. Per utilizzare il ruolo predefinito fornito da Amazon Data Lifecycle Manager, seleziona **Ruolo predefinito**. In alternativa, per utilizzare un ruolo IAM personalizzato creato in precedenza, seleziona **Scegli un altro ruolo**, quindi seleziona il ruolo desiderato. 1. Per **Tag di policy**, aggiungi i tag da applicare alla policy del ciclo di vita. Puoi utilizzare i tag per identificare e categorizzare le policy. 1. Per **Policy status** (Stato della policy dopo la creazione), seleziona **Enable**(Abilita) per avviare l'esecuzione della policy all'ora successiva pianificata o **Disable policy** (Disabilita la policy) per impedirne l'esecuzione. Se la policy non viene attivata ora, non inizierà a creare snapshot finché non verrà attivata manualmente dopo la creazione. 1. (*Policy destinate solo alle istanze*) Escludere i volumi dai set di snapshot a più volumi. Per impostazione predefinita, Amazon Data Lifecycle Manager crea snapshot di tutti i volumi collegati alle istanze di destinazione. Tuttavia, puoi scegliere di creare snapshot per un sottoinsieme dei volumi collegati. Nella sezione **Parameters** (Parametri) esegui le operazioni seguenti: + Se non desideri creare snapshot dei volumi root collegati alle istanze target, seleziona **Exclude root volume** (Escludi il volume root). Se selezioni questa opzione, solo i volumi di dati (non root) collegati alle istanze target verranno inclusi nei set di snapshot a più volumi. + Se desideri creare snapshot di un sottoinsieme dei volumi di dati (non root) collegati all'istanza, seleziona **Exclude specific data volumes** (Escludi volumi di dati specifici), quindi specifica i tag da utilizzare per identificare i volumi di dati da escludere. Amazon Data Lifecycle Manager non creerà snapshot di volumi di dati contenenti uno qualsiasi dei tag specificati. Amazon Data Lifecycle Manager creerà solo snapshot di volumi di dati non contenenti i tag specificati. 1. Scegli **Next (Successivo)**. 1. Nella schermata **Configura pianificazione**, configura le pianificazioni delle policy. Una policy può avere fino a 4 pianificazioni. La pianificazione 1 è obbligatoria. Le pianificazioni 2, 3 e 4 sono facoltative. Per ogni pianificazione di policy che viene aggiunta, completa le seguenti operazioni: 1. Nella sezione **Dettagli pianificazione**, completa le operazioni descritte di seguito. 1. Per **Nome pianificazione**, specifica un nome descrittivo per la pianificazione. 1. Per **Frequenza** e nei campi correlati, configura l'intervallo tra un'esecuzione della policy e l'altra. Puoi configurare le esecuzioni delle policy in base a una pianificazione giornaliera, settimanale, mensile o annuale. In alternativa, scegli **Custom cron expression (Personalizza espressione cron)** per specificare un intervallo massimo di 1 anno. Per ulteriori informazioni, consulta [Cron and rate expression](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html) nella *Amazon EventBridge User Guide*. **Nota** Se devi abilitare l'**archiviazione degli snapshot** per la pianificazione, devi selezionare la frequenza **mensile** o **annuale**, oppure devi specificare un'espressione cron con una frequenza di creazione di almeno 28 giorni. Se specifichi una frequenza mensile che crea snapshot in un giorno specifico di una settimana specifica (ad esempio il secondo giovedì del mese), per una pianificazione basata sul conteggio il numero di conservazioni per il livello archivio deve essere almeno 4. 1. In **A partire dalle**, specifica l'ora di avvio pianificata per le esecuzioni della policy. La prima esecuzione della policy inizia entro un'ora dall'orario pianificato. L'ora deve essere inserita in formato `hh:mm` UTC. 1. Per **Tipo di conservazione**, specifica la policy di conservazione per gli snapshot creati dalla pianificazione. È possibile conservare gli snapshot in base al loro conteggio totale o alla loro età. + Mantenimento basato sul conteggio + Con l'archiviazione degli snapshot disabilitata, l'intervallo è da `1` a `1000`. Quando viene raggiunta la soglia di conservazione, lo snapshot meno recente viene eliminato definitivamente. + Con l'archiviazione degli snapshot abilitata, l'intervallo è da `0` (archiviazione immediata dopo la creazione) a `1000`. Quando viene raggiunta la soglia di conservazione, lo snapshot meno recente viene convertito in uno snapshot completo e viene spostato nel livello di archivio. + Mantenimento basato sull'età + Con l'archiviazione degli snapshot disabilitata, l'intervallo è da `1` giorno a `100` anni. Quando viene raggiunta la soglia di conservazione, lo snapshot meno recente viene eliminato definitivamente. + Con l'archiviazione degli snapshot abilitata, l'intervallo è da `0` giorni (archiviazione immediata dopo la creazione) a `100` anni. Quando viene raggiunta la soglia di conservazione, lo snapshot meno recente viene convertito in uno snapshot completo e viene spostato nel livello di archivio. **Nota** Tutte le pianificazioni devono avere lo stesso tipo di conservazione (in base all'età o in base al conteggio). È possibile specificare il tipo di conservazione solo per Pianificazione 1. Le pianificazioni 2, 3 e 4 ereditano il tipo di conservazione dal programma 1. Ogni programma può avere il proprio conteggio o periodo di conservazione. Se abiliti il ripristino rapido degli snapshot, la copia tra regioni o la condivisione di snapshot, devi specificare un numero di conservazioni di almeno `1` o un periodo di conservazione di almeno `1` giorno. 1. (*AWS Outposts e solo per i clienti della zona locale*) Specificate la destinazione dello snapshot. Per **Destinazione dello snapshot**, specifica la destinazione per gli snapshot creati dalla policy. + Se la politica riguarda le risorse in una regione, le istantanee devono essere create nella stessa regione. AWS La regione è selezionata automaticamente. + Se la politica riguarda le risorse in una zona locale, è possibile creare istantanee nella stessa zona locale della risorsa di origine o nella relativa regione principale. + Se la politica riguarda le risorse su unaOutpost, è possibile creare istantanee sulla Outpost stessa risorsa di origine o nella relativa regione principale. 1. Configura il tagging per gli snapshot. Nella sezione **Tagging**, procedi nel seguente modo: 1. Per copiare tutti i tag definiti dall'utente dal volume di origine agli snapshot creati dalla pianificazione, seleziona **Copia tag dall'origine**. 1. Per specificare eventuali tag aggiuntivi da assegnare agli snapshot creati da questa pianificazione, seleziona **Aggiungi tag**. 1. Configura gli script pre e post per gli snapshot coerenti con l'applicazione. Per ulteriori informazioni, consulta [Automatizza le istantanee coerenti con le applicazioni con Data Lifecycle Manager](automate-app-consistent-backups.md). 1. (*Policy destinate solo ai volumi*) Configura l'archiviazione degli snapshot. Nella sezione **Archiviazione degli snapshot**, procedi come segue: **Nota** Puoi abilitare l'archiviazione degli snapshot per una sola pianificazione in una policy. 1. Per abilitare l'archiviazione degli snapshot per la pianificazione, seleziona **Archivia snapshot creati da questa pianificazione**. **Nota** Puoi abilitare l'archiviazione degli snapshot solo se la frequenza di creazione degli snapshot è mensile o annuale, oppure se specifichi un'espressione cron con una frequenza di creazione di almeno 28 giorni. 1. Specifica la regola di conservazione per gli snapshot nel livello archivio. + Per **pianificazioni basate sul conteggio**, specifica il numero di snapshot da mantenere nel livello archivio. Quando viene raggiunta la soglia di conservazione, lo snapshot meno recente viene eliminato definitivamente dal livello di archivio. Ad esempio, se specifichi 3, la pianificazione manterrà max 3 snapshot nel livello archivio. Quando viene archiviato il quarto snapshot, il più vecchio dei tre snapshot esistenti nel livello archivio viene eliminato. + Per **pianificazioni basate sul conteggio**, specifica il numero di snapshot da mantenere nel livello archivio. Quando viene raggiunta la soglia di conservazione, lo snapshot meno recente viene eliminato definitivamente dal livello di archivio. Ad esempio, se specifichi 120 giorni, la pianificazione eliminerà automaticamente gli snapshot dal livello archivio quando avranno raggiunto tale età. **Importante** Il periodo minimo di conservazione per gli snapshot archiviati è 90 giorni. Devi specificare una regola di conservazione che mantenga lo snapshot per almeno 90 giorni. 1. Abilitare il ripristino rapido degli snapshot. Per abilitare il ripristino rapido degli snapshot creati dalla pianificazione, nella finestra di dialogo **Ripristino rapido degli snapshot**, seleziona **Abilita ripristino rapido degli snapshot**. Se si abilita il ripristino rapido dello snapshot, è necessario scegliere le zone di disponibilità in cui attivarlo. Se la pianificazione utilizza una pianificazione di conservazione basata sull'età, è necessario specificare il periodo durante il quale abilitare il ripristino rapido degli snapshot per ogni snapshot. Se la pianificazione utilizza la conservazione basata su conteggi, è necessario specificare il numero massimo di snapshot per consentire il ripristino rapido degli snapshot. Se la pianificazione crea istantanee su unaOutpost, non è possibile abilitare il ripristino rapido delle istantanee. Il ripristino rapido delle istantanee non è supportato con le istantanee locali archiviate su un. Outpost **Nota** Viene fatturato ogni minuto in cui viene abilitato il ripristino rapido degli snapshot per uno snapshot in una determinata zona di disponibilità. Le tariffe sono proporzionalmente valutate con un minimo di un'ora. 1. Configura la copia tra Regioni. **Per copiare le istantanee create dalla pianificazione in una Outpost o in un'altra regione, nella sezione **Copia tra regioni, seleziona Abilita copia** tra regioni.** Se la pianificazione crea istantanee in una regione, puoi copiare le istantanee in un massimo di tre regioni aggiuntive o nel tuo account. Outposts È necessario specificare una regola di copia interregionale distinta per ogni regione di destinazione o. Outpost Per ogni regioneOutpost, puoi scegliere politiche di conservazione diverse e puoi scegliere se copiare tutti i tag o nessun tag. Se lo snapshot di origine è crittografato o se la crittografia è abilitata per impostazione predefinita, le copie degli snapshot saranno crittografate. Se lo snapshot di origine non è crittografato, è possibile abilitare la crittografia. Se non si specifica una chiave KMS, gli snapshot vengono crittografati utilizzando la chiave KMS predefinita per la crittografia EBS in ogni regione di destinazione. Se si specifica una Chiave KMS per la regione di destinazione, il ruolo IAM selezionato deve avere accesso alla Chiave KMS. **Nota** È necessario assicurarsi di non superare il numero di copie di snapshot simultanee per regione. Se la policy crea istantanee su una regioneOutpost, non è possibile copiare le istantanee in una regione o in un'altra Outpost e le impostazioni di copia tra aree geografiche non sono disponibili. 1. Configura la condivisione tra account. Nella **condivisione tra account**, configura la politica per condividere automaticamente le istantanee create dalla pianificazione con altri account. AWS Esegui questa operazione: 1. Per abilitare la condivisione con altri AWS account, seleziona **Abilita condivisione tra** account. 1. Per aggiungere gli account con cui condividere gli snapshot, scegli **Aggiungi account**, inserisci l'ID account AWS di 12 cifre e seleziona **Aggiungi**. 1. Per annullare automaticamente la condivisione degli snapshot condivisi dopo un periodo di tempo specifico, selezionare **Unshare automatically (Annulla la condivisione automatica)**. Se si sceglie di annullare automaticamente la condivisione degli snapshot condivisi, il periodo dopo il quale si desidera annullare la condivisione automatica degli snapshot non può essere più lungo del periodo durante il quale la policy conserva gli snapshot. Ad esempio, se la configurazione di conservazione della policy prevede la conservazione degli snapshot per un periodo di 5 giorni, è possibile configurare la policy solo affinché annulli automaticamente la condivisione degli snapshot condivisi dopo un periodo di massimo 4 giorni. Questo vale per le policy con configurazioni di conservazione degli snapshot basate sull'età e sul conteggio. Se non si attiva l'annullamento della condivisione automatica, lo snapshot sarà condiviso fino a quando non viene eliminato. **Nota** È possibile condividere solo snapshot non crittografati o crittografati utilizzando una chiave gestita dal cliente. Non è possibile condividere snapshot crittografati con la Chiave KMS di crittografia EBS predefinita. Se si condividono snapshot crittografati, è necessario condividere con gli account di destinazione anche la Chiave KMS utilizzata per crittografare il volume di origine. Per ulteriori informazioni, consultare [Consentire agli utenti in altri account di utilizzare una chiave KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) nella *Guida per gli sviluppatori di AWS Key Management Service *. 1. Per aggiungere ulteriori pianificazioni, seleziona **Aggiungi un'altra pianificazione**, che si trova nella parte superiore dello schermo. Per ogni pianificazione aggiuntiva, completa i campi come descritto in precedenza in questo argomento. 1. Dopo aver aggiunto le pianificazioni richieste, seleziona **Rivedi policy**. 1. Esamina il riepilogo della policy, quindi seleziona **Crea policy**. **Nota** Se viene restituito l'errore `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consulta [Risolvi i problemi relativi ad Amazon Data Lifecycle Manager](dlm-troubleshooting.md) per ulteriori informazioni. ------ #### [ Command line ] Utilizza il [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)comando per creare una politica del ciclo di vita delle istantanee. Per `PolicyType`, specificare `EBS_SNAPSHOT_MANAGEMENT`. **Nota** Per semplificare la sintassi, negli esempi seguenti viene utilizzato un file JSON, `policyDetails.json`, che include i dettagli della policy. **Esempio 1: policy del ciclo di vita degli snapshot con due pianificazioni** In questo esempio viene creata una policy del ciclo di vita degli snapshot che crea snapshot di tutti i volumi che dispongono di una chiave di tag `costcenter` con il valore `115`. La policy include due orari. La prima pianificazione crea uno snapshot ogni giorno alle 03:00 UTC. La seconda pianificazione crea uno snapshot settimanale ogni venerdì alle 17:00 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 ``` Di seguito è riportato un esempio del file `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 } ]} ``` Se la richiesta ha esito positivo, il comando restituisce l'ID della policy appena creata. Di seguito è riportato un output di esempio. ``` { "PolicyId": "policy-0123456789abcdef0" } ``` **Esempio 2: Policy del ciclo di vita degli snapshot che si rivolge alle istanze e crea snapshot di un sottoinsieme di volumi di dati (non root)** Questo esempio illustra la creazione di una policy del ciclo di vita degli snapshot che crea set di snapshot a più volumi da istanze taggate con `code=production`. La policy include soltanto una pianificazione. La pianificazione non crea snapshot di volumi di dati taggati con `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 ``` Di seguito è riportato un esempio del file `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 } ]} ``` Se la richiesta ha esito positivo, il comando restituisce l'ID della policy appena creata. Di seguito è riportato un output di esempio. ``` { "PolicyId": "policy-0123456789abcdef0" } ``` **Esempio 3: politica del ciclo di vita delle istantanee che automatizza le istantanee locali delle risorse Outpost** Questo esempio crea una politica del ciclo di vita delle istantanee che crea istantanee dei volumi con cui sono etichettati tutti i tuoi. `team=dev` Outposts La policy crea le istantanee sugli stessi Outposts volumi di origine. La policy crea snapshot ogni `12` ore a partire dalle `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 ``` Di seguito è riportato un esempio del file `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 } ]} ``` **Esempio 4: politica del ciclo di vita delle istantanee che crea istantanee in una regione e le copia in una Outpost** La policy di esempio seguente crea snapshot dei volumi con tag `team=dev`. Gli snapshot vengono creati nella stessa Regione del volume di origine. Gli snapshot vengono creati ogni `12` ore a partire dalle `00:00` UTC. Viene conservato un massimo di `1` snapshot. La policy copia inoltre le istantanee in Outpost`arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0`, crittografa le istantanee copiate utilizzando la chiave KMS di crittografia predefinita e conserva le copie per un mese. `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 ``` Di seguito è riportato un esempio del file `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" } }] } ]} ``` **Esempio 5: policy del ciclo di vita degli snapshot con una pianificazione basata sull'età e abilitata all'archiviazione** In questo esempio viene creata una policy del ciclo di vita dei volumi di destinazioni con tag con `Name=Prod`. La policy ha una pianificazione basata sull'età che crea snapshot il primo giorno di ogni mese alle ore 09:00. La pianificazione mantiene ogni snapshot nel livello standard per un giorno, dopodiché lo sposta nel livello archivio. Gli snapshot vengono memorizzati nel livello archivio per 90 giorni prima di essere eliminati. ``` 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 ``` Di seguito è riportato un esempio del file `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" } ] } ``` **Esempio 6: policy del ciclo di vita degli snapshot con una pianificazione basata sul conteggio e abilitata all'archiviazione** In questo esempio viene creata una policy del ciclo di vita dei volumi di destinazioni con tag con `Purpose=Test`. La policy ha una pianificazione basata sul conteggio che crea snapshot il primo giorno di ogni mese alle ore 09:00. La pianificazione archivia gli snapshot subito dopo la creazione e mantiene max 3 snapshot nel livello archivio. ``` 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 ``` Di seguito è riportato un esempio del file `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" } ] } ``` ------ ## Considerazioni sulle policy del ciclo di vita degli snapshot Alle policy sul ciclo di vita degli snapshot si applicano le seguenti **considerazioni generali**: + Le policy del ciclo di vita degli snapshot riguardano solo le istanze o i volumi che si trovano nella stessa regione della policy. + La prima operazione di creazione dello snapshot inizia entro un'ora dall'ora di inizio specificata. Le successive operazioni di creazione di snapshot iniziano entro un'ora dall'orario pianificato. + Puoi creare più policy per supportare un volume o un'istanza. Ad esempio, se a un volume sono associati due tag, dove il tag *A* è il tag di destinazione della policy *A* per la creazione di uno snapshot ogni 12 ore e il tag *B* è il tag di destinazione della policy *B* per la creazione di uno snapshot ogni 24 ore, Amazon Data Lifecycle Manager crea snapshot in base alle pianificazioni di entrambe le policy. In alternativa, è possibile ottenere lo stesso risultato creando un'unica policy con più pianificazioni. Ad esempio, è possibile creare un'unica policy indirizzata solo al tag *A* e specificare due pianificazioni: una ogni 12 ore e una ogni 24 ore. + I tag delle risorse di destinazione fanno distinzione tra maiuscole e minuscole. + Se rimuovi i tag di destinazione di una policy, Sistema di gestione del ciclo di vita dei dati Amazon non gestirà più gli snapshot esistenti nel livello standard e nel livello archivio; se non sono più necessari, dovrai eliminarli manualmente. + Se si crea una policy indirizzata alle istanze di destinazione e i nuovi volumi vengono collegati all'istanza di destinazione dopo la creazione della policy, i volumi appena aggiunti vengono inclusi nel backup alla successiva esecuzione della policy. Sono inclusi tutti i volumi collegati all'istanza al momento dell'esecuzione della policy. + Se si crea una policy con una pianificazione basata su cronologia personalizzata che è configurata per creare solo uno snapshot, la policy non eliminerà automaticamente tale snapshot quando viene raggiunta la soglia di conservazione. Se non è più necessario, occorre eliminare manualmente lo snapshot. + Se crei una policy basata sull'età in cui il periodo di conservazione è più breve della frequenza di creazione, Sistema di gestione del ciclo di vita dei dati Amazon conserverà sempre l'ultimo snapshot fino alla creazione di quello successivo. Ad esempio, se una policy basata sull'età crea uno snapshot ogni mese con un periodo di conservazione di sette giorni, Sistema di gestione del ciclo di vita dei dati Amazon conserverà ogni snapshot per un mese anche se il periodo di conservazione è di sette giorni. All'**[archiviazione degli snapshot](snapshot-archive.md)** si applicano le considerazioni seguenti: + Puoi abilitare l'archiviazione degli snapshot solo per le policy degli snapshot per volumi di destinazione. + Puoi specificare una regola di archiviazione per una sola pianificazione per ogni policy. + Se usi la console, puoi abilitare l'archiviazione degli snapshot solo se la pianificazione ha una frequenza di creazione mensile o annuale, oppure se specifichi un'espressione cron con una frequenza di creazione di almeno 28 giorni. Se si utilizza l' AWS API o l' AWS CLI AWS SDK, è possibile abilitare l'archiviazione delle istantanee solo se la pianificazione ha un'espressione cron con una frequenza di creazione di almeno 28 giorni. + Il periodo di conservazione minimo nel livello archivio è 90 giorni. + Quando uno snapshot viene archiviato, viene convertito in uno snapshot completo quando viene spostato nel livello di archivio. Ciò potrebbe aumentare i costi di archiviazione degli snapshot. Per ulteriori informazioni, consulta [Prezzi e fatturazione per l'archiviazione degli snapshot di Amazon EBS](snapshot-archive-pricing.md). + Il ripristino rapido e la condivisione degli snapshot sono disattivati per gli snapshot quando vengono archiviati. + Se, nel caso di un anno bisestile, la regola di conservazione comporta un periodo di conservazione dell'archivio inferiore a 90 giorni, Amazon Data Lifecycle Manager garantisce che gli snapshot vengano mantenuti per un periodo minimo di 90 giorni. + Se archivi manualmente uno snapshot creato da Amazon Data Lifecycle Manager e lo snapshot rimane ancora archiviato quando viene raggiunta la soglia di conservazione della pianificazione, Amazon Data Lifecycle Manager non gestisce più tale snapshot. Tuttavia, se ripristini lo snapshot al livello standard prima che venga raggiunta la soglia di conservazione della pianificazione, la pianificazione continuerà a gestire lo snapshot secondo le regole di conservazione. + Se ripristini definitivamente o temporaneamente uno snapshot creato da Amazon Data Lifecycle Manager al livello standard e lo snapshot rimane ancora archiviato quando viene raggiunta la soglia di conservazione della pianificazione, Amazon Data Lifecycle Manager non gestisce più tale snapshot. Tuttavia, se archivi nuovamente lo snapshot prima che venga raggiunta la soglia di conservazione della pianificazione, la pianificazione eliminerà lo snapshot quando viene raggiunta la soglia di conservazione. + Gli snapshot archiviati da Amazon Data Lifecycle Manager vengono conteggiati nelle tue quote `Archived snapshots per volume` e `In-progress snapshot archives per account`. + Se una pianificazione non è in grado di archiviare una snapshot dopo nuovi tentativi per 24 ore, lo snapshot rimane nel livello standard e viene pianificato per l'eliminazione in base al tempo in cui sarebbe stata eliminata dal livello archivio. Ad esempio, se la pianificazione archivia snapshot per 120 giorni, gli snapshot rimangono nel livello standard per 120 giorni dopo l'archiviazione non riuscita prima dell'eliminazione definitiva. Per le pianificazioni basate sul conteggio, lo snapshot non viene conteggiato nel numero di conservazioni della pianificazione. + Gli snapshot devono essere archiviati nella stessa regione in cui sono stati creati. Se hai abilitato la copia e l'archiviazione di snapshot tra Regioni, Sistema di gestione del ciclo di vita dei dati Amazon non archivia copie dello snapshot. + Gli snapshot archiviati da Amazon Data Lifecycle Manager sono contrassegnati con il tag di sistema `aws:dlm:archived=true`. Inoltre, gli snapshot creati da una pianificazione basata sull'età e abilitata all'archiviazione sono contrassegnati con il tag di sistema `aws:dlm:expirationTime` indicante la data e l'ora in cui è pianificata l'archiviazione dello snapshot. Le considerazioni seguenti si applicano all'**esclusione di volumi root e di volumi di dati (non root)**: + Se scegli di escludere i volumi di avvio e specifichi tag che di conseguenza escludono tutti i volumi di dati aggiuntivi collegati a un'istanza, Amazon Data Lifecycle Manager non creerà alcuna istantanea per l'istanza interessata ed emetterà un parametro. `SnapshotsCreateFailed` CloudWatch Per ulteriori informazioni, consulta [Monitora le politiche utilizzando CloudWatch](monitor-dlm-cw-metrics.md). Le considerazioni seguenti si applicano all'**eliminazione di volumi o alla terminazione di istanze di destinazione delle policy del ciclo di vita degli snapshot**: + Se elimini un volume o termini un'istanza di destinazione di una policy con una pianificazione di conservazione basata sul conteggio, Amazon Data Lifecycle Manager non gestirà più gli snapshot nel livello standard e nel livello archivio che sono stati creati dall'istanza o dal volume eliminato. Se non sono più necessari, occorre annullare manualmente gli snapshot precedenti. + Se elimini un volume o termini un'istanza di destinazione di una policy con una pianificazione di conservazione basata sull'età, la policy continua a eliminare gli snapshot dal livello standard e dal livello archivio che sono stati creati dall'istanza o dal volume eliminato in base alla pianificazione definita, fino all'ultimo snapshot non incluso. Se non è più necessario, occorre eliminare manualmente l'ultimo snapshot. Le considerazioni seguenti si applicano alle policy del ciclo di vita degli snapshot e al ** [ripristino rapido degli snapshot](ebs-fast-snapshot-restore.md)**: + Amazon Data Lifecycle Manager può abilitare il ripristino rapido delle istantanee solo per istantanee di dimensioni pari o inferiori a 16 TiB. Per ulteriori informazioni, consulta [Ripristino rapido degli snapshot Amazon EBS](ebs-fast-snapshot-restore.md). + Uno snapshot che è abilitato per il ripristino rapido degli snapshot rimane abilitato anche se si elimina o si disabilita la policy, si disabilita il ripristino rapido degli snapshot per la policy o si disabilita il ripristino rapido degli snapshot per la zona di disponibilità. Il ripristino rapido degli snapshot per questi snapshot deve essere disabilitato manualmente. + Se si abilita il ripristino rapido degli snapshot per una policy e si supera il numero massimo di snapshot che possono essere abilitati per il ripristino rapido degli snapshot, Amazon Data Lifecycle Manager crea snapshot come pianificato ma non li abilita per il ripristino rapido degli snapshot. Dopo che uno snapshot che è stato abilitato per il ripristino rapido degli snapshot viene eliminato, lo snapshot successivo creato da Amazon Data Lifecycle Manager viene abilitato per il ripristino rapido degli snapshot. + Quando il ripristino rapido degli snapshot è abilitato per uno snapshot, sono necessari 60 minuti per consentire a TiB di ottimizzare lo snapshot. È consigliabile configurare le pianificazioni in modo che ogni snapshot sia completamente ottimizzato prima che Amazon Data Lifecycle Manager crei lo snapshot successivo. + Se abiliti il ripristino rapido delle istantanee per una policy destinata alle istanze, Amazon Data Lifecycle Manager abilita il ripristino rapido delle istantanee per ogni istantanea nella serie di istantanee a più volumi singolarmente. Se Amazon Data Lifecycle Manager non riesce ad abilitare il ripristino rapido delle istantanee per una delle istantanee della serie di istantanee multivolume, tenterà comunque di abilitare il ripristino rapido delle istantanee per le istantanee rimanenti nella serie di istantanee. + Viene fatturato ogni minuto in cui viene abilitato il ripristino rapido degli snapshot per uno snapshot in una determinata zona di disponibilità. Le tariffe sono proporzionalmente valutate con un minimo di un'ora. Per ulteriori informazioni, consulta [Prezzi e fatturazione](ebs-fast-snapshot-restore.md#fsr-pricing). **Nota** A seconda della configurazione delle policy del ciclo di vita, è possibile che siano abilitati più snapshot per il ripristino rapido degli snapshot in più zone di disponibilità contemporaneamente. Le considerazioni seguenti si applicano alle policy del ciclo di vita degli snapshot e ai ** volumi con l'abilitazione per gli [allegati multipli](ebs-volumes-multi.md) **: + Quando si crea una policy del ciclo di vita che si rivolge alle istanze con volumi con l'abilitazione per gli allegati multipli, Amazon Data Lifecycle Manager avvia uno snapshot del volume per ogni istanza allegata. Utilizzare il tag *timestamp* per identificare il set di snapshot costanti nel tempo creati dalle istanze allegate. Alla **condivisione degli snapshot tra account** si applicano le considerazioni seguenti: + È possibile condividere solo snapshot non crittografati o crittografati utilizzando una chiave gestita dal cliente. + Non è possibile condividere snapshot crittografati con la Chiave KMS di crittografia EBS predefinita. + Se si condividono snapshot crittografati, è necessario condividere con gli account di destinazione anche la Chiave KMS utilizzata per crittografare il volume di origine. Per ulteriori informazioni, consultare [Consentire agli utenti in altri account di utilizzare una chiave KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) nella *Guida per gli sviluppatori di AWS Key Management Service *. Le considerazioni seguenti si applicano alle policy degli snapshot e all'** [archivio degli snapshot](snapshot-archive.md)**: + Se si archivia manualmente uno snapshot creato da una policy e tale snapshot si trova nel livello di archiviazione quando viene raggiunta la soglia di conservazione della policy, Amazon Data Lifecycle Manager non eliminerà lo snapshot. Amazon Data Lifecycle Manager non gestisce gli snapshot mentre sono archiviati nel livello di archiviazione. Se non sono più necessari gli snapshot archiviati nel livello di archiviazione, è necessario eliminarli manualmente. [Le seguenti considerazioni si applicano alle policy relative alle istantanee e al Recycle Bin:](recycle-bin.md) + Se Amazon Data Lifecycle Manager elimina uno snapshot e lo invia al Cestino di riciclaggio quando viene raggiunta la soglia di conservazione della policy e si ripristina manualmente lo snapshot dal Cestino di riciclaggio, è necessario eliminare manualmente tale snapshot quando non è più necessario. Amazon Data Lifecycle Manager non gestirà più lo snapshot. + Se si elimina manualmente uno snapshot creato da una policy e tale snapshot si trova nel Cestino di riciclaggio quando viene raggiunta la soglia di conservazione della policy, Amazon Data Lifecycle Manager non eliminerà lo snapshot. Amazon Data Lifecycle Manager non gestisce gli snapshot mentre sono archiviati nel Cestino di riciclaggio Se lo snapshot viene ripristinato dal Cestino di riciclaggio prima che venga raggiunta la soglia di conservazione della policy, Amazon Data Lifecycle Manager eliminerà lo snapshot quando viene raggiunta la soglia di conservazione della policy. Se lo snapshot viene ripristinato dal Cestino di riciclaggio dopo che venga raggiunta la soglia di conservazione della policy, Amazon Data Lifecycle Manager non provvederà più ad eliminare lo snapshot. Lo snapshot che non è più necessario deve essere eliminato manualmente. Le seguenti considerazioni si applicano alle policy del ciclo di vita in stato **errore**: + Per le policy con pianificazioni di conservazione basate sull'età, gli snapshot impostati per la scadenza mentre la policy è in stato `error` vengono conservati indefinitamente. Questi snapshot dovranno essere eliminati manualmente. Quando riabiliti la policy, Amazon Data Lifecycle Manager riprende a eliminare gli snapshot quando scadono i relativi periodi di conservazione. + Per le policy con pianificazioni di conservazione basate sul conteggio, la policy interrompe la creazione e l'eliminazione degli snapshot mentre è in stato `error`. Quando riabiliti la policy, Amazon Data Lifecycle Manager riprende la creazione degli snapshot e riprende l'eliminazione degli snapshot al raggiungimento della soglia di conservazione. Le considerazioni seguenti si applicano alle policy degli snapshot e al **[blocco degli snapshot](ebs-snapshot-lock.md)**: + Se blocchi manualmente uno snapshot creato da Amazon Data Lifecycle Manager e lo snapshot rimane ancora bloccato quando viene raggiunta la soglia di conservazione, Amazon Data Lifecycle Manager non gestisce più tale snapshot. Se non è più necessario, occorre eliminare manualmente lo snapshot. + Se blocchi manualmente uno snapshot creato e abilitato per il ripristino rapido da Amazon Data Lifecycle Manager e lo snapshot rimane ancora bloccato quando viene raggiunta la soglia di conservazione, Amazon Data Lifecycle Manager non disabiliterà il ripristino rapido né eliminerà lo snapshot. Se non è più necessario, occorre disabilitare manualmente il ripristino rapido ed eliminare lo snapshot. + Se registri manualmente uno snapshot creato da Amazon Data Lifecycle Manager con un'AMI e quindi lo blocchi e lo snapshot rimane ancora bloccato e associato all'AMI quando viene raggiunta la soglia di conservazione, Amazon Data Lifecycle Manager continuerà a provarne l'eliminazione. Quando la registrazione dell'AMI viene annullata e lo snapshot viene sbloccato, Amazon Data Lifecycle Manager eliminerà automaticamente lo snapshot. ## Risorse aggiuntive Per ulteriori informazioni, consulta il blog [Automating Amazon EBS snapshot and AMI management using Amazon Data AWS Lifecycle Manager storage](https://aws.amazon.com/blogs/storage/automating-amazon-ebs-snapshot-and-ami-management-using-amazon-dlm/). # Automatizza le istantanee coerenti con le applicazioni con Data Lifecycle Manager È possibile utilizzare snapshot coerenti con l'applicazione con Amazon Data Lifecycle Manager abilitando gli script pre e post nelle tue policy del ciclo di vita degli snapshot che puntano alle istanze. Amazon Data Lifecycle Manager si integra con (Systems AWS Systems Manager Manager) per supportare istantanee coerenti con le applicazioni. Amazon Data Lifecycle Manager utilizza documenti di comando Systems Manager (SSM) che includono script pre e post per automatizzare le azioni necessarie per completare gli snapshot coerenti con l'applicazione. Prima che Amazon Data Lifecycle Manager inizi la creazione di snapshot, esegue i comandi del pre script per congelare e svuotare. I/O. After Amazon Data Lifecycle Manager initiates snapshot creation, it runs the commands in the post script to thaw I/O Utilizzando Amazon Data Lifecycle Manager, puoi automatizzare gli snapshot coerenti con l'applicazione di quanto segue: + Applicazioni Windows che utilizzano Volume Shadow Copy Service (VSS) + SAP HANA utilizza un documento SSDM gestito. AWS Per ulteriori informazioni, consulta [Snapshot Amazon EBS per SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/ebs-sap-hana.html). + Database autogestiti, come MySQL, PostgreSQL o IRIS, utilizzando modelli InterSystems di documenti SSM **Topics** + [ ## Requisiti per l'utilizzo di script pre e post ](#app-consistent-prereqs) + [ ## Guida introduttiva agli snapshot coerenti con l'applicazione ](#app-consistent-get-started) + [ ## Considerazioni per i backup VSS con Amazon Data Lifecycle Manager ](#app-consistent-vss) + [ ## Responsabilità condivisa per snapshot coerenti a livello di applicazione ](#shared-responsibility) ## Requisiti per l'utilizzo di script pre e post La tabella seguente riporta i requisiti per l'utilizzo di script pre e post con Amazon Data Lifecycle Manager. | | Snapshot coerenti a livello di applicazione | | | --- |--- |--- | | Requisito | Backup VSS | Documento SSM personalizzato | Altri casi d'uso | | --- |--- |--- |--- | | SSM Agent installato e funzionante sulle istanze di destinazione | ✓ | ✓ | ✓ | | Requisiti di sistema VSS soddisfatti sulle istanze di destinazione | ✓ | | | | Profilo di istanza abilitato a VSS associato alle istanze di destinazione | ✓ | | | | Componenti VSS installati sulle istanze di destinazione | ✓ | | | | Prepara il documento SSM con comandi pre e post script | | ✓ | ✓ | | Prepara il ruolo IAM di Amazon Data Lifecycle Manager, esegui prima e dopo gli script | ✓ | ✓ | ✓ | | Crea una policy di snapshot destinata alle istanze e configurata per gli script precedenti e successivi | ✓ | ✓ | ✓ | ## Guida introduttiva agli snapshot coerenti con l'applicazione Questa sezione spiega i passaggi da seguire per automatizzare le istantanee coerenti con le applicazioni utilizzando Amazon Data Lifecycle Manager. ### Fase 1: Preparazione delle istanze di destinazione È necessario preparare le istanze di destinazione per gli snapshot coerenti con l'applicazione utilizzando Amazon Data Lifecycle Manager. Completa una delle operazioni riportate di seguito, a seconda del caso d'uso. ------ #### [ Prepare for VSS Backups ] **Preparazione delle istanze di destinazione per i backup VSS** 1. Installa l'agente SSM sulle istanze di destinazione, se non è già installato. Se l'agente SSM è già installato sulle istanze di destinazione, salta questo passaggio. Per ulteriori informazioni, consulta [Working with SSM Agent on EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) Instances for Windows Server. 1. Assicurati che l'agente SSM sia in esecuzione. Per ulteriori informazioni, consulta [Verifica dello stato dell'agente SSM e avvio dell'agente](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html). 1. Configura Systems Manager per le istanze Amazon EC2. Per ulteriori informazioni, consulta [Configurazione di Systems Manager per le istanze Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) nella *Guida per l'utente di AWS Systems Manager *. 1. [Assicurati che i requisiti di sistema per i backup VSS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-prereqs.html) siano soddisfatti. 1. [Collega un profilo di istanza abilitato per VSS alle istanze di destinazione](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vss-iam-reqs.html). 1. [Installa i componenti VSS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-getting-started.html). ------ #### [ Prepare for SAP HANA backups ] **Preparazione delle istanze di destinazione per i backup SAP HANA** 1. Prepara l'ambiente SAP HANA sulle istanze di destinazione. 1. Configura la tua istanza con SAP HANA. Se non disponi già di un ambiente SAP HANA esistente, puoi fare riferimento a [Configurazione dell'ambiente SAP HANA su AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/std-sap-hana-environment-setup.html). 1. Accedi a SystemDB come utente amministratore adatto. 1. Crea un utente di backup del database da utilizzare con Amazon Data Lifecycle Manager. ``` CREATE USER username PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE; ``` Ad esempio, il seguente comando crea un utente denominato `dlm_user` con la password `password`. ``` CREATE USER dlm_user PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE; ``` 1. Assegna il ruolo `BACKUP OPERATOR` all'utente di backup del database creato nel passaggio precedente. ``` GRANT BACKUP OPERATOR TO username ``` Ad esempio, il comando seguente assegna il ruolo a un utente denominato`dlm_user`. ``` GRANT BACKUP OPERATOR TO dlm_user ``` 1. Accedi al sistema operativo come amministratore, ad esempio `sidadm`. 1. Crea una voce `hdbuserstore` per memorizzare le informazioni di connessione in modo che il documento SSM di SAP HANA possa connettersi a SAP HANA senza che gli utenti debbano inserire le informazioni. ``` hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:3hana_instance_number13 username password ``` Esempio: ``` hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:30013 dlm_user password ``` 1. Esegui il test della connessione. ``` hdbsql -U DLM_HANADB_SNAPSHOT_USER "select * from dummy" ``` 1. Installa l'agente SSM sulle istanze di destinazione, se non è già installato. Se l'agente SSM è già installato sulle istanze di destinazione, salta questo passaggio. Per ulteriori informazioni, consulta [Installazione manuale dell'agente SSM sulle istanze EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) per Linux. 1. Assicurati che l'agente SSM sia in esecuzione. Per ulteriori informazioni, consulta [Verifica dello stato dell'agente SSM e avvio dell'agente](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html). 1. Configura Systems Manager per le istanze Amazon EC2. Per ulteriori informazioni, consulta [Configurazione di Systems Manager per le istanze Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) nella *Guida per l'utente di AWS Systems Manager *. ------ #### [ Prepare for custom SSM documents ] **Preparazione dei documenti SSM personalizzati per le istanze di destinazione** 1. Installa l'agente SSM sulle istanze di destinazione, se non è già installato. Se l'agente SSM è già installato sulle istanze di destinazione, salta questo passaggio. + (Istanze Linux) [Installazione manuale dell'agente SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) su istanze EC2 per Linux + (Istanze Windows) [Utilizzo di SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) su istanze EC2 per Windows Server 1. Assicurati che l'agente SSM sia in esecuzione. Per ulteriori informazioni, consulta [Verifica dello stato dell'agente SSM e avvio dell'agente](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html). 1. Configura Systems Manager per le istanze Amazon EC2. Per ulteriori informazioni, consulta [Configurazione di Systems Manager per le istanze Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) nella *Guida per l'utente di AWS Systems Manager *. ------ ### Fase 2: Preparazione del documento SSM **Nota** Questo passaggio è necessario solo per i documenti SSM personalizzati. Non è richiesto per i backup VSS o SAP HANA. Per i backup VSS e SAP HANA, Amazon Data Lifecycle Manager utilizza il documento SSM gestito. AWS Se si stanno automatizzando istantanee coerenti con l'applicazione per un database autogestito, come MySQL, PostgreSQL o InterSystems IRIS, è necessario creare un documento di comando SSM che includa uno script pre da bloccare e svuotare prima dell'avvio della creazione dello snapshot e un post script da scongelare dopo l'avvio della creazione dello snapshot. I/O I/O Se il tuo database MySQL, PostgreSQL o IRIS utilizza configurazioni standard InterSystems , puoi creare un documento di comando SSM utilizzando il contenuto del documento SSM di esempio riportato di seguito. Se il database MySQL, PostgreSQL o IRIS utilizza una configurazione non standard InterSystems , è possibile utilizzare il contenuto di esempio riportato di seguito come punto di partenza per il documento di comando SSM e quindi personalizzarlo in base alle proprie esigenze. In alternativa, se desideri creare un nuovo documento SSM da zero, puoi utilizzare il modello di documenti SSM vuoto riportato di seguito e aggiungere i comandi pre e post nelle sezioni appropriate del documento. **Tenere presente quanto segue:** È tua responsabilità assicurarti che il documento SSM esegua le azioni corrette e necessarie per la configurazione del database. È garantito che gli snapshot siano coerenti con l'applicazione solo se gli script pre e post del documento SSM riescono a bloccare, svuotare e sbloccare l'I/O con successo. Il documento SSM deve includere i campi obbligatori per `allowedValues`, tra cui `pre-script`, `post-script` e `dry-run`. Amazon Data Lifecycle Manager eseguirà comandi sull'istanza in base al contenuto di tali sezioni. Se il documento SSM non contiene queste sezioni, Amazon Data Lifecycle Manager lo considererà un'esecuzione non riuscita. ------ #### [ 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 ``` [Per ulteriori informazioni, consulta il repository. GitHub ](https://github.com/intersystems-community/aws/blob/master/README.md) ------ #### [ Empty document template ] ``` ###===============================================================================### # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. # Permission is hereby granted, free of charge, to any person obtaining a copy of this # software and associated documentation files (the "Software"), to deal in the Software # without restriction, including without limitation the rights to use, copy, modify, # merge, publish, distribute, sublicense, and/or sell copies of the Software, and to # permit persons to whom the Software is furnished to do so. # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, # INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A # PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT # HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION # OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE # SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ###===============================================================================### schemaVersion: '2.2' description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature parameters: executionId: type: String default: None description: (Required) Specifies the unique identifier associated with a pre and/or post execution allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$ command: # Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution. # 'dry-run' option is intended for validating the document execution without triggering any commands # on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully # trigger pre and post script actions. type: String default: 'dry-run' description: (Required) Specifies whether pre-script and/or post-script should be executed. allowedValues: - pre-script - post-script - dry-run mainSteps: - action: aws:runShellScript description: Run Database freeze/thaw commands name: run_pre_post_scripts precondition: StringEquals: - platformType - Linux inputs: runCommand: - | #!/bin/bash ###===============================================================================### ### Error Codes ###===============================================================================### # The following Error codes will inform Data Lifecycle Manager of the type of error # and help guide handling of the error. # The Error code will also be emitted via AWS Eventbridge events in the 'cause' field. # 1 Pre-script failed during execution - 201 # 2 Post-script failed during execution - 202 # 3 Auto thaw occurred before post-script was initiated - 203 # 4 Pre-script initiated while post-script was expected - 204 # 5 Post-script initiated while pre-script was expected - 205 # 6 Application not ready for pre or post-script initiation - 206 ###===============================================================================### ### Global variables ###===============================================================================### START=$(date +%s) # For testing this script locally, replace the below with OPERATION=$1. OPERATION={{ command }} # Add all pre-script actions to be performed within the function below execute_pre_script() { echo "INFO: Start execution of pre-script" } # Add all post-script actions to be performed within the function below execute_post_script() { echo "INFO: Start execution of post-script" } # Debug logging for parameters passed to the SSM document echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}" # Based on the command parameter value execute the function that supports # pre-script/post-script operation case ${OPERATION} in pre-script) execute_pre_script ;; post-script) execute_post_script ;; dry-run) echo "INFO: dry-run option invoked - taking no action" ;; *) echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run." exit 1 # return failure ;; esac END=$(date +%s) # Debug Log for profiling the script time echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds." ``` ------ Una volta ottenuto il contenuto del documento SSM, utilizza una delle seguenti procedure per creare il documento SSM personalizzato. ------ #### [ Console ] **Creazione di un documento di comandi SSM** 1. Apri la AWS Systems Manager console all'indirizzo [https://console.aws.amazon.com//systems-manager/](https://console.aws.amazon.com//systems-manager/). 1. Nel pannello di navigazione, scegli **Documenti**, quindi scegli **Crea documento**, **Comando o Sessione**. 1. Per **Nome**, inserisci un nome descrittivo per il documento. 1. Per **Tipo di destinazione**, seleziona**/AWS::EC2::Instance**. 1. Per **Tipo di documento**, seleziona **Comando**. 1. Nel campo **Contenuto**, seleziona **YAML** e quindi incolla il contenuto del documento. 1. Nella sezione **Tag del documento**, aggiungi un tag con la chiave di tag `DLMScriptsAccess` e il valore di tag `true`. **Importante** Il `DLMScriptsAccess:true` tag è richiesto dalla policy AWS gestita di **AWSDataLifecycleManagerSSMFullaccesso** utilizzata nella *Fase 3: Preparazione del ruolo IAM di Amazon Data Lifecycle Manager*. La policy utilizza la chiave di condizione `aws:ResourceTag` per limitare l'accesso ai documenti SSM che hanno questo tag. 1. Scegli **Crea documento**. ------ #### [ AWS CLI ] **Creazione di un documento di comandi SSM** Usa il comando [create-document](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html). Per `--name`, digitare un nome descrittivo per il documento. Per `--document-type`, specificare `Command`. Per `--content`, specifica il percorso del file.yaml con il contenuto del documento SSM. Per `--tags`, specificare `"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" ``` ------ ### Fase 3: Preparazione del ruolo IAM di Amazon Data Lifecycle Manager **Nota** Questo passaggio è necessario se: Crei o aggiorni una policy di snapshot pre/post abilitata agli script che utilizza un ruolo IAM personalizzato. Si utilizza la riga di comando per creare o aggiornare una policy di snapshot pre/post abilitata agli script che utilizza quella predefinita. Se utilizzi la console per creare o aggiornare una politica di snapshot pre/post abilitata agli script che utilizza il ruolo predefinito per la gestione delle istantanee (), salta questo passaggio. **AWSDataLifecycleManagerDefaultRole** In questo caso, associamo automaticamente la politica di **AWSDataLifecycleManagerSSMFullaccesso** a quel ruolo. Devi assicurarti che il ruolo IAM che usi per le policy conceda ad Amazon Data Lifecycle Manager l'autorizzazione a eseguire le azioni SSM necessarie per eseguire gli script pre e post sulle istanze oggetto della policy. Amazon Data Lifecycle Manager fornisce una policy gestita (**AWSDataLifecycleManagerSSMFullAccess**) che include le autorizzazioni richieste. Puoi collegare questa policy al tuo ruolo IAM per la gestione degli snapshot per assicurarti che includa le autorizzazioni. **Importante** La policy gestita di AWSData LifecycleManager SSMFull Access utilizza la chiave di `aws:ResourceTag` condizione per limitare l'accesso a documenti SSM specifici quando si utilizzano script pre e post. Per consentire ad Amazon Data Lifecycle Manager di accedere ai documenti SSM, devi assicurarti che i tuoi documenti SSM siano etichettati con `DLMScriptsAccess:true`. In alternativa, puoi creare manualmente una policy personalizzata o assegnare le autorizzazioni richieste direttamente al ruolo IAM utilizzato. È possibile utilizzare le stesse autorizzazioni definite nella politica gestita di AWSData LifecycleManager SSMFull Access, tuttavia la chiave di `aws:ResourceTag` condizione è facoltativa. Se decidi di non utilizzare quella chiave di condizione, non è necessario etichettare i documenti SSM con `DLMScriptsAccess:true`. Utilizza uno dei seguenti metodi per aggiungere la policy di **AWSDataLifecycleManagerSSMFullaccesso** al tuo ruolo IAM. ------ #### [ Console ] **Collegamento della policy gestita al ruolo personalizzato** 1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Nel riquadro di navigazione, selezionare **Ruoli**. 1. Cerca e seleziona il tuo ruolo personalizzato per la gestione degli snapshot. 1. Nella scheda **Autorizzazioni**, scegli **Aggiungi autorizzazioni**, quindi **Collega policy**. 1. Cerca e seleziona la policy gestita di **AWSDataLifecycleManagerSSMFullAccess**, quindi scegli **Aggiungi autorizzazioni**. ------ #### [ AWS CLI ] **Collegamento della policy gestita al ruolo personalizzato** Utilizza il comando [ attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Per `---role-name`, specifica il nome del tuo ruolo personalizzato. Per `--policy-arn`, specificare `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess`. ``` $ aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \ --role-name your_role_name ``` ------ ### Fase 4: Creazione di una policy del ciclo di vita dello snapshot Per automatizzare gli snapshot coerenti con l'applicazione, è necessario creare una policy del ciclo di vita degli snapshot destinata alle istanze e configurare gli script pre e post per tale policy. ------ #### [ Console ] **Creazione di una policy del ciclo di vita dello snapshot** 1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Nel riquadro di navigazione, scegliere **Elastic Block Store**, **Lifecycle Manager**, quindi selezionare **Create lifecycle policy (Crea policy del ciclo di vita)**. 1. Nella schermata **Seleziona il tipo di policy**, seleziona **Policy di snapshot EBS** e quindi **Successivo**. 1. Nella sezione **Risorse di destinazione**, procedere come segue: 1. Per **Tipi di risorse di destinazione**, scegli `Instance`. 1. Per **Tag delle risorse interessate**, specifica i tag delle risorse che identificano le istanze di cui eseguire il backup. Verrà eseguito il backup solo delle risorse con i tag specificati. 1. Per il **ruolo IAM**, scegli **AWSDataLifecycleManagerDefaultRole**(il ruolo predefinito per la gestione delle istantanee) o scegli un ruolo personalizzato che hai creato e preparato per la fase precedente e successiva agli script. 1. Configura le pianificazioni e le opzioni aggiuntive in base alla necessità. Si consiglia di pianificare gli orari di creazione degli snapshot per periodi di tempo corrispondenti al carico di lavoro, ad esempio durante le finestre di manutenzione. Per SAP HANA, si consiglia di abilitare il ripristino rapido degli snapshot. **Nota** Se abiliti una pianificazione per i backup VSS, non puoi abilitare **Escludi volumi di dati specifici** o **Copia tag dall'origine**. 1. Nella sezione **Script pre e post**, seleziona **Abilita script pre e post**, quindi procedi come segue, a seconda del carico di lavoro: + Per creare snapshot coerenti con l'applicazione delle applicazioni Windows, seleziona **Backup VSS**. + Per creare snapshot coerenti con l'applicazione dei carichi di lavoro SAP HANA, seleziona **SAP HANA**. + **Per creare istantanee coerenti con l'applicazione di tutti gli altri database e carichi di lavoro, inclusi i database MySQL, PostgreSQL o IRIS autogestiti, utilizzando un documento SSM personalizzato, seleziona Documento SSM personalizzato. InterSystems ** 1. Per l'**Opzione Automatizza**, scegli **Script pre e post**. 1. Per **Documento SSM**, seleziona il documento SSM che hai preparato. 1. A seconda dell'opzione selezionata, configura le seguenti opzioni aggiuntive: + **Timeout dello script**: (*solo documento SSM personalizzato*) il periodo di timeout dopo il quale Amazon Data Lifecycle Manager fallisce il tentativo di esecuzione dello script se non è stato completato. Se uno script non viene completato entro il periodo di timeout, Amazon Data Lifecycle Manager fallisce il tentativo. Il periodo di timeout si applica ai singoli script pre e post. Il periodo di timeout minimo e predefinito è 10 secondi. E il periodo massimo di timeout è di 120 secondi. + **Riprova gli script non riusciti**: seleziona questa opzione per riprovare gli script che non vengono completati entro il periodo di timeout. Se lo script preliminare fallisce, Amazon Data Lifecycle Manager riprova l'intero processo di creazione degli snapshot, inclusa l'esecuzione degli script pre e post. Se lo script post fallisce, Amazon Data Lifecycle Manager riprova solo lo script post; in questo caso, lo script pre sarà completato e lo snapshot potrebbe essere stato creato. + **Predefinito su snapshot crash-consistent**: seleziona questa opzione per impostare come impostazione predefinita gli snapshot crash-consistent se lo script pre non viene eseguito. Questo è il comportamento di creazione di snapshot predefinito per Amazon Data Lifecycle Manager se gli script pre e post non sono abilitati. Se hai abilitato i nuovi tentativi, Amazon Data Lifecycle Manager utilizzerà per impostazione predefinita gli snapshot crash-consistent solo dopo aver esaurito tutti i tentativi. Se lo script pre non riesce e per impostazione predefinita non utilizzi snapshot crash-consistent, Amazon Data Lifecycle Manager non creerà gli snapshot per l'istanza durante l'esecuzione della pianificazione. **Nota** Se stai creando snapshot per SAP HANA, potresti voler disabilitare questa opzione. Gli snapshot crash-consistent dei carichi di lavoro SAP HANA non possono essere ripristinati nello stesso modo. 1. Scegli **Crea policy predefinita**. **Nota** Se viene restituito l'errore `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consulta [Risolvi i problemi relativi ad Amazon Data Lifecycle Manager](dlm-troubleshooting.md) per ulteriori informazioni. ------ #### [ AWS CLI ] **Creazione di una policy del ciclo di vita dello snapshot** [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)Usa il `Scripts` `CreateRule` comando e includi i parametri in. Per ulteriori informazioni sui parametri, consulta 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 ``` Dove `policyDetails.json` include una delle seguenti operazioni, a seconda del caso d'uso: + **Backup 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 } }] } ``` + **Backup di 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 } }] } ``` + **Documento SSM personalizzato** ``` { "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 } }] } ``` ------ ## Considerazioni per i backup VSS con Amazon Data Lifecycle Manager Con Amazon Data Lifecycle Manager, puoi eseguire il backup e il ripristino di applicazioni Windows abilitate per VSS (Volume Shadow Copy Service) in esecuzione su istanze Amazon EC2. Se un VSS writer è registrato con Windows VSS nell'applicazione, allora il Sistema di gestione del ciclo di vita dei dati Amazon crea uno snapshot che sarà coerente per tale applicazione. **Nota** Attualmente, Amazon Data Lifecycle Manager supporta solo backup coerenti con l'applicazione delle risorse in esecuzione su Amazon EC2, in particolare scenari di backup in cui i dati delle applicazioni possono essere ripristinati sostituendo un'istanza esistente con una nuova istanza creata dal backup. Non tutti i tipi di istanze o applicazioni sono supportati per i backup di Windows VSS. *Per ulteriori informazioni, consulta gli [snapshot Windows VSS coerenti con le applicazioni nella Guida per l'](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html)utente di Amazon EC2.* **Tipi di istanze non supportati** I seguenti tipi di istanza Amazon EC2 non sono supportati per i backup VSS. Se la tua policy si rivolge a uno di questi tipi di istanze, Amazon Data Lifecycle Manager potrebbe comunque creare backup VSS, ma gli snapshot potrebbero non essere taggati con i tag di sistema richiesti. Senza questi tag, gli snapshot non saranno gestiti da Amazon Data Lifecycle Manager dopo la creazione. Questi snapshot dovranno essere eliminati manualmente. + T3: `t3.nano` \$1 `t3.micro` + T3a: `t3a.nano` \$1 `t3a.micro` + T2: `t2.nano` \$1 `t2.micro` ## Responsabilità condivisa per snapshot coerenti a livello di applicazione **È necessario assicurarsi che:** + L'agente SSM è installato e in esecuzione sulle istanze di destinazione up-to-date + Systems Manager disponga delle autorizzazioni per effettuare le operazioni richieste sulle istanze di destinazione + Amazon Data Lifecycle Manager abbia l'autorizzazione a eseguire le azioni di Systems Manager necessarie per eseguire gli script pre e post sulle istanze di destinazione. + Per i carichi di lavoro personalizzati, come i database MySQL, PostgreSQL o InterSystems IRIS autogestiti, il documento SSM che usi include le azioni corrette e necessarie per il congelamento, lo svuotamento e lo scongelamento per la configurazione del database. I/O + I tempi di creazione degli snapshot si allineano alla pianificazione del carico di lavoro. Ad esempio, prova a pianificare la creazione di snapshot durante le finestre di manutenzione pianificata. **Amazon Data Lifecycle Manager garantisce che:** + La creazione degli snapshot viene avviata entro 60 minuti dall'ora pianificata per la creazione dello snapshot. + Gli script pre vengono eseguiti prima dell'avvio della creazione dello snapshot. + Gli script post vengono eseguiti dopo il completamento dello script pre e l'avvio della creazione dello snapshot. Amazon Data Lifecycle Manager esegue lo script post solo se lo script pre ha esito positivo. Se lo script pre fallisce, Amazon Data Lifecycle Manager non eseguirà lo script post. + Gli snapshot vengono taggati con i tag appropriati al momento della creazione. + CloudWatch le metriche e gli eventi vengono emessi quando gli script vengono avviati e quando hanno esito negativo o hanno esito positivo. # Altri casi d'uso degli script pre e post di Data Lifecycle Manager Oltre a utilizzare script pre e post per automatizzare gli snapshot coerenti con le applicazioni, è possibile utilizzarli insieme o singolarmente per automatizzare altre attività amministrative prima o dopo la creazione degli snapshot. Esempio: + Mediante uno script pre per applicare le patch prima di creare gli snapshot. Questo può aiutarti a creare snapshot dopo aver applicato i regolari aggiornamenti software settimanali o mensili. **Nota** Se decidi di eseguire solo uno script pre, l'opzione **Predefinito su snapshot crash-consistent** è abilitata per impostazione predefinita. + Mediante uno script post per applicare le patch prima di creare gli snapshot. Questo può aiutarti a creare snapshot prima di applicare i regolari aggiornamenti software settimanali o mensili. ## Guida introduttiva per altri casi d'uso Questa sezione spiega i passaggi da eseguire quando si utilizzano script pre and/or post per **casi d'uso diversi** dagli snapshot coerenti con l'applicazione. ### Fase 1: Preparazione delle istanze di destinazione **Per preparare le istanze di destinazione per gli script pre post and/or** 1. Installa l'agente SSM sulle istanze di destinazione, se non è già installato. Se l'agente SSM è già installato sulle istanze di destinazione, salta questo passaggio. + (Istanze Linux) [Installazione manuale di SSM Agent su](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) istanze EC2 per Linux + (Istanze Windows) [Utilizzo di SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) su istanze EC2 per Windows Server 1. Assicurati che l'agente SSM sia in esecuzione. Per ulteriori informazioni, consulta [Verifica dello stato dell'agente SSM e avvio dell'agente](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html). 1. Configura Systems Manager per le istanze Amazon EC2. Per ulteriori informazioni, consulta [Configurazione di Systems Manager per le istanze Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) nella *Guida per l'utente di AWS Systems Manager *. ### Fase 2: Preparazione del documento SSM È necessario creare un documento di comando SSM che includa gli script pre and/or post con i comandi che si desidera eseguire. È possibile creare un documento SSM utilizzando il modello di documenti SSM vuoto riportato di seguito e aggiungendo i comandi degli script pre e post nelle sezioni appropriate del documento. **Tenere presente quanto segue:** È tua responsabilità assicurarti che il documento SSM esegua le azioni corrette e necessarie per il carico di lavoro. Il documento SSM deve includere i campi obbligatori per `allowedValues`, tra cui `pre-script`, `post-script` e `dry-run`. Amazon Data Lifecycle Manager eseguirà comandi sull'istanza in base al contenuto di tali sezioni. Se il documento SSM non contiene queste sezioni, Amazon Data Lifecycle Manager lo considererà un'esecuzione non riuscita. ``` ###===============================================================================### # 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." ``` ### Fase 3: Preparazione del ruolo IAM di Amazon Data Lifecycle Manager **Nota** Questo passaggio è necessario se: Crei o aggiorni una policy di snapshot pre/post abilitata agli script che utilizza un ruolo IAM personalizzato. Si utilizza la riga di comando per creare o aggiornare una policy di snapshot pre/post abilitata agli script che utilizza quella predefinita. Se utilizzi la console per creare o aggiornare una politica di snapshot pre/post abilitata agli script che utilizza il ruolo predefinito per la gestione delle istantanee (), salta questo passaggio. **AWSDataLifecycleManagerDefaultRole** In questo caso, associamo automaticamente la politica di **AWSDataLifecycleManagerSSMFullaccesso** a quel ruolo. Devi assicurarti che il ruolo IAM che usi per le policy conceda ad Amazon Data Lifecycle Manager l'autorizzazione a eseguire le azioni SSM necessarie per eseguire gli script pre e post sulle istanze oggetto della policy. Amazon Data Lifecycle Manager fornisce una policy gestita (**AWSDataLifecycleManagerSSMFullAccess**) che include le autorizzazioni richieste. Puoi collegare questa policy al tuo ruolo IAM per la gestione degli snapshot per assicurarti che includa le autorizzazioni. **Importante** La policy gestita di AWSData LifecycleManager SSMFull Access utilizza la chiave di `aws:ResourceTag` condizione per limitare l'accesso a documenti SSM specifici quando si utilizzano script pre e post. Per consentire ad Amazon Data Lifecycle Manager di accedere ai documenti SSM, devi assicurarti che i tuoi documenti SSM siano etichettati con `DLMScriptsAccess:true`. In alternativa, puoi creare manualmente una policy personalizzata o assegnare le autorizzazioni richieste direttamente al ruolo IAM utilizzato. È possibile utilizzare le stesse autorizzazioni definite nella politica gestita di AWSData LifecycleManager SSMFull Access, tuttavia la chiave di `aws:ResourceTag` condizione è facoltativa. Se decidi di non utilizzare quella chiave di condizione, non è necessario etichettare i documenti SSM con `DLMScriptsAccess:true`. Utilizza uno dei seguenti metodi per aggiungere la policy di **AWSDataLifecycleManagerSSMFullaccesso** al tuo ruolo IAM. ------ #### [ Console ] **Collegamento della policy gestita al ruolo personalizzato** 1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Nel riquadro di navigazione, selezionare **Ruoli**. 1. Cerca e seleziona il tuo ruolo personalizzato per la gestione degli snapshot. 1. Nella scheda **Autorizzazioni**, scegli **Aggiungi autorizzazioni**, quindi **Collega policy**. 1. Cerca e seleziona la policy gestita di **AWSDataLifecycleManagerSSMFullAccess**, quindi scegli **Aggiungi autorizzazioni**. ------ #### [ AWS CLI ] **Collegamento della policy gestita al ruolo personalizzato** Utilizza il comando [ attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Per `---role-name`, specifica il nome del tuo ruolo personalizzato. Per `--policy-arn`, specificare `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess`. ``` $ aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \ --role-name your_role_name ``` ------ ### Creazione di una policy del ciclo di vita dello snapshot ------ #### [ Console ] **Creazione di una policy del ciclo di vita dello snapshot** 1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Nel riquadro di navigazione, scegliere **Elastic Block Store**, **Lifecycle Manager**, quindi selezionare **Create lifecycle policy (Crea policy del ciclo di vita)**. 1. Nella schermata **Seleziona il tipo di policy**, seleziona **Policy di snapshot EBS** e quindi **Successivo**. 1. Nella sezione **Risorse di destinazione**, procedere come segue: 1. Per **Tipi di risorse di destinazione**, scegli `Instance`. 1. Per **Tag delle risorse interessate**, specifica i tag delle risorse che identificano le istanze di cui eseguire il backup. Verrà eseguito il backup solo delle risorse con i tag specificati. 1. Per il **ruolo IAM**, scegli **AWSDataLifecycleManagerDefaultRole**(il ruolo predefinito per la gestione delle istantanee) o scegli un ruolo personalizzato che hai creato e preparato per la fase precedente e successiva agli script. 1. Configura le pianificazioni e le opzioni aggiuntive in base alla necessità. Si consiglia di pianificare gli orari di creazione degli snapshot per periodi di tempo corrispondenti al carico di lavoro, ad esempio durante le finestre di manutenzione. 1. Nella sezione **Script pre e post**, seleziona **Abilita script pre e post**, quindi procedi come segue: 1. Seleziona **Documento SSM personalizzato**. 1. Per **Opzione Automatizza**, scegli l'opzione che corrisponde agli script che desideri eseguire. 1. Per **Documento SSM**, seleziona il documento SSM che hai preparato. 1. Configura le seguenti opzioni aggiuntive, se necessario: + **Timeout dello script**: il periodo di timeout dopo il quale Amazon Data Lifecycle Manager fallisce il tentativo di esecuzione dello script se non è stato completato. Se uno script non viene completato entro il periodo di timeout, Amazon Data Lifecycle Manager fallisce il tentativo. Il periodo di timeout si applica ai singoli script pre e post. Il periodo di timeout minimo e predefinito è 10 secondi. E il periodo massimo di timeout è di 120 secondi. + **Riprova gli script non riusciti**: seleziona questa opzione per riprovare gli script che non vengono completati entro il periodo di timeout. Se lo script preliminare fallisce, Amazon Data Lifecycle Manager riprova l'intero processo di creazione degli snapshot, inclusa l'esecuzione degli script pre e post. Se lo script post fallisce, Amazon Data Lifecycle Manager riprova solo lo script post; in questo caso, lo script pre sarà completato e lo snapshot potrebbe essere stato creato. + **Predefinito su snapshot crash-consistent**: seleziona questa opzione per impostare come impostazione predefinita gli snapshot crash-consistent se lo script pre non viene eseguito. Questo è il comportamento di creazione di snapshot predefinito per Amazon Data Lifecycle Manager se gli script pre e post non sono abilitati. Se hai abilitato i nuovi tentativi, Amazon Data Lifecycle Manager utilizzerà per impostazione predefinita gli snapshot crash-consistent solo dopo aver esaurito tutti i tentativi. Se lo script pre non riesce e per impostazione predefinita non utilizzi snapshot crash-consistent, Amazon Data Lifecycle Manager non creerà gli snapshot per l'istanza durante l'esecuzione della pianificazione. 1. Scegli **Crea policy predefinita**. **Nota** Se viene restituito l'errore `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consulta [Risolvi i problemi relativi ad Amazon Data Lifecycle Manager](dlm-troubleshooting.md) per ulteriori informazioni. ------ #### [ AWS CLI ] **Creazione di una policy del ciclo di vita dello snapshot** Usa il [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)comando e includi i `Scripts` parametri in. `CreateRule` Per ulteriori informazioni sui parametri, consulta 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 ``` Dove `policyDetails.json` include quanto segue. ``` { "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 } }] } ``` ------ # Come funzionano gli script pre e post di Amazon Data Lifecycle Manager L'immagine seguente mostra il flusso di processo per gli script pre e post quando si utilizzano documenti SSM personalizzati. Non si applica ai backup VSS. ![\[Flusso di elaborazione degli script pre e post di Amazon Data Lifecycle Manager\]](http://docs.aws.amazon.com/it_it/ebs/latest/userguide/images/dlm-scripts.png) Al momento della creazione pianificata dello snapshot, si verificano le seguenti azioni e interazioni tra servizi. 1. Amazon Data Lifecycle Manager avvia l'azione dello script pre richiamando il documento SSM e passando il parametro `pre-script`. **Nota** I passaggi da 1 a 3 si verificano solo se esegui script pre. Se si eseguono solo script post, i passaggi da 1 a 3 vengono ignorati. 1. Systems Manager invia comandi degli script pre all'agente SSM in esecuzione sulle istanze di destinazione. L'agente SSM esegue i comandi sull'istanza e invia le informazioni sullo stato a Systems Manager. Ad esempio, se il documento SSM viene utilizzato per creare istantanee coerenti con l'applicazione, lo script preliminare potrebbe bloccarsi e svuotarsi per garantire che tutti i dati memorizzati nel buffer vengano I/O scritti sul volume prima dell'acquisizione dell'istantanea. 1. Systems Manager invia aggiornamenti sullo stato dei comandi dello script pre ad Amazon Data Lifecycle Manager. Se lo script pre non riesce, Amazon Data Lifecycle Manager richiede una delle seguenti azioni, a seconda di come configuri le opzioni degli script pre e post: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/ebs/latest/userguide/script-flow.html) 1. Amazon Data Lifecycle Manager avvia la creazione di snapshot. 1. Amazon Data Lifecycle Manager avvia l'azione dello script post richiamando il documento SSM e passando il parametro `post-script`. **Nota** I passaggi da 5 a 7 si verificano solo se esegui script pre. Se si eseguono solo script post, i passaggi da 1 a 3 vengono ignorati. 1. Systems Manager invia comandi degli script post all'agente SSM in esecuzione sulle istanze di destinazione. L'agente SSM esegue i comandi sull'istanza e invia le informazioni sullo stato a Systems Manager. Ad esempio, se il documento SSM abilita istantanee coerenti con l'applicazione, questo post script potrebbe scongelarsi per garantire che i database riprendano le normali operazioni di I/O dopo l'acquisizione I/O dell'istantanea. 1. Se si esegue uno script post e Systems Manager indica che è stato completato correttamente, il processo viene completato. Se lo script post non riesce, Amazon Data Lifecycle Manager richiede una delle seguenti azioni, a seconda di come configuri le opzioni degli script pre e post: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/ebs/latest/userguide/script-flow.html) Tieni presente che se lo script post non riesce, lo script pre (se abilitato) sarà completato con successo e gli snapshot potrebbero essere state creati. Potrebbe essere necessario intraprendere ulteriori azioni sull'istanza per garantire che funzioni come previsto. Ad esempio se il prescript è stato messo in pausa e poi svuotato. 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. Il processo di creazione degli snapshot potrebbe essere completato dopo il completamento dello script post. Il tempo necessario per completare lo snapshot dipende dalla dimensione dello snapshot. # Identifica le istantanee create con gli script precedenti e successivi a quelli di Data Lifecycle Manager Amazon Data Lifecycle Manager assegna automaticamente i seguenti tag di sistema agli snapshot creati con script pre e post. + Chiave: `aws:dlm:pre-script`; valore: `SUCCESS`\$1`FAILED` Un valore del tag pari a `SUCCESS` indica che lo script pre è stato eseguito correttamente. Un valore del tag pari a `FAILED` indica che lo script pre non è stato eseguito correttamente. + Chiave: `aws:dlm:post-script`; valore: `SUCCESS`\$1`FAILED` Un valore del tag pari a `SUCCESS` indica che lo script post è stato eseguito correttamente. Un valore del tag pari a `FAILED` indica che lo script post non è stato eseguito correttamente. Per i documenti SSM personalizzati e i backup SAP HANA, è possibile dedurre che la creazione di snapshot coerenti con le applicazioni sia riuscita se lo snapshot è taggato sia con `aws:dlm:pre-script:SUCCESS` che con `aws:dlm:post-script:SUCCESS`. Inoltre, gli snapshot coerenti con le applicazioni creati utilizzando il backup VSS vengono taggati automaticamente con: + Chiave: `AppConsistent tag`; valore: `true`\$1`false` Un valore di tag pari a `true` indica che il backup VSS è stato eseguito correttamente e che gli snapshot sono coerenti a livello di applicazione. Un valore di tag pari a `false` indica che il backup VSS non è stato eseguito correttamente e che gli snapshot non sono coerenti a livello di applicazione. # Monitora Amazon Data Lifecycle Manager prima e dopo gli script **CloudWatch Metriche Amazon** Amazon Data Lifecycle Manager pubblica le seguenti CloudWatch metriche quando gli script precedenti e successivi hanno esito negativo e hanno esito positivo e quando i backup VSS falliscono e hanno esito positivo. + `PreScriptStarted` + `PreScriptCompleted` + `PreScriptFailed` + `PostScriptStarted` + `PostScriptCompleted` + `PostScriptFailed` + `VSSBackupStarted` + `VSSBackupCompleted` + `VSSBackupFailed` Per ulteriori informazioni, consulta [Monitora le policy di Data Lifecycle Manager utilizzando CloudWatch](monitor-dlm-cw-metrics.md). **Amazon EventBridge** Amazon Data Lifecycle Manager emette il seguente evento EventBridge Amazon quando uno script precedente o successivo viene avviato, ha esito positivo o negativo + `DLM Pre Post Script Notification` Per ulteriori informazioni, consulta [Monitora le policy di Data Lifecycle Manager utilizzando EventBridge](monitor-cloudwatch-events.md).