Automatizzazione di snapshot coerenti con l'applicazione con script pre e post - Amazon EBS

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Automatizzazione di snapshot coerenti con l'applicazione con script pre e post

È possibile utilizzare snapshot coerenti con l'applicazione con Amazon Data Lifecycle Manager abilitando gli script pre e post nelle tue policy del ciclo di vita degli snapshot che puntano alle istanze.

Amazon Data Lifecycle Manager si integra con (Systems AWS Systems Manager Manager) per supportare istantanee coerenti con le applicazioni. Amazon Data Lifecycle Manager utilizza documenti di comando Systems Manager (SSM) che includono script pre e post per automatizzare le azioni necessarie per completare gli snapshot coerenti con l'applicazione. Prima che Amazon Data Lifecycle Manager inizi la creazione di snapshot, esegue i comandi nello script pre per bloccare e svuotare l'I/O. Dopo che Amazon Data Lifecycle Manager ha avviato la creazione di snapshot, esegue i comandi nello script post per sbloccare l'I/O.

Utilizzando Amazon Data Lifecycle Manager, puoi automatizzare gli snapshot coerenti con l'applicazione di quanto segue:

  • Applicazioni Windows che utilizzano Volume Shadow Copy Service (VSS)

  • SAP HANA utilizza un documento SSDM gestito. AWS Per ulteriori informazioni, consulta Snapshot Amazon EBS per SAP HANA.

  • Database autogestiti, come MySQL, PostgreSQL o IRIS, utilizzando modelli InterSystems di documenti SSM

Guida introduttiva agli snapshot coerenti con l'applicazione

Questa sezione spiega i passaggi da seguire per automatizzare le istantanee coerenti con le applicazioni utilizzando Amazon Data Lifecycle Manager.

È necessario preparare le istanze di destinazione per gli snapshot coerenti con l'applicazione utilizzando Amazon Data Lifecycle Manager. Completa una delle operazioni riportate di seguito, a seconda del caso d'uso.

Prepare for VSS Backups
Preparazione delle istanze di destinazione per i backup VSS
  1. Installa l'agente SSM sulle istanze di destinazione, se non è già installato. Se l'agente SSM è già installato sulle istanze di destinazione, salta questo passaggio.

    Per ulteriori informazioni, consulta Installazione manuale dell'agente SSM su istanze Amazon EC2 per Windows.

  2. Assicurati che l'agente SSM sia in esecuzione. Per ulteriori informazioni, consulta Verifica dello stato dell'agente SSM e avvio dell'agente.

  3. Configura Systems Manager per le istanze Amazon EC2. Per ulteriori informazioni, consulta Configurazione di Systems Manager per le istanze Amazon EC2 nella Guida per l'utente di AWS Systems Manager .

  4. Assicurati che i requisiti di sistema per i backup VSS siano soddisfatti.

  5. Collega un profilo di istanza abilitato per VSS alle istanze di destinazione.

  6. Installa i componenti VSS.

Prepare for SAP HANA backups
Preparazione delle istanze di destinazione per i backup SAP HANA
  1. Prepara l'ambiente SAP HANA sulle istanze di destinazione.

    1. Configura la tua istanza con SAP HANA. Se non disponi già di un ambiente SAP HANA esistente, puoi fare riferimento a Configurazione dell'ambiente SAP HANA su AWS.

    2. Accedi a SystemDB come utente amministratore adatto.

    3. Crea un utente di backup del database da utilizzare con Amazon Data Lifecycle Manager.

      CREATE USER username PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;

      Ad esempio, il seguente comando crea un utente denominato dlm_user con la password password.

      CREATE USER dlm_user PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
    4. Assegna il ruolo BACKUP OPERATOR all'utente di backup del database creato nel passaggio precedente.

      GRANT BACKUP OPERATOR TO username

      Ad esempio, il comando seguente assegna il ruolo a un utente denominatodlm_user.

      GRANT BACKUP OPERATOR TO dlm_user
    5. Accedi al sistema operativo come amministratore, ad esempio sidadm.

    6. Crea una voce hdbuserstore per memorizzare le informazioni di connessione in modo che il documento SSM di SAP HANA possa connettersi a SAP HANA senza che gli utenti debbano inserire le informazioni.

      hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:3hana_instance_number13 username password

      Per esempio:

      hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:30013 dlm_user password
    7. Esegui il test della connessione.

      hdbsql -U DLM_HANADB_SNAPSHOT_USER "select * from dummy"
  2. Installa l'agente SSM sulle istanze di destinazione, se non è già installato. Se l'agente SSM è già installato sulle istanze di destinazione, salta questo passaggio.

    Per ulteriori informazioni, consulta Installazione manuale dell'agente SSM su istanze Amazon EC2 per Linux.

  3. Assicurati che l'agente SSM sia in esecuzione. Per ulteriori informazioni, consulta Verifica dello stato dell'agente SSM e avvio dell'agente.

  4. Configura Systems Manager per le istanze Amazon EC2. Per ulteriori informazioni, consulta Configurazione di Systems Manager per le istanze Amazon EC2 nella Guida per l'utente di AWS Systems Manager .

Prepare for custom SSM documents
Preparazione dei documenti SSM personalizzati per le istanze di destinazione
  1. Installa l'agente SSM sulle istanze di destinazione, se non è già installato. Se l'agente SSM è già installato sulle istanze di destinazione, salta questo passaggio.

  2. Assicurati che l'agente SSM sia in esecuzione. Per ulteriori informazioni, consulta Verifica dello stato dell'agente SSM e avvio dell'agente.

  3. Configura Systems Manager per le istanze Amazon EC2. Per ulteriori informazioni, consulta Configurazione di Systems Manager per le istanze Amazon EC2 nella Guida per l'utente di AWS Systems Manager .

Nota

