As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Criar política padrão do Amazon Data Lifecycle Manager para snapshots O procedimento a seguir mostra como usar o Amazon Data Lifecycle Manager para automatizar os ciclos de vida de snapshots do Amazon EBS. **Topics** + [Criar uma política de ciclo de vida de snapshots](#create-snap-policy) + [Considerações sobre políticas de ciclo de vida de snapshots](#snapshot-considerations) + [Recursos adicionais do](#snapshot-additional-resources) + [Automatizar snapshots consistentes com a aplicação](automate-app-consistent-backups.md) + [Outros casos de uso para scripts prévios e posteriores](script-other-use-cases.md) + [Como funcionam os scripts prévios e posteriores](script-flow.md) + [Identificar snapshots criados com pré-scripts e pós-scripts](dlm-script-tags.md) + [Monitorar pré-scripts e pós-scripts](dlm-script-monitoring.md) ## Criar uma política de ciclo de vida de snapshots Use um dos procedimentos a seguir para criar uma política de ciclo de vida de snapshots. ------ #### [ Console ] **Para criar uma política de snapshot** 1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. No painel de navegação, selecione **Elastic Block Store**, **Lifecycle Manager** ((Gerenciador de ciclo de vida) e **Create snapshot lifecycle policy** (Criar política de ciclo de vida de snapshot). 1. Na tela **Select policy type** (Selecionar tipo de política), escolha **EBS snapshot policy** (Política de snapshot do EBS) e depois **Next** (Próximo). 1. Na seção **Target resources** (Recursos de destino), faça o seguinte: 1. Em **Target resource types**, (Tipos de recurso de destino), escolha o tipo de recurso para backup. Escolha `Volume` (Volume) para criar snapshots de volumes individuais ou `Instance` (Instância) para criar snapshots multivolume dos volumes associados a uma instância. 1. (*Apenas para clientes do Outpost e zonas locais*) Especifique onde os recursos-alvo estão localizados. Para **Local dos recursos-alvo**, especifique onde os recursos-alvo estão localizados. + Para direcionar recursos em uma região, escolha **Região da AWS **. O Amazon Data Lifecycle Manager fará backup de todos os recursos do tipo especificado que têm etiquetas de destino correspondentes somente na região atual. Os snapshots são criados na mesma região. + Para direcionar recursos em zonas locais, escolha **Zonas locais da AWS **. O Amazon Data Lifecycle Manager fará backup de todos os recursos do tipo especificado que têm etiquetas de destino correspondentes em todas as zonas locais apenas na região atual. Os snapshots podem ser criados na mesma zona local do recurso de origem ou em sua região principal. + Para direcionar recursos para um Outpost, selecione **AWS Outpost**. O Amazon Data Lifecycle Manager fará backup de todos os recursos do tipo especificado que tenham etiquetas de destino correspondentes em todos os Outposts em sua conta. Os snapshots podem ser criados no mesmo Outpost que o recurso de origem ou em sua região principal. 1. Em **Target with these tags** (Destino com essas etiquetas), escolha as etiquetas de recurso que identificam os volumes ou as instâncias dos quais fazer backup. A política só oferece suporte aos recursos com a chave de tag e os pares de valor especificados. 1. Para **Description** (Descrição), insira uma breve descrição da rota. 1. Em **IAM role** (Função do IAM), selecione a função do IAM que tem permissões para gerenciar snapshots e para descrever volumes e instâncias. Para usar a função padrão fornecida pelo Amazon Data Lifecycle Manager, escolha **Default role** (Função padrão). Se preferir, para usar uma função do IAM personalizada criada anteriormente, selecione **Choose another role** (Escolher outra função) e selecione a função a ser usada. 1. Em **Policy tags** (Etiquetas de políticas), adicione as etiquetas a serem aplicadas na política de ciclo de vida. É possível usar essas etiquetas para identificar e categorizar suas políticas. 1. Em **Policy status** (Status da política), selecione **Enable** (Habilitar) para iniciar as execuções da política no próximo horário agendado ou **Disable policy** (Desabilitar política) para impedir que a política seja executada. Se você não habilitar a política agora, ela não começará a criar snapshots até que você a ative manualmente após a criação. 1. (*Políticas que têm apenas instâncias como alvo*) Excluir volumes de conjuntos de snapshots de vários volumes. Por padrão, o Amazon Data Lifecycle Manager criará snapshots de todos os volumes anexados às instâncias-alvo. Porém, você pode optar por criar snapshots de um subconjunto dos volumes anexados. Na seção **Parameters** (Parâmetros), faça o seguinte: + Se não quiser criar snapshots dos volumes raiz anexados às instâncias de destino, selecione **Exclude root volume** (Excluir volume raiz). Se você selecionar essa opção, apenas os volumes de dados (não raiz) anexados às instâncias de destino serão incluídos nos conjuntos de snapshots de vários volumes. + Para criar snapshots de um subconjunto dos volumes de dados (não raiz) anexados às instâncias de destino, selecione **Exclude specific data volumes** (Excluir volumes de dados específicos) e especifique as etiquetas a serem usadas para identificar os volumes de dados que não deverão ser capturados. O Amazon Data Lifecycle Manager não criará snapshots de volumes de dados que contenham qualquer uma das etiquetas especificadas. O Amazon Data Lifecycle Manager criará snapshots apenas de volumes de dados que não contenham qualquer uma das etiquetas especificadas. 1. Escolha **Próximo**. 1. Em **Configure schedule** (Configurar agendamento), configure os agendamentos de política. Uma política pode ter até quatro agendamentos. A Programação 1 é obrigatória. As Programações 2, 3 e 4 são opcionais. Para cada agendamento de política que você adicionar, faça o seguinte: 1. Na seção **Schedule details** (Detalhes do agendamento), faça o seguinte: 1. Em **Schedule name** (Nome do agendamento), especifique um nome descritivo para o agendamento. 1. Em **Frequency** (Frequência) e nos campos relacionados, configure o intervalo entre as execuções da política. É possível configurar execuções de políticas com uma programação diária, semanal, mensal ou anual. Como opção, escolha **Custom cron expression** (Expressão cron personalizada) para especificar um intervalo de até 1 ano. Para obter mais informações, consulte [Cron e expressões de taxa](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html) no *Guia do EventBridge usuário da Amazon*. **nota** Se precisar habilitar o **arquivamento de snapshots** para a programação, você deve selecionar a frequência **mensal** ou **anual**, ou especificar uma expressão cron com uma frequência de criação de pelo menos 28 dias. Se você especificar uma frequência mensal que crie snapshots em um dia específico de uma semana específica (por exemplo, na segunda quinta-feira do mês), para uma programação baseada em contagem, a contagem de retenção para o nível de arquivamento deverá ser 4 ou mais. 1. Em **Starting at** (Iniciando às), especifique a hora em que as execuções da política estão programadas para iniciar. A primeira execução da política começa uma hora depois do horário agendado. A hora deve ser inserida no formato `hh:mm` UTC. 1. Em **Retention type** (Tipo de retenção), especifique a política de retenção para snapshots criados pelo agendamento. É possível reter snapshots com base na contagem total ou na idade deles. + Retenção baseada em contagem + Com o arquivamento de snapshots desabilitado, o intervalo varia de `1` a `1000`. Quando o limite de retenção for atingido, o snapshot mais antigo será excluído permanentemente. + Com o arquivamento de snapshots habilitado, o intervalo varia de `0` (arquivamento imediatamente após a criação) a `1000`. Quando o limite de retenção for atingido, o snapshot mais antigo será convertido em um snapshot completo e movido para o nível de arquivamento. + Retenção com base em tempo + Com o arquivamento de snapshots desabilitado, o intervalo varia de `1` dia a `100` anos. Quando o limite de retenção for atingido, o snapshot mais antigo será excluído permanentemente. + Com o arquivamento de snapshots habilitado, o intervalo varia de `0` dias (arquivamento imediatamente após a criação) a `100` anos. Quando o limite de retenção for atingido, o snapshot mais antigo será convertido em um snapshot completo e movido para o nível de arquivamento. **nota** Todas as programações devem ter o mesmo tipo de retenção (baseado em idade ou contagem). É possível especificar o tipo de retenção somente para a Programação 1. As Programações 2, 3 e 4 herdam o tipo de retenção da Programação 1. Cada programação pode ter sua própria contagem ou período de retenção. Se você habilitar a restauração rápida de snapshots, a cópia entre regiões ou o compartilhamento de snapshots, deverá especificar uma contagem de retenção de `1` ou mais, ou um período de retenção de `1` dia ou mais. 1. (*AWS Outposts e somente para clientes da Zona Local*) Especifique o destino do snapshot. Para **Destino do snapshot**, especifique o destino dos snapshots criados pela política. + Se a política tem como alvo recursos em uma região, os instantâneos devem ser criados na mesma região. AWS A região está selecionada para você. + Se a política tiver como alvo recursos em uma zona local, você pode criar snapshots na mesma zona local que o recurso de origem ou em sua região principal. + Se a política tiver como alvo recursos em um Outpost, você pode criar snapshots no mesmo Outpost que o recurso de origem ou em sua região principal. 1. Configure a marcação para snapshots. Na seção **Tagging** (Marcação), faça o seguinte: 1. Para copiar todas as etiquetas definidas por usuário do volume de origem para os snapshots criados pelo agendamento, selecione **Copy tags from source** (Copiar etiquetas da origem). 1. Para especificar etiquetas adicionais a serem atribuídas aos snapshots criados por esse agendamento, escolha **Add tags** (Adicionar etiquetas). 1. Configurar scripts prévios e posteriores para snapshots consistentes com a aplicação. Para obter mais informações, consulte [Automatizar snapshots consistentes com a aplicação com o Data Lifecycle Manager](automate-app-consistent-backups.md). 1. (*Políticas que têm somente volumes como alvo*) Configurar o arquivamento dos snapshots. Na seção **Arquivamento de snapshots**, faça o seguinte: **nota** Você só pode habilitar o arquivamento de snapshots para uma única programação em uma política. 1. Para habilitar o arquivamento de snapshots para a programação, selecione **Archive snapshots created by this schedule** (Arquivar os snapshots criados por essa programação). **nota** Você só pode habilitar o arquivamento de snapshots se a frequência de criação de snapshots for mensal ou anual, ou se especificar uma expressão cron com uma frequência de criação de pelo menos 28 dias. 1. Especifique a regra de retenção para snapshots no nível de arquivamento. + Para **programações baseadas em contagem**, especifique o número de snapshots a serem retidos no nível de arquivamento. Quando o limite de retenção for atingido, o snapshot mais antigo será excluído permanentemente do nível de arquivamento. Por exemplo, se você especificar 3, a programação reterá no máximo 3 snapshots no nível de arquivamento. Quando o quarto snapshot for arquivado, o mais antigo dos três snapshots existentes no nível de arquivamento será excluído. + Para **programações baseadas em idade**, especifique por quanto tempo os snapshots devem ser retidos no nível de arquivamento. Quando o limite de retenção for atingido, o snapshot mais antigo será excluído permanentemente do nível de arquivamento. Por exemplo, se você especificar 120 dias, a programação excluirá automaticamente os snapshots do nível de arquivamento quando eles atingirem essa idade. **Importante** O período de retenção mínimo para snapshots arquivados é de 90 dias. Você deve especificar uma regra de retenção para reter o snapshot por pelo menos 90 dias. 1. Habilitar a restauração rápida de snapshots. Para habilitar a restauração rápida de snapshots para snapshots criados pelo agendamento, na seção **Fast snapshot restore** (Restauração rápida de snapshots), selecione **Enable fast snapshot restore** (Habilitar restauração rápida de snapshots). Se você habilitar a restauração rápida de snapshots, deverá escolher as zonas de disponibilidade nas quais serão habilitadas. Se o agendamento usar uma programação de retenção baseada em idade, será necessário especificar o período para o qual habilitar a restauração rápida de snapshots para cada snapshot. Se o agendamento usar retenção baseada em contagem, será necessário especificar o número máximo de snapshots para ativar a restauração rápida de snapshots. Se o agendamento criar snapshots em um Outpost, você não poderá habilitar a restauração rápida de snapshots. A restauração rápida de snapshots não é compatível com snapshots locais armazenados em um Outpost. **nota** Você será cobrado por cada minuto em que a restauração rápida de snapshots estiver habilitada para um snapshot em uma determinada zona de disponibilidade. As cobranças são divididas com um mínimo de uma hora. 1. Configurar cópia entre regiões. Para copiar snapshots criados pelo agendamento para um Outpost ou para uma região diferente, na seção **Cópia entre regiões**, selecione **Habilitar cópia entre regiões**. Se o agendamento criar snapshots em uma região, será possível copiar os snapshots para até três regiões ou Outposts adicionais na sua conta. É preciso especificar uma regra de cópia entre regiões separada para cada Outpost ou região de destino. Para cada região ou Outpost, é possível escolher diferentes políticas de retenção e se deseja copiar todas as etiquetas ou nenhuma etiqueta. Se o snapshot de origem estiver criptografado, ou se a criptografia estiver habilitada por padrão, os snapshots copiados serão criptografados. Se o snapshot de origem não estiver criptografado, será possível habilitar a criptografia. Se você não especificar uma chave do KMS, os snapshots serão criptografados usando a chave do KMS padrão de criptografia do EBS em cada região de destino. Se você especificar uma Chave do KMS para a região de destino, a função do IAM selecionada deverá ter acesso à Chave do KMS. **nota** É necessário garantir que o número de cópias de snapshots simultâneas não seja excedido por região. Se a política criar snapshots em um Outpost, você não poderá copiá-los para uma região ou outro Outpost e as configurações de cópia entre regiões não estarão disponíveis. 1. Configurar compartilhamento entre contas. No **compartilhamento entre contas**, configure a política para compartilhar automaticamente os instantâneos criados pela agenda com outras AWS contas. Faça o seguinte: 1. Para ativar o compartilhamento com outras AWS contas, selecione **Ativar compartilhamento entre contas**. 1. Para adicionar contas com as quais os snapshots serão compartilhados, escolha **Add account** (Adicionar conta), insira o ID de 12 dígitos da conta da AWS e escolha **Add** (Adicionar). 1. Para cancelar o compartilhamento de snapshots compartilhados automaticamente após um período específico, selecione **Unshare automatically** (Cancelar o compartilhamento automaticamente). Se você escolher cancelar automaticamente o compartilhamento de snapshots compartilhados, o período após o qual cancelar o compartilhamento automaticamente dos snapshots não poderá ser maior do que o período para o qual a política retém seus snapshots. Por exemplo, se a configuração de retenção da política retém snapshots por um período de cinco dias, é possível configurar a política para cancelar o compartilhamento automático de snapshots compartilhados após períodos de até quatro dias. Isso se aplica a políticas com configurações de retenção de snapshots baseadas em idade e em contagem. Se você não habilitar o cancelamento automático de compartilhamento, o snapshot será compartilhado até ser excluído. **nota** Você só pode compartilhar snapshots não criptografados ou criptografados usando uma chave gerenciada pelo cliente gerenciada pelo cliente. Você não pode compartilhar snapshots criptografados com a Chave do KMS de criptografia padrão do EBS. Se você compartilhar snapshots criptografados, também deverá compartilhar a Chave do KMS usada para criptografar o volume de origem com as contas de destino. Para obter mais informações, consulte [Como permitir que usuários em outras contas usem uma chave do KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) no *Guia do desenvolvedor do AWS Key Management Service *. 1. Para adicionar outros agendamentos, escolha **Add another schedule** (Adicionar outro agendamento), localizado na parte superior da tela. Para cada agendamento adicional, preencha os campos conforme descrito anteriormente neste tópico. 1. Depois de adicionar os agendamentos necessárias, escolha **Review policy** (Revisar política). 1. Revise o resumo da política e escolha **Create policy** (Criar política). **nota** Se receber um erro `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consulte [Solucionar problemas do Amazon Data Lifecycle Manager](dlm-troubleshooting.md) para obter mais informações. ------ #### [ Command line ] Use o [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)comando para criar uma política de ciclo de vida de instantâneos. Para `PolicyType`, especifique `EBS_SNAPSHOT_MANAGEMENT`. **nota** Para simplificar a sintaxe, os exemplos a seguir usam um arquivo JSON `policyDetails.json`, que inclui os detalhes da política. **Exemplo 1: política de ciclo de vida de snapshot com duas programações** Este exemplo cria uma política de ciclo de vida de snapshot que cria snapshots de todos os volumes que têm uma chave de tag de `costcenter` com um valor de `115`. A política inclui duas programações. A primeira programação cria um snapshot todos os dias às 3h UTC. A segunda programação cria um snapshot semanal todas as sextas-feiras às 17h 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 ``` Este é um exemplo do arquivo `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 a solicitação for bem-sucedida, o comando retornará o ID da política recém-criada. O seguinte é um exemplo de saída. ``` { "PolicyId": "policy-0123456789abcdef0" } ``` **Exemplo 2: política de ciclo de vida de snapshot direcionada a instâncias que cria snapshots de um subconjunto de volumes de dados (não raiz)** Este exemplo cria uma política de ciclo de vida de snapshots de vários volumes com base em instâncias marcadas com `code=production`. A política inclui um agendamento. O agendamento não cria snapshots dos volumes de dados com a etiqueta `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 ``` Este é um exemplo do arquivo `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 a solicitação for bem-sucedida, o comando retornará o ID da política recém-criada. O seguinte é um exemplo de saída. ``` { "PolicyId": "policy-0123456789abcdef0" } ``` **Exemplo 3: política de ciclo de vida de snapshots que automatiza snapshots locais de recursos do Outpost** Este exemplo cria uma política de ciclo de vida de snapshots que cria snapshots de volumes marcados com `team=dev` em todos os seus Outposts. A política cria os snapshots nos mesmos Outposts que os volumes de origem. A política cria snapshots a cada `12` horas a partir das `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 ``` Este é um exemplo do arquivo `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 } ]} ``` **Exemplo 4: política de ciclo de vida de snapshots que cria snapshots em uma região e os copia para um Outpost** O exemplo de política a seguir cria snapshots de volumes com a tag `team=dev`. Os snapshots são criados na mesma região que o volume de origem. Os snapshots são criados a cada `12` horas a partir das `00:00` UTC e retêm, no máximo, `1` snapshot. A política também copia os snapshots para o Outpost `arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0`, criptografa os snapshots copiados usando a chave do KMS de criptografia padrão e retém as cópias por `1` mês. ``` aws dlm create-lifecycle-policy \ --description "Copy snapshots to Outpost" \ --state ENABLED \ --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \ --policy-details file://policyDetails.json ``` Este é um exemplo do arquivo `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" } }] } ]} ``` **Exemplo 5: política de ciclo de vida de snapshots com uma programação baseada em idade habilitada para arquivamento** Este exemplo cria uma política de ciclo de vida de snapshots que visa volumes marcados com `Name=Prod`. A política tem uma programação baseada em idade que cria snapshots no primeiro dia de cada mês às 9h. A programação retém cada snapshot no nível padrão por um dia e depois o move para o nível de arquivamento. Os snapshots são armazenados no nível de arquivamento por 90 dias antes de serem excluídos. ``` 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 ``` Este é um exemplo do arquivo `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" } ] } ``` **Exemplo 6: política de ciclo de vida de snapshots com uma programação baseada em conta habilitada para arquivamento** Este exemplo cria uma política de ciclo de vida de snapshots que visa volumes marcados com `Purpose=Test`. A política tem uma programação baseada em contagem que cria snapshots no primeiro dia de cada mês às 9h. A programação arquiva os snapshots imediatamente após a criação e retém no máximo três snapshots no nível de arquivamento. ``` 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 ``` Este é um exemplo do arquivo `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" } ] } ``` ------ ## Considerações sobre políticas de ciclo de vida de snapshots As seguintes **considerações gerais** se aplicam a políticas de ciclo de vida de snapshot: + As políticas de ciclo de vida do snapshot visam somente instâncias ou volumes que estão na mesma região que a política. + A primeira operação de criação de snapshot começa uma hora após o horário de início especificado. As operações subsequentes de criação de snapshot começam uma hora após o horário programado. + É possível criar várias políticas para fazer backup de um volume ou de uma instância. Por exemplo, se um volume tiver 2 etiquetas, com a etiqueta *A* como o destino da política *A* para criar um snapshot a cada 12 horas, e a etiqueta *B* como o destino da política *B* para criar um snapshot a cada 24 horas, o Amazon Data Lifecycle Manager cria snapshots de acordo com as programações de ambas as políticas. Como alternativa, é possível obter o mesmo resultado criando uma única política que tenha várias programações. Por exemplo, é possível criar uma única política voltada apenas para tag *A* e especificar duas programações: uma para cada 12 horas e uma para cada 24 horas. + Tags de recursos de destino diferenciam letras maiúsculas de minúsculas. + Se você remover as tags de destino de um recurso visado por uma política, o Amazon Data Lifecycle Manager não gerenciará mais os snapshots existentes no nível padrão e no nível de arquivamento; você deverá excluí-los manualmente se eles não forem mais necessários. + Se você criar uma política que segmente instâncias e novos volumes forem anexados à instância-alvo após a criação da política, os volumes recém-adicionados serão incluídos no backup na próxima execução da política. Todos os volumes associados à instância no momento da execução da política são incluídos. + Se você criar uma política com uma programação personalizada baseada em cron que esteja configurada para criar apenas um snapshot, a política não excluirá automaticamente esse snapshot quando o limite de retenção for atingido. Exclua manualmente o snapshot caso ele não seja mais necessário. + Se você criar uma política baseada na idade em que o período de retenção seja menor do que a frequência de criação, o Amazon Data Lifecycle Manager sempre reterá o último snapshot até que o próximo seja criado. Por exemplo, se uma política baseada na idade criar um snapshot por mês com um período de retenção de sete dias, o Amazon Data Lifecycle Manager reterá cada snapshot por um mês, mesmo que o período de retenção seja de sete dias. As seguintes considerações se aplicam ao **[arquivamento de snapshots](snapshot-archive.md)**: + Você só pode habilitar o arquivamento de snapshots para políticas de snapshots que visem volumes. + Você só pode especificar uma regra de arquivamento para uma única programação para cada política. + Se você estiver usando o console, só poderá habilitar o arquivamento de snapshots se a programação tiver uma frequência de criação mensal ou anual, ou tiver uma expressão cron com uma frequência de criação de pelo menos 28 dias. Se você estiver usando a AWS API ou o AWS CLI AWS SDK, poderá ativar o arquivamento de instantâneos somente se o cronograma tiver uma expressão cron com uma frequência de criação de pelo menos 28 dias. + O período mínimo de retenção no nível de arquivamento é de 90 dias. + Quando um snapshot está arquivado, ele é convertido em um snapshot completo quando é movido para o nível de arquivamento. Isso pode resultar em custos de armazenamento de snapshots mais altos. Para obter mais informações, consulte [Preços e faturamento para o arquivamento de snapshots do Amazon EBS](snapshot-archive-pricing.md). + A restauração rápida e o compartilhamento de snapshots são desabilitados para os snapshots quando eles são arquivados. + Se, no caso de um ano bissexto, a regra de retenção resultar em um período de retenção de arquivos de menos de 90 dias, o Amazon Data Lifecycle Manager garantirá que os snapshots sejam retidos pelo período mínimo de 90 dias. + Se você arquivar manualmente um snapshot criado pelo Amazon Data Lifecycle Manager e o snapshot ainda estiver arquivado quando o limite de retenção da programação for atingido, o Amazon Data Lifecycle Manager não gerenciará mais esse snapshot. Porém, se você restaurar o snapshot no nível padrão antes que o limite de retenção da programação seja atingido, a programação continuará gerenciando o snapshot de acordo com as regras de retenção. + Se você restaurar, permanente ou temporariamente, um snapshot arquivado pelo Amazon Data Lifecycle Manager no nível padrão e o snapshot ainda estiver arquivado quando o limite de retenção da programação for atingido, o Amazon Data Lifecycle Manager não gerenciará mais esse snapshot. Porém, se você rearquivar o snapshot antes que o limite de retenção da programação seja atingido, a programação excluirá o snapshot quando o limite de retenção for atingido. + Os snapshots arquivados pelo Amazon Data Lifecycle Manager contam para as cotas de `Archived snapshots per volume` e `In-progress snapshot archives per account`. + Se uma programação não conseguir arquivar um snapshot após repetidas tentativas durante 24 horas, o snapshot permanecerá no nível padrão e será programado para exclusão com base na hora em que seria excluído do nível de arquivamento. Por exemplo, se a programação arquivar snapshots por 120 dias, o snapshot permanecerá no nível padrão por 120 dias após a falha no arquivamento antes de ser excluído permanentemente. Para programações baseadas em contagem, o snapshot não conta para a contagem de retenção da programação. + Os snapshots devem ser arquivados na mesma região em que foram criados. Se você tiver habilitado a cópia e arquivamento de snapshot entre regiões, o Amazon Data Lifecycle Manager não arquivará a cópia do snapshot. + Os snapshots arquivados pelo Amazon Data Lifecycle Manager são marcados com a etiqueta `aws:dlm:archived=true` do sistema. Além disso, os snapshots criados por uma programação baseada em idade habilitada para arquivamento são marcados com a tag `aws:dlm:expirationTime` do sistema, que indica a data e a hora em que o snapshot está programado para ser arquivado. Estas considerações se aplicam a **excluir volumes raiz e volumes de dados (não raiz)**: + Se você optar por excluir volumes de inicialização e especificar tags que, consequentemente, excluem todos os volumes de dados adicionais anexados a uma instância, o Amazon Data Lifecycle Manager não criará nenhum snapshot para a instância afetada e emitirá uma métrica. `SnapshotsCreateFailed` CloudWatch Para obter mais informações, consulte [Monitore políticas usando CloudWatch](monitor-dlm-cw-metrics.md). Os seguintes fatores são aplicáveis à **exclusão de volumes ou ao encerramento de instâncias com direcionamento por políticas de ciclo de vida de snapshots**: + Se você excluir um volume ou encerrar uma instância visada por uma política com uma programação de retenção baseada em contagem, o Amazon Data Lifecycle Manager não gerenciará mais os snapshots no nível padrão e no nível de arquivamento que foram criados a partir do volume excluído ou da instância encerrada. Exclua manualmente esses snapshots mais antigos caso eles não sejam mais necessários. + Se você excluir um volume ou encerrar uma instância visada por uma política com uma programação de retenção baseada em idade, a política continuará excluir snapshots no nível padrão e no nível de arquivamento que foram criados a partir do volume ou da instância excluídos até restar apenas um snapshot. Exclua manualmente o último snapshot caso ele não seja mais necessário. As seguintes considerações se aplicam às políticas de ciclo de vida de snapshots e à **[restauração rápida de snapshots](ebs-fast-snapshot-restore.md)**: + O Amazon Data Lifecycle Manager pode habilitar a restauração rápida de snapshots somente para snapshots com um tamanho de 16 TiB ou menos. Para obter mais informações, consulte [Restauração rápida de snapshots do Amazon EBS](ebs-fast-snapshot-restore.md). + Um snapshot habilitado para restauração rápida continua habilitado mesmo que você exclua ou desabilite a política, desabilite a restauração rápida de snapshots ou desabilite a restauração de snapshots para a zona de disponibilidade. É possível desabilitar a restauração rápida desses snapshots manualmente. + Se você habilitar a restauração rápida de snapshots para uma política e exceder o número máximo de snapshots que podem ser habilitados para restauração rápida de snapshots, o Amazon Data Lifecycle Manager criará snapshots, mas não os habilitará para restauração rápida. Depois que um snapshot que está habilitado para restauração rápida for excluído, o próximo snapshot que o Amazon Data Lifecycle Manager criar será habilitado para restauração rápida. + Quando a restauração rápida de um snapshot é habilitada, são necessários 60 minutos por TiB para otimizar o snapshot. Recomendamos configurar as programações de modo que cada snapshot seja totalmente otimizado antes que o Amazon Data Lifecycle Manager crie o próximo snapshot. + Se você habilitar a restauração rápida de snapshots para uma política que visa instâncias, o Amazon Data Lifecycle Manager habilitará a restauração rápida de snapshot para cada um dos snapshots de vários volumes, definidos individualmente. Se o Amazon Data Lifecycle Manager não habilitar a restauração rápida de snapshots para um dos snapshots no conjunto de snapshots de vários volumes, ele tentará habilitar a restauração rápida para os snapshots restantes no conjunto. + Você será cobrado por cada minuto em que a restauração rápida de snapshots estiver habilitada para um snapshot em uma determinada zona de disponibilidade. As cobranças são divididas com um mínimo de uma hora. Para obter mais informações, consulte [Definição de preço e faturamento](ebs-fast-snapshot-restore.md#fsr-pricing). **nota** Dependendo da configuração de suas políticas de ciclo de vida, é possível ter vários snapshots habilitados para restauração rápida de snapshots em várias zonas de disponibilidade, simultaneamente. As considerações a seguir se aplicam às políticas de ciclo de vida de snapshots e aos **volumes habilitados para [multi-attach](ebs-volumes-multi.md)**: + Ao criar uma política de ciclo de vida voltada para instâncias que tenham o mesmo volume habilitado de Multi-Attach, o Amazon Data Lifecycle Manager inicia um snapshot do volume para cada instância anexada. Use a tag *timestamp* para identificar o conjunto de snapshots consistentes em relação ao tempo criados das instâncias anexadas. As considerações a seguir se aplicam ao **compartilhamento de snapshots entre contas**: + Você só pode compartilhar snapshots não criptografados ou criptografados usando uma chave gerenciada pelo cliente gerenciada pelo cliente. + Você não pode compartilhar snapshots criptografados com a Chave do KMS de criptografia padrão do EBS. + Se você compartilhar snapshots criptografados, também deverá compartilhar a chave do KMS usada para criptografar o volume de origem com as contas de destino. Para obter mais informações, consulte [Permissão para usuários em outras contas usarem uma chave KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) no *Guia de desenvolvedor do AWS Key Management Service *. As considerações a seguir se aplicam às políticas de snapshots e ao **[arquivamento de snapshots](snapshot-archive.md)**: + Se você arquivar manualmente um snapshot criado por uma política e esse snapshot estiver no nível de arquivamento quando o limite de retenção da política for atingido, o Amazon Data Lifecycle Manager não excluirá o snapshot. O Amazon Data Lifecycle Manager não gerencia snapshots enquanto eles são armazenados no nível de arquivamento. Se não precisar mais dos snapshots que estão armazenados no nível de arquivamento, você deve excluí-los manualmente. As seguintes considerações se aplicam às políticas de snapshots e à [Lixeira](recycle-bin.md): + Se o Amazon Data Lifecycle Manager excluir um snapshot e enviá-lo para a lixeira quando o limite de retenção da política for atingido e você restaurar manualmente o snapshot da lixeira, você deverá excluir manualmente esse snapshot quando ele não for mais necessário. O Amazon Data Lifecycle Manager não poderá mais gerenciar o snapshot. + Se você excluir manualmente um snapshot criado por uma política e esse snapshot estiver na lixeira quando o limite de retenção da política for atingido, o Amazon Data Lifecycle Manager não excluirá o snapshot. O Amazon Data Lifecycle Manager não gerencia snapshots enquanto eles estão armazenados no nível de arquivamento. Se o snapshot for restaurado da lixeira antes que o limite de retenção da política seja atingido, o Amazon Data Lifecycle Manager excluirá o snapshot quando o limite de retenção da política for atingido. Se o snapshot for restaurado da lixeira depois que o limite de retenção da política seja atingido, o Amazon Data Lifecycle Manager não excluirá mais o snapshot. Exclua manualmente o snapshot quando ele não for mais necessário. As seguintes considerações se aplicam a políticas de ciclo de vida de snapshots que estão no estado **error**: + Para políticas com programações de retenção com base na idade, os snapshots configurados para expirar enquanto a política estiver no estado `error` serão retidos por tempo indeterminado. Será necessário excluir os snapshots manualmente. Quando você habilita a política novamente, o Amazon Data Lifecycle Manager retoma a exclusão de snapshots à medida que os períodos de retenção expiram. + Para políticas com programas de retenção com base em contagem, a política interrompe a criação e exclusão de snapshots enquanto está no estado `error`. Ao reabilitar a política, o Amazon Data Lifecycle Manager retoma a criação de snapshots e retoma a exclusão de snapshots quando o limite de retenção é atingido. As seguintes considerações se aplicam às políticas de snapshot e **[bloqueio de snapshot](ebs-snapshot-lock.md)**: + Se você bloquear manualmente um snapshot criado pelo Amazon Data Lifecycle Manager e esse snapshot ainda estiver bloqueado quando seu limite de retenção for atingido, o Amazon Data Lifecycle Manager não gerenciará mais esse snapshot. Exclua manualmente o snapshot caso ele não seja mais necessário. + Se você bloquear manualmente um snapshot criado e habilitado para restauração rápida de snapshots pelo Amazon Data Lifecycle Manager e o snapshot ainda estiver arquivado quando seu limite de retenção for atingido, o Amazon Data Lifecycle Manager não desabilitará a restauração rápida de snapshots nem excluirá o snapshot. Você deve desabilitar manualmente a restauração rápida de snapshots e excluir o snapshot caso ele não seja mais necessário. + Se você registrar manualmente um snapshot criado por Amazon Data Lifecycle Manager com uma AMI e depois bloquear o snapshot e ele ainda estiver bloqueado e associado à AMI quando seu limite de retenção for atingido, o Amazon Data Lifecycle Manager continuará tentando excluir o snapshot. Quando o registro da AMI for cancelado e o snapshot for desbloqueado, o Amazon Data Lifecycle Manager excluirá automaticamente o snapshot. ## Recursos adicionais do Para obter mais informações, consulte o blog [Automatizando o snapshot e o gerenciamento de AMI do Amazon EBS usando o Amazon AWS Data Lifecycle Manager](https://aws.amazon.com/blogs/storage/automating-amazon-ebs-snapshot-and-ami-management-using-amazon-dlm/). # Automatizar snapshots consistentes com a aplicação com o Data Lifecycle Manager Você pode automatizar snapshots consistentes com a aplicação com o Amazon Data Lifecycle Manager habilitando scripts prévios e posteriores nas políticas de ciclo de vida de snapshot que têm as instâncias como alvo. O Amazon Data Lifecycle Manager se integra ao (Systems AWS Systems Manager Manager) para oferecer suporte a snapshots consistentes com aplicativos. O Amazon Data Lifecycle Manager usa documentos de comando do Systems Manager (SSM) que incluem scripts prévios e posteriores para automatizar as ações necessárias para fazer snapshots consistentes com a aplicação. Antes de o Amazon Data Lifecycle Manager iniciar a criação do snapshot, ele executa os comandos no pré-script para congelar e liberar. I/O. After Amazon Data Lifecycle Manager initiates snapshot creation, it runs the commands in the post script to thaw I/O Usando o Amazon Data Lifecycle Manager, você pode automatizar os snapshots consistentes com a aplicação dos seguintes itens: + Aplicações do Windows que usam o Volume Shadow Copy Service (VSS) + SAP HANA usando um documento AWS SSDM gerenciado. Para obter mais informações, consulte [Amazon EBS snapshots for SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/ebs-sap-hana.html). + Bancos de dados autogerenciados, como MySQL, PostgreSQL ou IRIS, usando modelos de documentos SSM InterSystems **Topics** + [Requisitos para o uso de scripts prévios e posteriores](#app-consistent-prereqs) + [Conceitos básicos dos snapshots consistentes com a aplicação](#app-consistent-get-started) + [Considerações sobre os backups do VSS com o Amazon Data Lifecycle Manager](#app-consistent-vss) + [Responsabilidade compartilhada pelos snapshots consistentes com a aplicação](#shared-responsibility) ## Requisitos para o uso de scripts prévios e posteriores A tabela a seguir descreve os requisitos para o uso de scripts prévios e posteriores com o Amazon Data Lifecycle Manager. | | Snapshots consistentes com aplicação | | | --- |--- |--- | | Requisito | Backup do VSS | Documento do SSM personalizado | Outros casos de uso | | --- |--- |--- |--- | | Agente SSM instalado e em execução nas instâncias de destino | ✓ | ✓ | ✓ | | Requisitos do sistema VSS atendidos nas instâncias de destino | ✓ | | | | Perfil de instância habilitado para VSS associado às instâncias de destino | ✓ | | | | Componentes do VSS instalados nas instâncias de destino | ✓ | | | | Prepare o documento SSM com comandos pré e pós-script | | ✓ | ✓ | | Prepare a função IAM do Amazon Data Lifecycle Manager, execute scripts pré e pós | ✓ | ✓ | ✓ | | Crie uma política de snapshot que vise instâncias e seja configurada para scripts anteriores e posteriores | ✓ | ✓ | ✓ | ## Conceitos básicos dos snapshots consistentes com a aplicação Esta seção explica as etapas que você precisa seguir para automatizar snapshots consistentes com a aplicação usando o Amazon Data Lifecycle Manager. ### Etapa 1: preparar as instâncias-alvo Você precisa preparar as instâncias-alvo para snapshots consistentes com a aplicação usando o Amazon Data Lifecycle Manager. Dependendo do caso de uso, faça um dos procedimentos a seguir. ------ #### [ Prepare for VSS Backups ] **Para preparar as instâncias-alvo para backups do VSS** 1. Instale o SSM Agent nas instâncias-alvo, se ainda não estiver instalado. Se o SSM Agent já estiver instalado em suas instâncias-alvo, pule esta etapa. Para obter mais informações, consulte [Trabalho com o SSM Agent em instâncias do EC2 para o Windows Server](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html). 1. Certifique-se de que o SSM Agent esteja em execução. Para obter mais informações, consulte [Verificar o status do SSM Agent e iniciar o agente](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html). 1. Configure o Systems Manager para instâncias do Amazon EC2. Para obter mais informações, consulte [Configuração do Systems Manager para instâncias Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) no *Guia do usuário do AWS Systems Manager *. 1. [Certifique-se de que os requisitos do sistema para backups do VSS sejam atendidos](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-prereqs.html). 1. [ Anexe um perfil de instância habilitado para o VSS às instâncias-alvo.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vss-iam-reqs.html) 1. [Instale os componentes do VSS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-getting-started.html). ------ #### [ Prepare for SAP HANA backups ] **Para preparar as instâncias-alvo para backups do SAP HANA** 1. Prepare o ambiente do SAP HANA nas instâncias-alvo. 1. Configure a instância com o SAP HANA. Se você ainda não tiver um ambiente do SAP HANA, pode consultar [SAP HANA Environment Setup on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/std-sap-hana-environment-setup.html). 1. Faça login no SystemDB como um usuário administrador adequado. 1. Crie um usuário de backup de banco de dados para ser usado com o Amazon Data Lifecycle Manager. ``` CREATE USER username PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE; ``` Por exemplo, o comando a seguir criar um usuário denominado `dlm_user` com a senha `password`. ``` CREATE USER dlm_user PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE; ``` 1. Atribua um perfil de `BACKUP OPERATOR` ao usuário de backup do banco de dados que você criou na etapa anterior. ``` GRANT BACKUP OPERATOR TO username ``` Por exemplo, o comando a seguir atribui o perfil a um usuário denominado `dlm_user`. ``` GRANT BACKUP OPERATOR TO dlm_user ``` 1. Faça login no sistema operacional como administrador, por exemplo `sidadm`. 1. Crie uma entrada `hdbuserstore` para armazenar as informações de conexão para que o documento do SSM do SAP HANA possa se conectar ao SAP HANA sem que os usuários precisem inserir as informações. ``` hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:3hana_instance_number13 username password ``` Por exemplo: ``` hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:30013 dlm_user password ``` 1. Teste a conexão. ``` hdbsql -U DLM_HANADB_SNAPSHOT_USER "select * from dummy" ``` 1. Instale o SSM Agent nas instâncias-alvo, se ainda não estiver instalado. Se o SSM Agent já estiver instalado em suas instâncias-alvo, pule esta etapa. Para obter mais informações, consulte [Instalar manualmente o SSM Agent em instâncias do EC2 para Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html). 1. Certifique-se de que o SSM Agent esteja em execução. Para obter mais informações, consulte [Verificar o status do SSM Agent e iniciar o agente](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html). 1. Configure o Systems Manager para instâncias do Amazon EC2. Para obter mais informações, consulte [Configuração do Systems Manager para instâncias Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) no *AWS Systems Manager Guia do usuário do *. ------ #### [ Prepare for custom SSM documents ] **Para preparar os documentos do SSM personalizados das instâncias-alvo** 1. Instale o SSM Agent nas instâncias-alvo, se ainda não estiver instalado. Se o SSM Agent já estiver instalado em suas instâncias-alvo, pule esta etapa. + (Instâncias do Linux) [Instalar o SSM Agent manualmente em instâncias do EC2 para Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) + (Instâncias do Windows) [Trabalhar com o SSM Agent em instâncias do EC2 para Windows Server](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) 1. Certifique-se de que o SSM Agent esteja em execução. Para obter mais informações, consulte [Verificar o status do SSM Agent e iniciar o agente](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html). 1. Configure o Systems Manager para instâncias do Amazon EC2. Para obter mais informações, consulte [Configuração do Systems Manager para instâncias Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) no *AWS Systems Manager Guia do usuário do *. ------ ### Etapa 2: preparar o documento do SSM **nota** Essa etapa só é necessária para documentos do SSM personalizados. Não é necessária para backup do VSS ou para o SAP HANA. Para backups do VSS e SAP HANA, o Amazon Data Lifecycle Manager AWS usa o documento SSM gerenciado. Se você estiver automatizando instantâneos consistentes com aplicativos para um banco de dados autogerenciado, como MySQL, PostgreSQL InterSystems ou IRIS, deverá criar um documento de comando SSM que inclua um pré-script para congelar e I/O liberar antes do início da criação do instantâneo e um pós-script para descongelar após o início da criação do instantâneo. I/O Se seu banco de dados MySQL, PostgreSQL ou InterSystems IRIS usa configurações padrão, você pode criar um documento de comando SSM usando o conteúdo de amostra do documento SSM abaixo. Se seu banco de dados MySQL, PostgreSQL ou InterSystems IRIS usa uma configuração não padrão, você pode usar o conteúdo de amostra abaixo como ponto de partida para seu documento de comando SSM e depois personalizá-lo para atender às suas necessidades. Ou então, se quiser criar um novo documento do SSM começando do zero, você pode usar o modelo de documento do SSM em branco abaixo e adicionar seus comandos prévios e posteriores nas seções apropriadas do documento. **Observe o seguinte:** É sua responsabilidade garantir que o documento do SSM realize as ações corretas e necessárias para a configuração do banco de dados. Só haverá garantia de que os snapshots sejam consistentes com a aplicação se os scripts prévios e posteriores no documento do SSM puderem congelar, descarregar e descongelar a E/S com sucesso. O documento do SSM deve incluir os campos obrigatórios para `allowedValues`, incluindo `pre-script`, `post-script` e `dry-run`. O Amazon Data Lifecycle Manager executará os comandos na instância com base no conteúdo dessas seções. Se o documento do SSM não tiver essas seções, o Amazon Data Lifecycle Manager o tratará como uma execução que falhou. ------ #### [ 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 ``` Para obter mais informações, consulte o [GitHub repositório.](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." ``` ------ Quando tiver o conteúdo do documento do SSM, use um dos procedimentos a seguir para criar o documento do SSM personalizado. ------ #### [ Console ] **Para criar um documento de comando do SSM** 1. Abra o AWS Systems Manager console em [https://console.aws.amazon.com//systems-manager/](https://console.aws.amazon.com//systems-manager/). 1. No painel de navegação, escolha **Documentos** e depois **Criar documento**, **Comando ou Sessão**. 1. Em **Name** (Nome), insira um nome descritivo para o documento. 1. Em **Tipo de destino**, selecione**/AWS::EC2::Instance**. 1. Para **Tipo de documento**, selecione **Comando**. 1. No campo **Conteúdo**, selecione **YAML** e cole o conteúdo do documento. 1. Na seção **Tags do documento**, adicione uma tag com uma chave de tag de `DLMScriptsAccess` e um valor de tag de `true`. **Importante** A `DLMScriptsAccess:true` tag é exigida pela política AWS gerenciada de **AWSDataLifecycleManagerSSMFullacesso** usada na *Etapa 3: Preparar a função IAM do Amazon Data Lifecycle Manager*. A política usa a chave de condição `aws:ResourceTag` para restringir o acesso aos documentos do SSM que tenham essa tag. 1. Escolha **Criar documento**. ------ #### [ AWS CLI ] **Para criar um documento de comando do SSM** Use o comando [create-document](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html). Para `--name`, especifique um nome descritivo para o documento. Em `--document-type`, especifique `Command`. Para `--content`, especifique o caminho para o arquivo .yaml com o conteúdo do documento do SSM. Em `--tags`, especifique `"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" ``` ------ ### Etapa 3: preparar o perfil do IAM do Amazon Data Lifecycle Manager **nota** Essa etapa é necessária se: Você cria ou atualiza uma política pre/post de snapshot habilitada por script que usa uma função personalizada do IAM. Você usa a linha de comando para criar ou atualizar uma política de snapshot pre/post habilitada por script que usa o padrão. Se você usar o console para criar ou atualizar uma política de snapshot pre/post habilitada por script que usa a função padrão para gerenciar snapshots (**AWSDataLifecycleManagerDefaultRole**), pule esta etapa. Nesse caso, anexamos automaticamente a política de **AWSDataLifecycleManagerSSMFullacesso** a essa função. Você deve garantir que o perfil do IAM que você usa para a política conceda ao Amazon Data Lifecycle Manager permissão para realizar as ações do SSM necessárias para executar scripts prévios e posteriores nas instâncias-alvo da política. O Amazon Data Lifecycle Manager fornece uma política gerenciada (**AWSDataLifecycleManagerSSMFullAccess**) que inclui as permissões necessárias. Você pode anexar essa política ao perfil do IAM para gerenciar snapshots e garantir que ela inclua as permissões. **Importante** A política gerenciada de AWSData LifecycleManager SSMFull acesso usa a chave de `aws:ResourceTag` condição para restringir o acesso a documentos SSM específicos ao usar scripts anteriores e posteriores. Para permitir que o Amazon Data Lifecycle Manager acesse os documentos do SSM, você deve garantir que eles estejam marcados com `DLMScriptsAccess:true`. Ou então, você pode criar manualmente uma política personalizada ou atribuir as permissões necessárias diretamente ao perfil do IAM que você usa. Você pode usar as mesmas permissões definidas na política gerenciada do AWSData LifecycleManager SSMFull Access, no entanto, a chave de `aws:ResourceTag` condição é opcional. Se você decidir não incluir essa chave de condição, não precisará marcar os documentos do SSM com `DLMScriptsAccess:true`. Use um dos métodos a seguir para adicionar a política de **AWSDataLifecycleManagerSSMFullacesso** à sua função do IAM. ------ #### [ Console ] **Para anexar a política gerenciada ao seu perfil personalizado** 1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. No painel de navegação, selecione **Roles** (Funções). 1. Pesquise e selecione o perfil personalizado para gerenciar os snapshots. 1. Na guia **Permissões**, escolha **Adicionar permissões**, **Anexar políticas**. 1. Pesquise e selecione a política gerenciada do **AWSDataLifecycleManagerSSMFullAccess** e escolha **Adicionar permissões**. ------ #### [ AWS CLI ] **Para anexar a política gerenciada ao seu perfil personalizado** Use o comando [ da attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Para `---role-name`, especifique o nome do seu perfil personalizado. Em `--policy-arn`, especifique `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess`. ``` $ aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \ --role-name your_role_name ``` ------ ### Etapa 4: criar uma política de ciclo de vida de snapshots Para automatizar snapshots consistentes com a aplicação, você deve criar uma política de ciclo de vida de snapshots que tenha como alvo as instâncias e configurar scripts prévios e posteriores para essa política. ------ #### [ Console ] **Para criar uma política de ciclo de vida de snapshots** 1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. No painel de navegação, selecione **Elastic Block Store**, **Lifecycle Manager** ((Gerenciador de ciclo de vida) e **Create snapshot lifecycle policy** (Criar política de ciclo de vida de snapshot). 1. Na tela **Select policy type** (Selecionar tipo de política), escolha **EBS snapshot policy** (Política de snapshot do EBS) e depois **Next** (Próximo). 1. Na seção **Target resources** (Recursos de destino), faça o seguinte: 1. Para **Tipos de recursos-alvo**, escolha `Instance`. 1. Para **Tags de recurso-alvo**, especifique as tags de recurso que identificam as instâncias para backup. Só será feito backup dos recursos que têm as tags especificadas. 1. Para a **função do IAM**, escolha **AWSDataLifecycleManagerDefaultRole**(a função padrão para gerenciar instantâneos) ou escolha uma função personalizada que você criou e preparou para scripts anteriores e posteriores. 1. Configure as agendas e as opções adicionais conforme necessário. Recomendamos que você agende a criação dos snapshots para períodos que atendam à sua workload, como durante janelas de manutenção. No SAP HANA, recomendamos que você habilite a restauração rápida de snapshots. **nota** Se você habilitar uma agenda para backups do VSS, não poderá habilitar **Excluir volumes de dados específicos** ou **Copiar tags da fonte**. 1. Na seção **Scripts prévios e posteriores**, selecione **Habilitar scripts prévios e posteriores** e depois, dependendo da sua workload, faça o seguinte: + Para criar snapshots consistentes com a aplicação para as aplicações do Windows, selecione **Backup do VSS**. + Para criar snapshots consistentes com a aplicação de suas workloads do SAP HANA, selecione **SAP HANA.** + **Para criar instantâneos consistentes com aplicativos de todos os outros bancos de dados e cargas de trabalho, incluindo seus bancos de dados MySQL, PostgreSQL InterSystems ou IRIS autogerenciados, usando um documento SSM personalizado, selecione Documento SSM personalizado.** 1. Para **Opção de automatização**, escolha **Scripts prévios e posteriores**. 1. Para **Documento do SSM**, selecione o documento do SSM que você preparou. 1. Dependendo da opção selecionada, configure as seguintes opções adicionais: + **Tempo limite do script**: (*somente documento do SSM personalizado*) O tempo limite após o qual o Amazon Data Lifecycle Manager considera que a tentativa de execução do script falhou se não foi concluída. Se um script não for concluído dentro do período limite, o Amazon Data Lifecycle Manager considerará que a tentativa falhou. O período de tempo limite se aplica aos scripts prévios e posteriores individualmente. O limite de tempo mínimo e padrão é de 10 segundos. E o tempo limite máximo é de 120 segundos. + **Tentar os scripts com falha novamente**: selecione essa opção para fazer novas tentativas de executar os scripts que não forem concluídos dentro do período de tempo limite. Se o script prévio falhar, o Amazon Data Lifecycle Manager tentará realizar novamente todo o processo de criação de snapshots, incluindo a execução dos scripts prévios e posteriores. Se o script posterior falhar, o Amazon Data Lifecycle Manager fará nova tentativa de executar apenas o script posterior; nesse caso, o script prévio estará sido concluído e o snapshot poderá ter sido criado. + **Usar o padrão de snapshots consistentes em caso de falha**: selecione essa opção para usar padrão de snapshots consistentes em caso de falha se a execução do script prévio falhar. Esse é o comportamento padrão da criação de snapshots para o Amazon Data Lifecycle Manager se os scripts prévios e posteriores não estiverem habilitados. Se você habilitou novas tentativas, o Amazon Data Lifecycle Manager só usará o padrão de snapshots consistentes em caso de falha após esgotar o todas as tentativas. Se o script prévio falhar e você não usar o padrão de snapshots consistentes em caso de falha, o Amazon Data Lifecycle Manager não criará snapshots para a instância durante da execução agendada. **nota** Se você estiver criando snapshots para o SAP HANA, talvez queira desabilitar essa opção. Os snapshots consistentes em caso de falha das workloads do SAP HANA não podem ser restaurados da mesma maneira. 1. Escolha **Criar política padrão**. **nota** Se receber um erro `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consulte [Solucionar problemas do Amazon Data Lifecycle Manager](dlm-troubleshooting.md) para obter mais informações. ------ #### [ AWS CLI ] **Para criar uma política de ciclo de vida de snapshots** Use o [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)comando e inclua os `Scripts` parâmetros em`CreateRule`. Para obter mais informações sobre os parâmetros, consulte [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 ``` Em que `policyDetails.json` inclui um dos seguintes itens dependendo do caso de uso: + **Backup do 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 do 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 do SSM personalizado** ``` { "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 } }] } ``` ------ ## Considerações sobre os backups do VSS com o Amazon Data Lifecycle Manager Com o Amazon Data Lifecycle Manager, você pode fazer backup e restaurar aplicações do Windows habilitadas para o VSS (Volume Shadow Copy Service) sendo executadas em instâncias do Amazon EC2. Se a aplicação tiver um gravador de VSS registrado no VSS do Windows, o Amazon Data Lifecycle Manager criará um snapshot que será consistente com a aplicação para essa aplicação. **nota** Atualmente, o Amazon Data Lifecycle Manager é compatível com snapshots consistentes com a aplicação apenas dos recursos executados no Amazon EC2, especificamente em cenários de backup em que os dados da aplicação podem ser restaurados substituindo uma instância existente por uma nova instância criada do backup. Nem todos os tipos de instância ou aplicação são compatíveis com os backups do VSS. Para obter mais informações, consulte [Snapshots consistentes com aplicações do Windows VSS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html) no *Guia do usuário do Amazon EC2*. **Tipos de instâncias não compatíveis** Os seguintes tipos de instância do Amazon EC2 não são compatíveis com backups do VSS. Se sua política tiver como alvo um desses tipos de instância, o Amazon Data Lifecycle Manager ainda poderá criar backups do VSS, mas os snapshots talvez não estejam marcados com as tags de sistema necessárias. Sem essas tags, os snapshots não serão gerenciados pelo Amazon Data Lifecycle Manager após sua criação. Pode ser necessário excluir esses snapshots manualmente. + T3: `t3.nano` \$1 `t3.micro` + T3a: `t3a.nano` \$1 `t3a.micro` + T2: `t2.nano` \$1 `t2.micro` ## Responsabilidade compartilhada pelos snapshots consistentes com a aplicação **Você deve garantir que:** + O Agente SSM está instalado e em execução nas instâncias de destino up-to-date + O Systems Manager tenha permissões para executar as ações necessárias nas instâncias-alvo + O Amazon Data Lifecycle Manager tenha permissões para realizar as ações do Systems Manager necessárias para executar scripts prévios e posteriores nas instâncias-alvo. + Para cargas de trabalho personalizadas, como bancos de dados MySQL, PostgreSQL InterSystems ou IRIS autogerenciados, o documento SSM que você usa inclui as ações corretas e necessárias para congelar, limpar e descongelar a configuração do banco de dados. I/O + Os horários de criação de snapshots estejam alinhados com sua agenda de workload. Por exemplo, tente agendar a criação de snapshots durante as janelas de manutenção agendadas. **O Amazon Data Lifecycle Manager garante que:** + A criação do snapshot seja iniciada dentro de 60 minutos a partir do horário agendado para criação do snapshot. + Os scripts prévios sejam executados antes do início da criação do snapshot. + Os scripts posteriores sejam executados após o script prévio ser bem-sucedido e a criação do snapshot ter sido iniciada. O Amazon Data Lifecycle Manager só execute o script posterior se o script prévio for bem-sucedido. Se o script prévio falhar, o Amazon Data Lifecycle Manager não executará o script posterior. + Os snapshots sejam marcados com as tags apropriadas na criação. + CloudWatch métricas e eventos são emitidos quando os scripts são iniciados e quando eles falham ou são bem-sucedidos. # Outros casos de uso de pré-scripts e pós-scripts Além de usar scripts prévios e posteriores para automatizar snapshots consistentes com a aplicação, você pode usar os scripts prévios e posteriores juntos ou individualmente para automatizar outras tarefas administrativas antes ou depois da criação do snapshot. Por exemplo: + Usar um script prévio para aplicar patches antes de criar os snapshots. Isso pode ajudar você a criar snapshots depois de aplicar as atualizações regulares de software semanais ou mensais. **nota** Se você escolher executar somente um script prévio, a opção **Usar o padrão de snapshots consistentes em caso de falha** será habilitada por padrão. + Usar um script posterior para aplicar patches após a criação de snapshots. Isso pode ajudar você a criar snapshots antes de aplicar suas atualizações regulares de software semanais ou mensais. ## Introdução a outros casos de uso Esta seção explica as etapas que você precisa executar ao usar scripts de and/or pré-publicação para **casos de uso que não sejam instantâneos consistentes com o aplicativo**. ### Etapa 1: preparar as instâncias-alvo **Para preparar suas instâncias de destino para scripts and/or pré-publicação** 1. Instale o SSM Agent nas instâncias-alvo, se ainda não estiver instalado. Se o SSM Agent já estiver instalado em suas instâncias-alvo, pule esta etapa. + (Instâncias do Linux) [Instalar o SSM Agent manualmente em instâncias do EC2 para Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) + (Instâncias do Windows) [Trabalhar com o SSM Agent em instâncias do EC2 para Windows Server](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) 1. Certifique-se de que o SSM Agent esteja em execução. Para obter mais informações, consulte [Verificar o status do SSM Agent e iniciar o agente](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html). 1. Configure o Systems Manager para instâncias do Amazon EC2. Para obter mais informações, consulte [Configuração do Systems Manager para instâncias Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) no *AWS Systems Manager Guia do usuário do *. ### Etapa 2: preparar o documento do SSM Você deve criar um documento de comando SSM que inclua os scripts de and/or pré-publicação com os comandos que você deseja executar. Você pode criar um documento do SSM usando o modelo de documento do SSM em branco abaixo e adicionar os comandos de script prévio e posterior nas seções apropriadas do documento. **Observe o seguinte:** É sua responsabilidade garantir que o documento do SSM realize as ações corretas e necessárias para a sua workload. O documento do SSM deve incluir os campos obrigatórios para `allowedValues`, incluindo `pre-script`, `post-script` e `dry-run`. O Amazon Data Lifecycle Manager executará os comandos na instância com base no conteúdo dessas seções. Se o documento do SSM não tiver essas seções, o Amazon Data Lifecycle Manager o tratará como uma execução que falhou. ``` ###===============================================================================### # 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." ``` ### Etapa 3: preparar o perfil do IAM do Amazon Data Lifecycle Manager **nota** Essa etapa é necessária se: Você cria ou atualiza uma política pre/post de snapshot habilitada por script que usa uma função personalizada do IAM. Você usa a linha de comando para criar ou atualizar uma política de snapshot pre/post habilitada por script que usa o padrão. Se você usar o console para criar ou atualizar uma política de snapshot pre/post habilitada por script que usa a função padrão para gerenciar snapshots (**AWSDataLifecycleManagerDefaultRole**), pule esta etapa. Nesse caso, anexamos automaticamente a política de **AWSDataLifecycleManagerSSMFullacesso** a essa função. Você deve garantir que o perfil do IAM que você usa para a política conceda ao Amazon Data Lifecycle Manager permissão para realizar as ações do SSM necessárias para executar scripts prévios e posteriores nas instâncias-alvo da política. O Amazon Data Lifecycle Manager fornece uma política gerenciada (**AWSDataLifecycleManagerSSMFullAccess**) que inclui as permissões necessárias. Você pode anexar essa política ao perfil do IAM para gerenciar snapshots e garantir que ela inclua as permissões. **Importante** A política gerenciada de AWSData LifecycleManager SSMFull acesso usa a chave de `aws:ResourceTag` condição para restringir o acesso a documentos SSM específicos ao usar scripts anteriores e posteriores. Para permitir que o Amazon Data Lifecycle Manager acesse os documentos do SSM, você deve garantir que eles estejam marcados com `DLMScriptsAccess:true`. Ou então, você pode criar manualmente uma política personalizada ou atribuir as permissões necessárias diretamente ao perfil do IAM que você usa. Você pode usar as mesmas permissões definidas na política gerenciada do AWSData LifecycleManager SSMFull Access, no entanto, a chave de `aws:ResourceTag` condição é opcional. Se você decidir não usar essa chave de condição, não precisará marcar os documentos do SSM com `DLMScriptsAccess:true`. Use um dos métodos a seguir para adicionar a política de **AWSDataLifecycleManagerSSMFullacesso** à sua função do IAM. ------ #### [ Console ] **Para anexar a política gerenciada ao seu perfil personalizado** 1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. No painel de navegação, selecione **Roles** (Funções). 1. Pesquise e selecione o perfil personalizado para gerenciar os snapshots. 1. Na guia **Permissões**, escolha **Adicionar permissões**, **Anexar políticas**. 1. Pesquise e selecione a política gerenciada do **AWSDataLifecycleManagerSSMFullAccess** e escolha **Adicionar permissões**. ------ #### [ AWS CLI ] **Para anexar a política gerenciada ao seu perfil personalizado** Use o comando [ da attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Para `---role-name`, especifique o nome do seu perfil personalizado. Em `--policy-arn`, especifique `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess`. ``` $ aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \ --role-name your_role_name ``` ------ ### Criar uma política de ciclo de vida de snapshots ------ #### [ Console ] **Para criar uma política de ciclo de vida de snapshots** 1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. No painel de navegação, selecione **Elastic Block Store**, **Lifecycle Manager** ((Gerenciador de ciclo de vida) e **Create snapshot lifecycle policy** (Criar política de ciclo de vida de snapshot). 1. Na tela **Select policy type** (Selecionar tipo de política), escolha **EBS snapshot policy** (Política de snapshot do EBS) e depois **Next** (Próximo). 1. Na seção **Target resources** (Recursos de destino), faça o seguinte: 1. Para **Tipos de recursos-alvo**, escolha `Instance`. 1. Para **Tags de recurso-alvo**, especifique as tags de recurso que identificam as instâncias para backup. Só será feito backup dos recursos que têm as tags especificadas. 1. Para a **função do IAM**, escolha **AWSDataLifecycleManagerDefaultRole**(a função padrão para gerenciar instantâneos) ou escolha uma função personalizada que você criou e preparou para scripts anteriores e posteriores. 1. Configure as agendas e as opções adicionais conforme necessário. Recomendamos que você agende a criação dos snapshots para períodos que atendam à sua workload, como durante janelas de manutenção. 1. Na seção **Scripts prévios e posteriores**, selecione **Habilitar scripts prévios e posteriores** e depois faça o seguinte: 1. Selecione **Documento do SSM personalizado**. 1. Para **Opção de automatização**, escolha a opção que corresponde aos scripts que você deseja executar. 1. Para **Documento do SSM**, selecione o documento do SSM que você preparou. 1. Configure as seguintes opções adicionais se necessário: + **Tempo limite do script**: o período limite após o qual o Amazon Data Lifecycle Manager considera que a tentativa de execução do script falhou se ela não foi concluída. Se um script não for concluído dentro do período limite, o Amazon Data Lifecycle Manager considerará que a tentativa falhou. O período de tempo limite se aplica aos scripts prévios e posteriores individualmente. O limite de tempo mínimo e padrão é de 10 segundos. E o tempo limite máximo é de 120 segundos. + **Tentar os scripts com falha novamente**: selecione essa opção para fazer novas tentativas de executar os scripts que não forem concluídos dentro do período de tempo limite. Se o script prévio falhar, o Amazon Data Lifecycle Manager tentará realizar novamente todo o processo de criação de snapshots, incluindo a execução dos scripts prévios e posteriores. Se o script posterior falhar, o Amazon Data Lifecycle Manager fará nova tentativa de executar apenas o script posterior; nesse caso, o script prévio estará sido concluído e o snapshot poderá ter sido criado. + **Usar o padrão de snapshots consistentes em caso de falha**: selecione essa opção para usar padrão de snapshots consistentes em caso de falha se a execução do script prévio falhar. Esse é o comportamento padrão da criação de snapshots para o Amazon Data Lifecycle Manager se os scripts prévios e posteriores não estiverem habilitados. Se você habilitou novas tentativas, o Amazon Data Lifecycle Manager só usará o padrão de snapshots consistentes em caso de falha após esgotar o todas as tentativas. Se o script prévio falhar e você não usar o padrão de snapshots consistentes em caso de falha, o Amazon Data Lifecycle Manager não criará snapshots para a instância durante da execução agendada. 1. Escolha **Criar política padrão**. **nota** Se receber um erro `Role with name AWSDataLifecycleManagerDefaultRole already exists`, consulte [Solucionar problemas do Amazon Data Lifecycle Manager](dlm-troubleshooting.md) para obter mais informações. ------ #### [ AWS CLI ] **Para criar uma política de ciclo de vida de snapshots** Use o [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)comando e inclua os `Scripts` parâmetros em`CreateRule`. Para obter mais informações sobre os parâmetros, consulte [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 ``` Em que `policyDetails.json` inclui o seguinte: ``` { "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 } }] } ``` ------ # Como funcionam os pré-scripts e pós-scripts do Amazon Data Lifecycle Manager A imagem a seguir mostra o fluxograma dos scripts prévios e posteriores ao usar documentos do SSM personalizados. Isso não se aplica aos backups do VSS. ![\[Fluxo de processo dos scripts prévios e posteriores do Amazon Data Lifecycle Manager\]](http://docs.aws.amazon.com/pt_br/ebs/latest/userguide/images/dlm-scripts.png) No horário agendado para a criação dos snapshots, as seguintes ações e interações entre serviços ocorrem. 1. O Amazon Data Lifecycle Manager inicia a ação de script prévio chamando o documento do SSM e passando o parâmetro `pre-script`. **nota** As etapas 1 a 3 só ocorrem se você executar os scripts prévios. Se você executar somente os scripts posteriores, as etapas 1 a 3 serão ignoradas. 1. O Systems Manager envia os comandos do script prévio para o SSM Agent em execução nas instâncias-alvo. O SSM Agent executa os comandos na instância e envia as informações de status de volta ao Systems Manager. Por exemplo, se o documento SSM for usado para criar instantâneos consistentes com aplicativos, o pré-script poderá congelar e ser liberado I/O para garantir que todos os dados armazenados em buffer sejam gravados no volume antes da captura instantânea. 1. O Systems Manager envia atualizações de status dos comandos do script prévio para o Amazon Data Lifecycle Manager. Se o script prévio falhar, o Amazon Data Lifecycle Manager fará uma das seguintes ações, dependendo de como você configurar as opções de script prévio e posterior: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/ebs/latest/userguide/script-flow.html) 1. O Amazon Data Lifecycle Manager inicia a criação de snapshots. 1. O Amazon Data Lifecycle Manager inicia a ação do script posterior chamando o documento do SSM e passando o parâmetro `post-script`. **nota** As etapas 5 a 7 só ocorrem se você executar os scripts prévios. Se você executar somente os scripts posteriores, as etapas 1 a 3 serão ignoradas. 1. O Systems Manager envia os comandos do script posterior para o SSM Agent em execução nas instâncias-alvo. O SSM Agent executa os comandos na instância e envia as informações de status de volta ao Systems Manager. Por exemplo, se o documento SSM permitir instantâneos consistentes com aplicativos, esse pós-script poderá ser descongelado I/O para garantir que seus bancos de dados retomem as operações normais de E/S após a captura instantânea ter sido tirada. 1. Se você executar um script posterior e o Systems Manager indicar que ele foi concluído com sucesso, o processo será concluído. Se o script posterior falhar, o Amazon Data Lifecycle Manager fará uma das seguintes ações, dependendo de como você configurar as opções de script prévio e posterior: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/ebs/latest/userguide/script-flow.html) Lembre-se de que, se o script posterior falhar, o script prévio (se habilitado) será concluído com sucesso e os snapshots poderão ter sido criados. Talvez seja necessário realizar outras ações na instância para garantir que ela esteja operando como esperado. Por exemplo, se o pré-script foi pausado e 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 descarregado. 1. O processo de criação do snapshot talvez seja concluído após a conclusão do script posterior. O tempo necessário para concluir o snapshot depende do tamanho do snapshot. # Identificar snapshots criados com pré-scripts e pós-scripts do Data Lifecycle Manager O Amazon Data Lifecycle Manager atribui automaticamente as seguintes tags do sistema aos snapshots criados com scripts prévios e posteriores. + Chave: `aws:dlm:pre-script`; valor: `SUCCESS`\$1`FAILED` Um valor de tag de `SUCCESS` indica que o script prévio foi executado com sucesso. Um valor de tag de `FAILED` indica que o script prévio não foi executado com sucesso. + Chave: `aws:dlm:post-script`; valor: `SUCCESS`\$1`FAILED` Um valor de tag de `SUCCESS` indica que o script posterior foi executado com sucesso. Um valor de tag de `FAILED` indica que o script posterior não foi executado com sucesso. Para documentos do SSM personalizados e backups do SAP HANA, você pode inferir a criação bem-sucedida de snapshots consistentes com a aplicação se o snapshot estiver marcado com `aws:dlm:pre-script:SUCCESS` e `aws:dlm:post-script:SUCCESS`. Além disso, snapshots consistentes com a aplicação criados usando o backup do VSS são automaticamente marcados com: + Chave: `AppConsistent tag`; valor: `true`\$1`false` Um valor de tag de `true` indica que o backup do VSS foi bem-sucedido e que os snapshots são consistentes com a aplicação. Um valor de tag de `false` indica que o backup do VSS não foi bem-sucedido e que os snapshots não são consistentes com a aplicação. # Monitorar pré-scripts e pós-scripts do Amazon Data Lifecycle Manager **CloudWatch Métricas da Amazon** O Amazon Data Lifecycle Manager publica as seguintes CloudWatch métricas quando os scripts anteriores e posteriores falham e são bem-sucedidos e quando os backups do VSS falham e são bem-sucedidos. + `PreScriptStarted` + `PreScriptCompleted` + `PreScriptFailed` + `PostScriptStarted` + `PostScriptCompleted` + `PostScriptFailed` + `VSSBackupStarted` + `VSSBackupCompleted` + `VSSBackupFailed` Para obter mais informações, consulte [Monitore as políticas do Data Lifecycle Manager usando CloudWatch](monitor-dlm-cw-metrics.md). **Amazon EventBridge** O Amazon Data Lifecycle Manager emite o seguinte evento da EventBridge Amazon quando um script pré ou pós-script é iniciado, é bem-sucedido ou falha + `DLM Pre Post Script Notification` Para obter mais informações, consulte [Monitore as políticas do Data Lifecycle Manager usando EventBridge](monitor-cloudwatch-events.md).