Questo passaggio è necessario solo per i documenti SSM personalizzati. Non è richiesto per i backup VSS o SAP HANA. Per i backup VSS e SAP HANA, Amazon Data Lifecycle Manager utilizza il documento SSM gestito. AWS

Se si stanno automatizzando istantanee coerenti con l'applicazione per un database autogestito, come MySQL, PostgreSQL o InterSystems IRIS, è necessario creare un documento di comando SSM che includa uno script pre per bloccare e svuotare l'I/O prima che venga avviata la creazione dello snapshot e un post script per sbloccare l'I/O dopo l'avvio della creazione dello snapshot.

Se il tuo database MySQL, PostgreSQL o IRIS utilizza configurazioni standard InterSystems , puoi creare un documento di comando SSM utilizzando il contenuto del documento SSM di esempio riportato di seguito. Se il database MySQL, PostgreSQL o IRIS utilizza una configurazione non standard InterSystems , è possibile utilizzare il contenuto di esempio riportato di seguito come punto di partenza per il documento di comando SSM e quindi personalizzarlo in base alle proprie esigenze. In alternativa, se desideri creare un nuovo documento SSM da zero, puoi utilizzare il modello di documenti SSM vuoto riportato di seguito e aggiungere i comandi pre e post nelle sezioni appropriate del documento.

Tieni presente quanto segue:
  • È tua responsabilità assicurarti che il documento SSM esegua le azioni corrette e necessarie per la configurazione del database.

  • È garantito che gli snapshot siano coerenti con l'applicazione solo se gli script pre e post del documento SSM riescono a bloccare, svuotare e sbloccare l'I/O con successo.

  • Il documento SSM deve includere i campi obbligatori per allowedValues, tra cui pre-script, post-script e dry-run. Amazon Data Lifecycle Manager eseguirà comandi sull'istanza in base al contenuto di tali sezioni. Se il documento SSM non contiene queste sezioni, Amazon Data Lifecycle Manager lo considererà un'esecuzione non riuscita.

MySQL sample document content
###===============================================================================### # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. # Permission is hereby granted, free of charge, to any person obtaining a copy of this # software and associated documentation files (the "Software"), to deal in the Software # without restriction, including without limitation the rights to use, copy, modify, # merge, publish, distribute, sublicense, and/or sell copies of the Software, and to # permit persons to whom the Software is furnished to do so. # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, # INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A # PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT # HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION # OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE # SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ###===============================================================================### schemaVersion: '2.2' description: Amazon Data Lifecycle Manager Pre/Post script for MySQL databases parameters: executionId: type: String default: None description: (Required) Specifies the unique identifier associated with a pre and/or post execution allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$ command: # Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution. # 'dry-run' option is intended for validating the document execution without triggering any commands # on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully # trigger pre and post script actions. type: String default: 'dry-run' description: (Required) Specifies whether pre-script and/or post-script should be executed. allowedValues: - pre-script - post-script - dry-run mainSteps: - action: aws:runShellScript description: Run MySQL Database freeze/thaw commands name: run_pre_post_scripts precondition: StringEquals: - platformType - Linux inputs: runCommand: - | #!/bin/bash ###===============================================================================### ### Error Codes ###===============================================================================### # The following Error codes will inform Data Lifecycle Manager of the type of error # and help guide handling of the error. # The Error code will also be emitted via AWS Eventbridge events in the 'cause' field. # 1 Pre-script failed during execution - 201 # 2 Post-script failed during execution - 202 # 3 Auto thaw occurred before post-script was initiated - 203 # 4 Pre-script initiated while post-script was expected - 204 # 5 Post-script initiated while pre-script was expected - 205 # 6 Application not ready for pre or post-script initiation - 206 ###=================================================================### ### Global variables ###=================================================================### START=$(date +%s) # For testing this script locally, replace the below with OPERATION=$1. OPERATION={{ command }} FS_ALREADY_FROZEN_ERROR='freeze failed: Device or resource busy' FS_ALREADY_THAWED_ERROR='unfreeze failed: Invalid argument' FS_BUSY_ERROR='mount point is busy' # Auto thaw is a fail safe mechanism to automatically unfreeze the application after the # duration specified in the global variable below. Choose the duration based on your # database application's tolerance to freeze. export AUTO_THAW_DURATION_SECS="60" # Add all pre-script actions to be performed within the function below execute_pre_script() { echo "INFO: Start execution of pre-script" # Check if filesystem is already frozen. No error code indicates that filesystem # is not currently frozen and that the pre-script can proceed with freezing the filesystem. check_fs_freeze # Execute the DB commands to flush the DB in preparation for snapshot snap_db # Freeze the filesystem. No error code indicates that filesystem was succefully frozen freeze_fs echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds." $(nohup bash -c execute_schedule_auto_thaw >/dev/null 2>&1 &) } # Add all post-script actions to be performed within the function below execute_post_script() { echo "INFO: Start execution of post-script" # Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen. unfreeze_fs thaw_db } # Execute Auto Thaw to automatically unfreeze the application after the duration configured # in the AUTO_THAW_DURATION_SECS global variable. execute_schedule_auto_thaw() { sleep ${AUTO_THAW_DURATION_SECS} execute_post_script } # Disable Auto Thaw if it is still enabled execute_disable_auto_thaw() { echo "INFO: Attempting to disable auto thaw if enabled" auto_thaw_pgid=$(pgrep -f execute_schedule_auto_thaw | xargs -i ps -hp {} -o pgid) if [ -n "${auto_thaw_pgid}" ]; then echo "INFO: execute_schedule_auto_thaw process found with pgid ${auto_thaw_pgid}" sudo pkill -g ${auto_thaw_pgid} rc=$? if [ ${rc} != 0 ]; then echo "ERROR: Unable to kill execute_schedule_auto_thaw process. retval=${rc}" else echo "INFO: Auto Thaw has been disabled" fi fi } # Iterate over all the mountpoints and check if filesystem is already in freeze state. # Return error code 204 if any of the mount points are already frozen. check_fs_freeze() { for target in $(lsblk -nlo MOUNTPOINTS) do # Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems. # Hence, we will skip the root and boot mountpoints while checking if filesystem is in freeze state. if [ $target == '/' ]; then continue; fi if [[ "$target" == *"/boot"* ]]; then continue; fi error_message=$(sudo mount -o remount,noatime $target 2>&1) # Remount will be a no-op without a error message if the filesystem is unfrozen. # However, if filesystem is already frozen, remount will fail with busy error message. if [ $? -ne 0 ];then # If the filesystem is already in frozen, return error code 204 if [[ "$error_message" == *"$FS_BUSY_ERROR"* ]];then echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204" exit 204 fi # If the check filesystem freeze failed due to any reason other than the filesystem already frozen, return 201 echo "ERROR: Failed to check_fs_freeze on mountpoint $target due to error - $errormessage" exit 201 fi done } # Iterate over all the mountpoints and freeze the filesystem. freeze_fs() { for target in $(lsblk -nlo MOUNTPOINTS) do # Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze # operations for root and boot mountpoints. if [ $target == '/' ]; then continue; fi if [[ "$target" == *"/boot"* ]]; then continue; fi echo "INFO: Freezing $target" error_message=$(sudo fsfreeze -f $target 2>&1) if [ $? -ne 0 ];then # If the filesystem is already in frozen, return error code 204 if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204" sudo mysql -e 'UNLOCK TABLES;' exit 204 fi # If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201 echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage" thaw_db exit 201 fi echo "INFO: Freezing complete on $target" done } # Iterate over all the mountpoints and unfreeze the filesystem. unfreeze_fs() { for target in $(lsblk -nlo MOUNTPOINTS) do # Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems. # Hence, will skip the root and boot mountpoints during unfreeze as well. if [ $target == '/' ]; then continue; fi if [[ "$target" == *"/boot"* ]]; then continue; fi echo "INFO: Thawing $target" error_message=$(sudo fsfreeze -u $target 2>&1) # Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen. if [ $? -ne 0 ]; then if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205" exit 205 fi # If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202 echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage" exit 202 fi echo "INFO: Thaw complete on $target" done } snap_db() { # Run the flush command only when MySQL DB service is up and running sudo systemctl is-active --quiet mysqld.service if [ $? -eq 0 ]; then echo "INFO: Execute MySQL Flush and Lock command." sudo mysql -e 'FLUSH TABLES WITH READ LOCK;' # If the MySQL Flush and Lock command did not succeed, return error code 201 to indicate pre-script failure if [ $? -ne 0 ]; then echo "ERROR: MySQL FLUSH TABLES WITH READ LOCK command failed." exit 201 fi sync else echo "INFO: MySQL service is inactive. Skipping execution of MySQL Flush and Lock command." fi } thaw_db() { # Run the unlock command only when MySQL DB service is up and running sudo systemctl is-active --quiet mysqld.service if [ $? -eq 0 ]; then echo "INFO: Execute MySQL Unlock" sudo mysql -e 'UNLOCK TABLES;' else echo "INFO: MySQL service is inactive. Skipping execution of MySQL Unlock command." fi } export -f execute_schedule_auto_thaw export -f execute_post_script export -f unfreeze_fs export -f thaw_db # Debug logging for parameters passed to the SSM document echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}" # Based on the command parameter value execute the function that supports # pre-script/post-script operation case ${OPERATION} in pre-script) execute_pre_script ;; post-script) execute_post_script execute_disable_auto_thaw ;; dry-run) echo "INFO: dry-run option invoked - taking no action" ;; *) echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run." exit 1 # return failure ;; esac END=$(date +%s) # Debug Log for profiling the script time echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
PostgreSQL sample document content
###===============================================================================### # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. # Permission is hereby granted, free of charge, to any person obtaining a copy of this # software and associated documentation files (the "Software"), to deal in the Software # without restriction, including without limitation the rights to use, copy, modify, # merge, publish, distribute, sublicense, and/or sell copies of the Software, and to # permit persons to whom the Software is furnished to do so. # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, # INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A # PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT # HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION # OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE # SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ###===============================================================================### schemaVersion: '2.2' description: Amazon Data Lifecycle Manager Pre/Post script for PostgreSQL databases parameters: executionId: type: String default: None description: (Required) Specifies the unique identifier associated with a pre and/or post execution allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$ command: # Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution. # 'dry-run' option is intended for validating the document execution without triggering any commands # on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully # trigger pre and post script actions. type: String default: 'dry-run' description: (Required) Specifies whether pre-script and/or post-script should be executed. allowedValues: - pre-script - post-script - dry-run mainSteps: - action: aws:runShellScript description: Run PostgreSQL Database freeze/thaw commands name: run_pre_post_scripts precondition: StringEquals: - platformType - Linux inputs: runCommand: - | #!/bin/bash ###===============================================================================### ### Error Codes ###===============================================================================### # The following Error codes will inform Data Lifecycle Manager of the type of error # and help guide handling of the error. # The Error code will also be emitted via AWS Eventbridge events in the 'cause' field. # 1 Pre-script failed during execution - 201 # 2 Post-script failed during execution - 202 # 3 Auto thaw occurred before post-script was initiated - 203 # 4 Pre-script initiated while post-script was expected - 204 # 5 Post-script initiated while pre-script was expected - 205 # 6 Application not ready for pre or post-script initiation - 206 ###===============================================================================### ### Global variables ###===============================================================================### START=$(date +%s) OPERATION={{ command }} FS_ALREADY_FROZEN_ERROR='freeze failed: Device or resource busy' FS_ALREADY_THAWED_ERROR='unfreeze failed: Invalid argument' FS_BUSY_ERROR='mount point is busy' # Auto thaw is a fail safe mechanism to automatically unfreeze the application after the # duration specified in the global variable below. Choose the duration based on your # database application's tolerance to freeze. export AUTO_THAW_DURATION_SECS="60" # Add all pre-script actions to be performed within the function below execute_pre_script() { echo "INFO: Start execution of pre-script" # Check if filesystem is already frozen. No error code indicates that filesystem # is not currently frozen and that the pre-script can proceed with freezing the filesystem. check_fs_freeze # Execute the DB commands to flush the DB in preparation for snapshot snap_db # Freeze the filesystem. No error code indicates that filesystem was succefully frozen freeze_fs echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds." $(nohup bash -c execute_schedule_auto_thaw >/dev/null 2>&1 &) } # Add all post-script actions to be performed within the function below execute_post_script() { echo "INFO: Start execution of post-script" # Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen unfreeze_fs } # Execute Auto Thaw to automatically unfreeze the application after the duration configured # in the AUTO_THAW_DURATION_SECS global variable. execute_schedule_auto_thaw() { sleep ${AUTO_THAW_DURATION_SECS} execute_post_script } # Disable Auto Thaw if it is still enabled execute_disable_auto_thaw() { echo "INFO: Attempting to disable auto thaw if enabled" auto_thaw_pgid=$(pgrep -f execute_schedule_auto_thaw | xargs -i ps -hp {} -o pgid) if [ -n "${auto_thaw_pgid}" ]; then echo "INFO: execute_schedule_auto_thaw process found with pgid ${auto_thaw_pgid}" sudo pkill -g ${auto_thaw_pgid} rc=$? if [ ${rc} != 0 ]; then echo "ERROR: Unable to kill execute_schedule_auto_thaw process. retval=${rc}" else echo "INFO: Auto Thaw has been disabled" fi fi } # Iterate over all the mountpoints and check if filesystem is already in freeze state. # Return error code 204 if any of the mount points are already frozen. check_fs_freeze() { for target in $(lsblk -nlo MOUNTPOINTS) do # Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems. # Hence, we will skip the root and boot mountpoints while checking if filesystem is in freeze state. if [ $target == '/' ]; then continue; fi if [[ "$target" == *"/boot"* ]]; then continue; fi error_message=$(sudo mount -o remount,noatime $target 2>&1) # Remount will be a no-op without a error message if the filesystem is unfrozen. # However, if filesystem is already frozen, remount will fail with busy error message. if [ $? -ne 0 ];then # If the filesystem is already in frozen, return error code 204 if [[ "$error_message" == *"$FS_BUSY_ERROR"* ]];then echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204" exit 204 fi # If the check filesystem freeze failed due to any reason other than the filesystem already frozen, return 201 echo "ERROR: Failed to check_fs_freeze on mountpoint $target due to error - $errormessage" exit 201 fi done } # Iterate over all the mountpoints and freeze the filesystem. freeze_fs() { for target in $(lsblk -nlo MOUNTPOINTS) do # Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze # operations for root and boot mountpoints. if [ $target == '/' ]; then continue; fi if [[ "$target" == *"/boot"* ]]; then continue; fi echo "INFO: Freezing $target" error_message=$(sudo fsfreeze -f $target 2>&1) if [ $? -ne 0 ];then # If the filesystem is already in frozen, return error code 204 if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204" exit 204 fi # If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201 echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage" exit 201 fi echo "INFO: Freezing complete on $target" done } # Iterate over all the mountpoints and unfreeze the filesystem. unfreeze_fs() { for target in $(lsblk -nlo MOUNTPOINTS) do # Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems. # Hence, will skip the root and boot mountpoints during unfreeze as well. if [ $target == '/' ]; then continue; fi if [[ "$target" == *"/boot"* ]]; then continue; fi echo "INFO: Thawing $target" error_message=$(sudo fsfreeze -u $target 2>&1) # Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen. if [ $? -ne 0 ]; then if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205" exit 205 fi # If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202 echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage" exit 202 fi echo "INFO: Thaw complete on $target" done } snap_db() { # Run the flush command only when PostgreSQL DB service is up and running sudo systemctl is-active --quiet postgresql if [ $? -eq 0 ]; then echo "INFO: Execute Postgres CHECKPOINT" # PostgreSQL command to flush the transactions in memory to disk sudo -u postgres psql -c 'CHECKPOINT;' # If the PostgreSQL Command did not succeed, return error code 201 to indicate pre-script failure if [ $? -ne 0 ]; then echo "ERROR: Postgres CHECKPOINT command failed." exit 201 fi sync else echo "INFO: PostgreSQL service is inactive. Skipping execution of CHECKPOINT command." fi } export -f execute_schedule_auto_thaw export -f execute_post_script export -f unfreeze_fs # Debug logging for parameters passed to the SSM document echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}" # Based on the command parameter value execute the function that supports # pre-script/post-script operation case ${OPERATION} in pre-script) execute_pre_script ;; post-script) execute_post_script execute_disable_auto_thaw ;; dry-run) echo "INFO: dry-run option invoked - taking no action" ;; *) echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run." exit 1 # return failure ;; esac END=$(date +%s) # Debug Log for profiling the script time echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."
InterSystems IRIS sample document content
###===============================================================================### # MIT License # # Copyright (c) 2024 InterSystems # # Permission is hereby granted, free of charge, to any person obtaining a copy # of this software and associated documentation files (the "Software"), to deal # in the Software without restriction, including without limitation the rights # to use, copy, modify, merge, publish, distribute, sublicense, and/or sell # copies of the Software, and to permit persons to whom the Software is # furnished to do so, subject to the following conditions: # # The above copyright notice and this permission notice shall be included in all # copies or substantial portions of the Software. # # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE # AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE # SOFTWARE. ###===============================================================================### schemaVersion: '2.2' description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature for InterSystems IRIS. parameters: executionId: type: String default: None description: Specifies the unique identifier associated with a pre and/or post execution allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$ command: type: String # Data Lifecycle Manager will trigger the pre-script and post-script actions. You can also use this SSM document with 'dry-run' for manual testing purposes. default: 'dry-run' description: (Required) Specifies whether pre-script and/or post-script should be executed. #The following allowedValues will allow Data Lifecycle Manager to successfully trigger pre and post script actions. allowedValues: - pre-script - post-script - dry-run mainSteps: - action: aws:runShellScript description: Run InterSystems IRIS Database freeze/thaw commands name: run_pre_post_scripts precondition: StringEquals: - platformType - Linux inputs: runCommand: - | #!/bin/bash ###===============================================================================### ### Global variables ###===============================================================================### DOCKER_NAME=iris LOGDIR=./ EXIT_CODE=0 OPERATION={{ command }} START=$(date +%s) # Check if Docker is installed # By default if Docker is present, script assumes that InterSystems IRIS is running in Docker # Leave only the else block DOCKER_EXEC line, if you run InterSystems IRIS non-containerised (and Docker is present). # Script assumes irissys user has OS auth enabled, change the OS user or supply login/password depending on your configuration. if command -v docker &> /dev/null then DOCKER_EXEC="docker exec $DOCKER_NAME" else DOCKER_EXEC="sudo -i -u irissys" fi # Add all pre-script actions to be performed within the function below execute_pre_script() { echo "INFO: Start execution of pre-script" # find all iris running instances iris_instances=$($DOCKER_EXEC iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}') echo "`date`: Running iris instances $iris_instances" # Only for running instances for INST in $iris_instances; do echo "`date`: Attempting to freeze $INST" # Detailed instances specific log LOGFILE=$LOGDIR/$INST-pre_post.log #check Freeze status before starting $DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).IsWDSuspendedExt()" freeze_status=$? if [ $freeze_status -eq 5 ]; then echo "`date`: ERROR: $INST IS already FROZEN" EXIT_CODE=204 else echo "`date`: $INST is not frozen" # Freeze # Docs: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreeze $DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).ExternalFreeze(\"$LOGFILE\",,,,,,600,,,300)" status=$? case $status in 5) echo "`date`: $INST IS FROZEN" ;; 3) echo "`date`: $INST FREEZE FAILED" EXIT_CODE=201 ;; *) echo "`date`: ERROR: Unknown status code: $status" EXIT_CODE=201 ;; esac echo "`date`: Completed freeze of $INST" fi done echo "`date`: Pre freeze script finished" } # Add all post-script actions to be performed within the function below execute_post_script() { echo "INFO: Start execution of post-script" # find all iris running instances iris_instances=$($DOCKER_EXEC iris qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}') echo "`date`: Running iris instances $iris_instances" # Only for running instances for INST in $iris_instances; do echo "`date`: Attempting to thaw $INST" # Detailed instances specific log LOGFILE=$LOGDIR/$INST-pre_post.log #check Freeze status befor starting $DOCKER_EXEC irissession $INST -U '%SYS' "##Class(Backup.General).IsWDSuspendedExt()" freeze_status=$? if [ $freeze_status -eq 5 ]; then echo "`date`: $INST is in frozen state" # Thaw # Docs: https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=Backup.General#ExternalFreeze $DOCKER_EXEC irissession $INST -U%SYS "##Class(Backup.General).ExternalThaw(\"$LOGFILE\")" status=$? case $status in 5) echo "`date`: $INST IS THAWED" $DOCKER_EXEC irissession $INST -U%SYS "##Class(Backup.General).ExternalSetHistory(\"$LOGFILE\")" ;; 3) echo "`date`: $INST THAW FAILED" EXIT_CODE=202 ;; *) echo "`date`: ERROR: Unknown status code: $status" EXIT_CODE=202 ;; esac echo "`date`: Completed thaw of $INST" else echo "`date`: ERROR: $INST IS already THAWED" EXIT_CODE=205 fi done echo "`date`: Post thaw script finished" } # Debug logging for parameters passed to the SSM document echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}" # Based on the command parameter value execute the function that supports # pre-script/post-script operation case ${OPERATION} in pre-script) execute_pre_script ;; post-script) execute_post_script ;; dry-run) echo "INFO: dry-run option invoked - taking no action" ;; *) echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run." # return failure EXIT_CODE=1 ;; esac END=$(date +%s) # Debug Log for profiling the script time echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds." exit $EXIT_CODE

Per ulteriori informazioni, consulta il repository. GitHub

Empty document template
###===============================================================================### # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. # Permission is hereby granted, free of charge, to any person obtaining a copy of this # software and associated documentation files (the "Software"), to deal in the Software # without restriction, including without limitation the rights to use, copy, modify, # merge, publish, distribute, sublicense, and/or sell copies of the Software, and to # permit persons to whom the Software is furnished to do so. # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, # INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A # PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT # HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION # OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE # SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ###===============================================================================### schemaVersion: '2.2' description: SSM Document Template for Amazon Data Lifecycle Manager Pre/Post script feature parameters: executionId: type: String default: None description: (Required) Specifies the unique identifier associated with a pre and/or post execution allowedPattern: ^(None|[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12})$ command: # Data Lifecycle Manager will trigger the pre-script and post-script actions during policy execution. # 'dry-run' option is intended for validating the document execution without triggering any commands # on the instance. The following allowedValues will allow Data Lifecycle Manager to successfully # trigger pre and post script actions. type: String default: 'dry-run' description: (Required) Specifies whether pre-script and/or post-script should be executed. allowedValues: - pre-script - post-script - dry-run mainSteps: - action: aws:runShellScript description: Run Database freeze/thaw commands name: run_pre_post_scripts precondition: StringEquals: - platformType - Linux inputs: runCommand: - | #!/bin/bash ###===============================================================================### ### Error Codes ###===============================================================================### # The following Error codes will inform Data Lifecycle Manager of the type of error # and help guide handling of the error. # The Error code will also be emitted via AWS Eventbridge events in the 'cause' field. # 1 Pre-script failed during execution - 201 # 2 Post-script failed during execution - 202 # 3 Auto thaw occurred before post-script was initiated - 203 # 4 Pre-script initiated while post-script was expected - 204 # 5 Post-script initiated while pre-script was expected - 205 # 6 Application not ready for pre or post-script initiation - 206 ###===============================================================================### ### Global variables ###===============================================================================### START=$(date +%s) # For testing this script locally, replace the below with OPERATION=$1. OPERATION={{ command }} # Add all pre-script actions to be performed within the function below execute_pre_script() { echo "INFO: Start execution of pre-script" } # Add all post-script actions to be performed within the function below execute_post_script() { echo "INFO: Start execution of post-script" } # Debug logging for parameters passed to the SSM document echo "INFO: ${OPERATION} starting at $(date) with executionId: ${EXECUTION_ID}" # Based on the command parameter value execute the function that supports # pre-script/post-script operation case ${OPERATION} in pre-script) execute_pre_script ;; post-script) execute_post_script ;; dry-run) echo "INFO: dry-run option invoked - taking no action" ;; *) echo "ERROR: Invalid command parameter passed. Please use either pre-script, post-script, dry-run." exit 1 # return failure ;; esac END=$(date +%s) # Debug Log for profiling the script time echo "INFO: ${OPERATION} completed at $(date). Total runtime: $((${END} - ${START})) seconds."

Una volta ottenuto il contenuto del documento SSM, utilizza una delle seguenti procedure per creare il documento SSM personalizzato.

Console
Creazione di un documento di comandi SSM
  1. Apri la AWS Systems Manager console all'indirizzo https://console.aws.amazon.com//systems-manager/.

  2. Nel pannello di navigazione, scegli Documenti, quindi scegli Crea documento, Comando o Sessione.

  3. Per Name (Nome), inserire un nome descrittivo per il documento.

  4. Per Tipo di destinazione, seleziona/AWS::EC2::Instance.

  5. Per Tipo di documento, seleziona Comando.

  6. Nel campo Contenuto, seleziona YAML e quindi incolla il contenuto del documento.

  7. Nella sezione Tag del documento, aggiungi un tag con la chiave di tag DLMScriptsAccess e il valore di tag true.

    Importante

    Il DLMScriptsAccess:true tag è richiesto dalla policy AWSDataLifecycleManagerSSMFullAccess AWS gestita utilizzata nella Fase 3: Preparazione del ruolo IAM di Amazon Data Lifecycle Manager. La policy utilizza la chiave di condizione aws:ResourceTag per limitare l'accesso ai documenti SSM che hanno questo tag.

  8. Scegliere Create document (Crea documento).

AWS CLI
Creazione di un documento di comandi SSM

Usa il comando create-document. Per --name, digitare un nome descrittivo per il documento. Per --document-type, specificare Command. Per --content, specifica il percorso del file.yaml con il contenuto del documento SSM. Per --tags, specificare "Key=DLMScriptsAccess,Value=true".

$ aws ssm create-document \ --content file://path/to/file/documentContent.yaml \ --name "document_name" \ --document-type "Command" \ --document-format YAML \ --tags "Key=DLMScriptsAccess,Value=true"
Nota

Questo passaggio è necessario se:

  • Crei o aggiorni una policy di snapshot abilitata per script pre/post che utilizza un ruolo IAM personalizzato.

  • Si utilizza la riga di comando per creare o aggiornare una policy di snapshot abilitata per script pre/post che utilizza il ruolo predefinito.

Se utilizzi la console per creare o aggiornare una policy di snapshot pre/post abilitata agli script che utilizza il ruolo predefinito per la gestione delle istantanee (), salta questo passaggio. AWSDataLifecycleManagerDefaultRole In questo caso, alleghiamo automaticamente la policy a quel ruolo. AWSDataLifecycleManagerSSMFullAccess

Devi assicurarti che il ruolo IAM che usi per le policy conceda ad Amazon Data Lifecycle Manager l'autorizzazione a eseguire le azioni SSM necessarie per eseguire gli script pre e post sulle istanze oggetto della policy.

Amazon Data Lifecycle Manager fornisce una policy gestita (AWSDataLifecycleManagerSSMFullAccess) che include le autorizzazioni richieste. Puoi collegare questa policy al tuo ruolo IAM per la gestione degli snapshot per assicurarti che includa le autorizzazioni.

Importante

La policy AWSDataLifecycleManagerSSMFullAccess gestita utilizza la chiave di aws:ResourceTag condizione per limitare l'accesso a documenti SSM specifici quando si utilizzano script pre e post. Per consentire ad Amazon Data Lifecycle Manager di accedere ai documenti SSM, devi assicurarti che i tuoi documenti SSM siano etichettati con DLMScriptsAccess:true.

In alternativa, puoi creare manualmente una policy personalizzata o assegnare le autorizzazioni richieste direttamente al ruolo IAM utilizzato. È possibile utilizzare le stesse autorizzazioni definite nella politica AWSDataLifecycleManagerSSMFullAccess gestita, tuttavia la chiave di aws:ResourceTag condizione è facoltativa. Se decidi di non utilizzare quella chiave di condizione, non è necessario etichettare i documenti SSM con DLMScriptsAccess:true.

Utilizza uno dei seguenti metodi per aggiungere la AWSDataLifecycleManagerSSMFullAccesspolicy al tuo ruolo IAM.

Console
Collegamento della policy gestita al ruolo personalizzato
  1. Aprire la console IAM all'indirizzo https://console.aws.amazon.com/iam/.

  2. Nel riquadro di navigazione, selezionare Ruoli.

  3. Cerca e seleziona il tuo ruolo personalizzato per la gestione degli snapshot.

  4. Nella scheda Autorizzazioni, scegli Aggiungi autorizzazioni, quindi Collega policy.

  5. Cerca e seleziona la policy AWSDataLifecycleManagerSSMFullAccessgestita, quindi scegli Aggiungi autorizzazioni.

AWS CLI
Collegamento della policy gestita al ruolo personalizzato

Usa il comando attach-role-policy. Per ---role-name, specifica il nome del tuo ruolo personalizzato. Per --policy-arn, specificare arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess.

$ aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \ --role-name your_role_name

Per automatizzare gli snapshot coerenti con l'applicazione, è necessario creare una policy del ciclo di vita degli snapshot destinata alle istanze e configurare gli script pre e post per tale policy.

Console
Creazione di una policy del ciclo di vita dello snapshot
  1. Apri la console Amazon EC2 all'indirizzo https://console.aws.amazon.com/ec2/.

  2. Nel riquadro di navigazione, scegliere Elastic Block Store, Lifecycle Manager, quindi selezionare Create lifecycle policy (Crea policy del ciclo di vita).

  3. Nella schermata Seleziona il tipo di policy, seleziona Policy di snapshot EBS e quindi Successivo.

  4. Nella sezione Risorse di destinazione, procedere come segue:

    1. Per Tipi di risorse di destinazione, scegli Instance.

    2. Per Tag delle risorse interessate, specifica i tag delle risorse che identificano le istanze di cui eseguire il backup. Verrà eseguito il backup solo delle risorse con i tag specificati.

  5. Per il ruolo IAM, scegli AWSDataLifecycleManagerDefaultRole(il ruolo predefinito per la gestione delle istantanee) o scegli un ruolo personalizzato che hai creato e preparato per le fasi precedenti e successive agli script.

  6. Configura le pianificazioni e le opzioni aggiuntive in base alla necessità. Si consiglia di pianificare gli orari di creazione degli snapshot per periodi di tempo corrispondenti al carico di lavoro, ad esempio durante le finestre di manutenzione.

    Per SAP HANA, si consiglia di abilitare il ripristino rapido degli snapshot.

    Nota

    Se abiliti una pianificazione per i backup VSS, non puoi abilitare Escludi volumi di dati specifici o Copia tag dall'origine.

  7. Nella sezione Script pre e post, seleziona Abilita script pre e post, quindi procedi come segue, a seconda del carico di lavoro:

    • Per creare snapshot coerenti con l'applicazione delle applicazioni Windows, seleziona Backup VSS.

    • Per creare snapshot coerenti con l'applicazione dei carichi di lavoro SAP HANA, seleziona SAP HANA.

    • Per creare istantanee coerenti con l'applicazione di tutti gli altri database e carichi di lavoro, inclusi i database MySQL, PostgreSQL o IRIS autogestiti, utilizzando un documento SSM personalizzato, seleziona Documento SSM personalizzato. InterSystems

      1. Per l'Opzione Automatizza, scegli Script pre e post.

      2. Per Documento SSM, seleziona il documento SSM che hai preparato.

  8. A seconda dell'opzione selezionata, configura le seguenti opzioni aggiuntive:

    • Timeout dello script: (solo documento SSM personalizzato) il periodo di timeout dopo il quale Amazon Data Lifecycle Manager fallisce il tentativo di esecuzione dello script se non è stato completato. Se uno script non viene completato entro il periodo di timeout, Amazon Data Lifecycle Manager fallisce il tentativo. Il periodo di timeout si applica ai singoli script pre e post. Il periodo di timeout minimo e predefinito è 10 secondi. E il periodo massimo di timeout è di 120 secondi.

    • Riprova gli script non riusciti: seleziona questa opzione per riprovare gli script che non vengono completati entro il periodo di timeout. Se lo script preliminare fallisce, Amazon Data Lifecycle Manager riprova l'intero processo di creazione degli snapshot, inclusa l'esecuzione degli script pre e post. Se lo script post fallisce, Amazon Data Lifecycle Manager riprova solo lo script post; in questo caso, lo script pre sarà completato e lo snapshot potrebbe essere stato creato.

    • Predefinito su snapshot crash-consistent: seleziona questa opzione per impostare come impostazione predefinita gli snapshot crash-consistent se lo script pre non viene eseguito. Questo è il comportamento di creazione di snapshot predefinito per Amazon Data Lifecycle Manager se gli script pre e post non sono abilitati. Se hai abilitato i nuovi tentativi, Amazon Data Lifecycle Manager utilizzerà per impostazione predefinita gli snapshot crash-consistent solo dopo aver esaurito tutti i tentativi. Se lo script pre non riesce e per impostazione predefinita non utilizzi snapshot crash-consistent, Amazon Data Lifecycle Manager non creerà gli snapshot per l'istanza durante l'esecuzione della pianificazione.

      Nota

      Se stai creando snapshot per SAP HANA, potresti voler disabilitare questa opzione. Gli snapshot crash-consistent dei carichi di lavoro SAP HANA non possono essere ripristinati nello stesso modo.

  9. Scegli Crea policy predefinita.

    Nota

    Se viene restituito l'errore Role with name AWSDataLifecycleManagerDefaultRole already exists, consulta Risoluzione dei problemi per ulteriori informazioni.

AWS CLI
Creazione di una policy del ciclo di vita dello snapshot

Usa il comando create-lifecycle-policy e includi i parametri Scripts in CreateRule. Per ulteriori informazioni sui parametri, consulta la Documentazione di riferimento delle API di Amazon Data Lifecycle Manager.

$ aws dlm create-lifecycle-policy \ --description "policy_description" \ --state ENABLED \ --execution-role-arn iam_role_arn \ --policy-details file://policyDetails.json

Dove policyDetails.json include una delle seguenti operazioni, a seconda del caso d'uso:

  • Backup VSS

    { "PolicyType": "EBS_SNAPSHOT_MANAGEMENT", "ResourceTypes": [ "INSTANCE" ], "TargetTags": [{ "Key": "tag_key", "Value": "tag_value" }], "Schedules": [{ "Name": "schedule_name", "CreateRule": { "CronExpression": "cron_for_creation_frequency", "Scripts": [{ "ExecutionHandler":"AWS_VSS_BACKUP", "ExecuteOperationOnScriptFailure":true|false, "MaximumRetryCount":retries (0-3) }] }, "RetainRule": { "Count": retention_count } }] }
  • Backup di SAP HANA

    { "PolicyType": "EBS_SNAPSHOT_MANAGEMENT", "ResourceTypes": [ "INSTANCE" ], "TargetTags": [{ "Key": "tag_key", "Value": "tag_value" }], "Schedules": [{ "Name": "schedule_name", "CreateRule": { "CronExpression": "cron_for_creation_frequency", "Scripts": [{ "Stages": ["PRE","POST"], "ExecutionHandlerService":"AWS_SYSTEMS_MANAGER", "ExecutionHandler":"AWSSystemsManagerSAP-CreateDLMSnapshotForSAPHANA", "ExecuteOperationOnScriptFailure":true|false, "ExecutionTimeout":timeout_in_seconds (10-120), "MaximumRetryCount":retries (0-3) }] }, "RetainRule": { "Count": retention_count } }] }
  • Documento SSM personalizzato

    { "PolicyType": "EBS_SNAPSHOT_MANAGEMENT", "ResourceTypes": [ "INSTANCE" ], "TargetTags": [{ "Key": "tag_key", "Value": "tag_value" }], "Schedules": [{ "Name": "schedule_name", "CreateRule": { "CronExpression": "cron_for_creation_frequency", "Scripts": [{ "Stages": ["PRE","POST"], "ExecutionHandlerService":"AWS_SYSTEMS_MANAGER", "ExecutionHandler":"ssm_document_name|arn", "ExecuteOperationOnScriptFailure":true|false, "ExecutionTimeout":timeout_in_seconds (10-120), "MaximumRetryCount":retries (0-3) }] }, "RetainRule": { "Count": retention_count } }] }

Considerazioni per i backup VSS con Amazon Data Lifecycle Manager

Con Amazon Data Lifecycle Manager, puoi eseguire il backup e il ripristino di applicazioni Windows abilitate per VSS (Volume Shadow Copy Service) in esecuzione su istanze Amazon EC2. Se un VSS writer è registrato con Windows VSS nell'applicazione, allora il Sistema di gestione del ciclo di vita dei dati Amazon crea uno snapshot che sarà coerente per tale applicazione.

Nota

Attualmente, Amazon Data Lifecycle Manager supporta solo backup coerenti con l'applicazione delle risorse in esecuzione su Amazon EC2, in particolare scenari di backup in cui i dati delle applicazioni possono essere ripristinati sostituendo un'istanza esistente con una nuova istanza creata dal backup. Non tutti i tipi di istanze o applicazioni sono supportati per i backup di Windows VSS. Per ulteriori AWS informazioni, consulta Che cos'è VSS? nella Guida per l'utente di Amazon EC2.

Tipi di istanze non supportati

I seguenti tipi di istanza Amazon EC2 non sono supportati per i backup VSS. Se la tua policy si rivolge a uno di questi tipi di istanze, Amazon Data Lifecycle Manager potrebbe comunque creare backup VSS, ma gli snapshot potrebbero non essere taggati con i tag di sistema richiesti. Senza questi tag, gli snapshot non saranno gestiti da Amazon Data Lifecycle Manager dopo la creazione. Questi snapshot dovranno essere eliminati manualmente.

  • T3: t3.nano | t3.micro

  • T3a: t3a.nano | t3a.micro

  • T2: t2.nano | t2.micro

Responsabilità condivisa per snapshot coerenti a livello di applicazione

È necessario assicurarsi che:
  • L'agente SSM è installato e in esecuzione sulle istanze di destinazione up-to-date

  • Systems Manager disponga delle autorizzazioni per effettuare le operazioni richieste sulle istanze di destinazione

  • Amazon Data Lifecycle Manager abbia l'autorizzazione a eseguire le azioni di Systems Manager necessarie per eseguire gli script pre e post sulle istanze di destinazione.

  • Per i carichi di lavoro personalizzati, come i database MySQL, PostgreSQL o InterSystems IRIS autogestiti, il documento SSM che usi include le azioni corrette e necessarie per il congelamento, lo svuotamento e lo scongelamento degli I/O per la configurazione del database.

  • I tempi di creazione degli snapshot si allineano alla pianificazione del carico di lavoro. Ad esempio, prova a pianificare la creazione di snapshot durante le finestre di manutenzione pianificata.

Amazon Data Lifecycle Manager garantisce che:
  • La creazione degli snapshot viene avviata entro 60 minuti dall'ora pianificata per la creazione dello snapshot.

  • Gli script pre vengono eseguiti prima dell'avvio della creazione dello snapshot.

  • Gli script post vengono eseguiti dopo il completamento dello script pre e l'avvio della creazione dello snapshot. Amazon Data Lifecycle Manager esegue lo script post solo se lo script pre ha esito positivo. Se lo script pre fallisce, Amazon Data Lifecycle Manager non eseguirà lo script post.

  • Gli snapshot vengono taggati con i tag appropriati al momento della creazione.

  • CloudWatch le metriche e gli eventi vengono emessi quando gli script vengono avviati e quando falliscono o hanno esito positivo.