Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Membuat kebijakan khusus Amazon Data Lifecycle Manager untuk snapshot EBS
Prosedur berikut ini menunjukkan cara menggunakan Amazon Data Lifecycle Manager untuk mengotomatisasi siklus hidup snapshot Amazon EBS.
**Topics**
+ [Membuat kebijakan siklus hidup snapshot](#create-snap-policy)
+ [Pertimbangan untuk kebijakan siklus hidup snapshot](#snapshot-considerations)
+ [Sumber daya tambahan](#snapshot-additional-resources)
+ [Otomatiskan snapshot yang konsisten dengan aplikasi](automate-app-consistent-backups.md)
+ [Kasus penggunaan lain untuk skrip pra dan pasca](script-other-use-cases.md)
+ [Cara kerja skrip pra dan pasca](script-flow.md)
+ [Identifikasi snapshot yang dibuat dengan skrip pra dan pasca](dlm-script-tags.md)
+ [Pantau skrip pra dan pasca](dlm-script-monitoring.md)
## Membuat kebijakan siklus hidup snapshot
Gunakan salah satu prosedur berikut ini untuk membuat kebijakan siklus hidup snapshot.
------
#### [ Console ]
**Untuk membuat kebijakan snapshot**
1. Buka konsol Amazon EC2 di. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Di panel navigasi, pilih **Elastic Block Store**, **Lifecycle Manager**, lalu pilih **Buat kebijakan siklus hidup**.
1. Pada layar **Pilih jenis kebijakan**, pilih **Kebijakan snapshot EBS**, lalu pilih **Berikutnya**.
1. Di bagian **Sumber daya target**, lakukan hal berikut ini:
1. Untuk **Jenis sumber daya target**, pilih jenis sumber daya untuk pencadangan. Pilih `Volume` untuk membuat snapshot volume individu atau pilih `Instance` untuk membuat snapshot multi-volume dari volume yang dilampirkan ke suatu instans.
1. (*Outpostdan pelanggan Zona Lokal saja*) Tentukan di mana sumber daya target berada.
Untuk **Lokasi sumber daya target**, tentukan lokasi sumber daya target.
+ Untuk menargetkan sumber daya di Wilayah, pilih **AWS Wilayah**. Amazon Data Lifecycle Manager akan mencadangkan semua sumber daya dari jenis tertentu yang memiliki tag target yang cocok di Wilayah saat ini saja. Snapshot dibuat di Wilayah yang sama.
+ Untuk menargetkan sumber daya di Local Zones, pilih **AWS Local Zones**. Amazon Data Lifecycle Manager akan mencadangkan semua sumber daya dari jenis tertentu yang memiliki tag target yang cocok di semua Local Zones di Wilayah saat ini saja. Snapshot dapat dibuat di Zona Lokal yang sama dengan sumber daya sumber, atau di Wilayah induknya.
+ Untuk menargetkan sumber dayaOutpost, pilih **AWS Outpost**. Amazon Data Lifecycle Manager akan mencadangkan semua sumber daya dari jenis tertentu yang memiliki tag target yang cocok di semua Outposts akun Anda. Snapshot dapat dibuat Outpost sama dengan sumber daya sumber, atau di Wilayah induknya.
1. Untuk **Tanda sumber daya target**, pilih tanda sumber daya yang mengidentifikasi volume atau instans yang akan dicadangkan. Hanya sumber daya yang memiliki pasangan kunci tanda dan nilai yang ditentukan yang dicadangkan oleh kebijakan.
1. Untuk **Deskripsi**, masukkan deskripsi singkat untuk kebijakan tersebut.
1. Untuk **peran IAM**, pilih peran IAM yang memiliki izin untuk mengelola snapshot dan untuk mendeskripsikan volume serta instans. Untuk menggunakan peran default yang disediakan oleh Amazon Data Lifecycle Manager, pilih **Peran default**. Atau, untuk menggunakan peran IAM kustom yang Anda buat sebelumnya, pilih **Pilih peran lain**, lalu pilih peran yang akan digunakan.
1. Untuk **Tanda kebijakan**, tambahkan tanda yang akan diterapkan pada kebijakan siklus hidup. Anda dapat menggunakan tanda ini untuk mengidentifikasi dan mengategorikan kebijakan Anda.
1. Untuk **Status kebijakan**, pilih **Aktifkan** untuk memulai pelaksanaan kebijakan pada waktu yang dijadwalkan berikutnya, atau **Nonaktifkan kebijakan** untuk mencegah agar kebijakan tidak berjalan. Jika Anda tidak mengaktifkan kebijakan sekarang, kebijakan tidak akan mulai membuat snapshot sampai Anda mengaktifkannya secara manual setelah pembuatan.
1. (*Kebijakan yang hanya menargetkan instans*) Kecualikan volume dari set snapshot multi-volume.
Secara default, Amazon Data Lifecycle Manager akan membuat snapshot dari semua volume yang terlampir ke instans yang ditargetkan. Namun, Anda dapat memilih untuk membuat snapshot dari subset volume yang dilampirkan. Di bagian **Parameter**, lakukan hal berikut ini:
+ Jika Anda tidak ingin membuat snapshot dari volume root yang dilampirkan ke instans yang ditargetkan, pilih **Kecualikan volume root**. Jika Anda memilih opsi ini, hanya volume data (non-root) yang dilampirkan ke instans yang ditargetkan yang akan disertakan dalam set snapshot multi-volume.
+ Jika Anda ingin membuat snapshot dari subset volume data (non-root) yang dilampirkan ke instans yang ditargetkan, pilih **Kecualikan volume data tertentu**, lalu tentukan tanda yang akan digunakan untuk mengidentifikasi volume data yang tidak boleh dibuat snapshot. Amazon Data Lifecycle Manager tidak akan membuat snapshot volume data yang memiliki tanda yang ditentukan. Amazon Data Lifecycle Manager hanya akan membuat snapshot dari volume data yang tidak memiliki tanda yang ditentukan.
1. Pilih **Berikutnya**.
1. Pada layar **Konfigurasikan jadwal**, konfigurasikan jadwal kebijakan. Kebijakan dapat memiliki hingga 4 jadwal. Jadwal 1 bersifat wajib. Jadwal 2, 3, dan 4 bersifat opsional. Untuk setiap jadwal kebijakan yang Anda tambahkan, lakukan hal berikut:
1. Dalam bagian **Detail jadwal**, lakukan hal berikut:
1. Untuk **Nama jadwal**, tentukan nama deskriptif untuk jadwal.
1. Untuk **Frekuensi** dan bidang terkait, konfigurasikan interval antara kebijakan yang dijalankan.
Anda dapat mengonfigurasikan kebijakan yang berjalan sesuai jadwal harian, mingguan, bulanan, atau tahunan. Atau, pilih **Ekspresi cron kustom** untuk menentukan interval hingga satu tahun. Untuk informasi selengkapnya, lihat [Cron dan ekspresi nilai](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html) di *Panduan EventBridge Pengguna Amazon*.
**catatan**
Jika Anda perlu mengaktifkan **pengarsipan snapshot** untuk jadwal, Anda harus memilih frekuensi **bulanan** atau **tahunan**, atau Anda harus menentukan ekspresi cron dengan frekuensi pembuatan minimal 28 hari.
Jika menentukan frekuensi bulanan yang membuat snapshot pada hari tertentu dalam minggu tertentu (misalnya, Kamis kedua setiap bulan), untuk jadwal berbasis hitungan, hitungan retensi untuk tingkat arsip harus 4 atau lebih.
1. Untuk **Dimulai pada**, tentukan waktu pelaksanaan kebijakan dijadwalkan untuk dimulai. Pelaksanaan kebijakan pertama dimulai dalam waktu satu jam setelah waktu yang dijadwalkan. Waktu harus dimasukkan dalam format `hh:mm` UTC.
1. Untuk **Jenis retensi**, tentukan kebijakan retensi untuk snapshot yang dibuat berdasarkan jadwal.
Anda dapat mempertahankan snapshot berdasarkan total jumlah atau usianya.
+ Retensi berbasis jumlah
+ Dengan pengarsipan snapshot dinonaktifkan, rentangnya adalah dari `1` hingga `1000`. Saat ambang batas retensi tercapai, snapshot terlama dihapus secara permanen.
+ Dengan pengarsipan snapshot diaktifkan, rentangnya adalah dari `0` (diarsipkan segera setelah pembuatan) hingga `1000`. Saat ambang batas retensi tercapai, snapshot terlama dikonversi ke snapshot penuh dan dipindahkan ke tingkat arsip.
+ Retensi berbasis usia
+ Dengan pengarsipan snapshot dinonaktifkan, rentangnya adalah dari `1` hingga `100` tahun. Saat ambang batas retensi tercapai, snapshot terlama dihapus secara permanen.
+ Dengan pengarsipan snapshot diaktifkan, rentangnya adalah dari `0` hari (diarsipkan segera setelah pembuatan) hingga `100` tahun. Saat ambang batas retensi tercapai, snapshot terlama dikonversi ke snapshot penuh dan dipindahkan ke tingkat arsip.
**catatan**
Semua jadwal harus memiliki jenis retensi yang sama (berbasis usia atau berbasis hitungan). Anda dapat menentukan jenis retensi hanya untuk Jadwal 1. Jadwal 2, 3, dan 4 mewarisi jenis retensi dari Jadwal 1. Setiap jadwal dapat memiliki jumlah atau periode retensi sendiri.
Jika Anda mengaktifkan pemulihan snapshot cepat, salinan lintas Wilayah, atau berbagi snapshot, Anda harus menentukan jumlah retensi `1` atau lebih, atau periode penyimpanan `1` hari atau lebih lama.
1. (*AWS Outposts dan pelanggan Zona Lokal saja*) Tentukan tujuan snapshot.
Untuk **Tujuan snapshot**, tentukan tujuan snapshot yang dibuat oleh kebijakan.
+ Jika kebijakan menargetkan sumber daya di Wilayah, snapshot harus dibuat di Wilayah yang sama. AWS Wilayah dipilih untuk Anda.
+ Jika kebijakan menargetkan sumber daya di Zona Lokal, Anda dapat membuat snapshot di Zona Lokal yang sama dengan sumber daya sumber, atau di Wilayah induknya.
+ Jika kebijakan menargetkan sumber daya di sebuahOutpost, Anda dapat membuat snapshot yang Outpost sama dengan sumber daya sumber, atau di Wilayah induknya.
1. Konfigurasikan penandaan untuk snapshot.
Di bagian **Penandaan**, lakukan hal berikut ini:
1. Untuk menyalin semua tanda yang ditentukan pengguna dari volume sumber ke snapshot yang dibuat oleh jadwal, pilih **Salin tanda dari sumber**.
1. Untuk menentukan tanda tambahan yang akan ditetapkan ke snapshot yang dibuat oleh jadwal ini, pilih **Tambahkan tanda**.
1. Konfigurasikan skrip pra dan pasca untuk snapshot yang konsisten dengan aplikasi.
Untuk informasi selengkapnya, lihat [Mengotomatiskan snapshot yang konsisten dengan aplikasi dengan Data Lifecycle Manager](automate-app-consistent-backups.md).
1. (*Kebijakan yang hanya menargetkan volume*) Konfigurasikan pengarsipan snapshot.
Di bagian **Pengarsipan snapshot**, lakukan hal berikut:
**catatan**
Anda dapat mengaktifkan pengarsipan snapshot hanya untuk satu jadwal dalam kebijakan.
1. Untuk mengaktifkan pengarsipan snapshot untuk jadwal, pilih **Arsipkan snapshot yang dibuat oleh jadwal ini**.
**catatan**
Anda dapat mengaktifkan pengarsipan snapshot hanya jika frekuensi pembuatan snapshot bersifat bulanan atau tahunan, atau jika Anda menentukan ekspresi cron dengan frekuensi pembuatan minimal 28 hari.
1. Tentukan aturan retensi untuk snapshot di tingkat arsip.
+ Untuk **jadwal berbasis jumlah**, tentukan jumlah snapshot yang akan dipertahankan di tingkat arsip. Ketika ambang batas retensi tercapai, snapshot paling lama dihapus secara permanen dari tingkat arsip. Misalnya, jika Anda menentukan 3, jadwal akan mempertahankan maksimal 3 snapshot di tingkat arsip. Ketika snapshot keempat diarsipkan, yang tertua dari tiga snapshot yang ada di tingkat arsip dihapus.
+ Untuk **jadwal berbasis usia**, tentukan periode waktu untuk mempertahankan snapshot di tingkat arsip. Ketika ambang batas retensi tercapai, snapshot paling lama dihapus secara permanen dari tingkat arsip. Misalnya, jika Anda menentukan 120 hari, jadwal akan secara otomatis menghapus snapshot dari tingkat arsip ketika mereka mencapai usia tersebut.
**penting**
Batas penyimpanan snapshot minimum adalah 90 hari. Anda harus menentukan aturan retensi yang mempertahankan snapshot setidaknya selama 90 hari.
1. Aktifkan pemulihan snapshot cepat.
Untuk mengaktifkan pemulihan snapshot cepat untuk snapshot yang dibuat oleh jadwal, di bagian **Pemulihan snapshot cepat**, pilih **Aktifkan pemulihan snapshot cepat**. Jika Anda mengaktifkan pemulihan snapshot cepat, Anda harus memilih Zona Ketersediaan untuk tempat mengaktifkannya. Jika jadwal menggunakan jadwal retensi berbasis usia, Anda harus menentukan periode untuk mengaktifkan pemulihan snapshot cepat untuk setiap snapshot. Jika jadwal menggunakan retensi berbasis jumlah, Anda harus menentukan jumlah maksimal snapshot untuk mengaktifkan pemulihan snapshot cepat.
Jika jadwal membuat snapshot pada fileOutpost, Anda tidak dapat mengaktifkan pemulihan snapshot cepat. Pemulihan snapshot cepat tidak didukung dengan snapshot lokal yang disimpan di file. Outpost
**catatan**
Anda dikenai biaya untuk setiap menit pengaktifan pemulihan snapshot cepat untuk snapshot dalam Zona Ketersediaan tertentu. Biaya bersifat pro-rata minimal satu jam.
1. Konfigurasikan salinan lintas Wilayah.
Untuk menyalin snapshot yang dibuat berdasarkan jadwal ke Outpost atau ke Wilayah lain, di bagian **Salinan Lintas Wilayah, pilih Aktifkan salinan** **Lintas** wilayah.
Jika jadwal membuat snapshot di Wilayah, Anda dapat menyalin snapshot hingga tiga Wilayah tambahan atau Outposts di akun Anda. Anda harus menentukan aturan salinan Lintas wilayah terpisah untuk setiap wilayah tujuan atauOutpost.
Untuk setiap Wilayah atauOutpost, Anda dapat memilih kebijakan penyimpanan yang berbeda dan Anda dapat memilih apakah akan menyalin semua tag atau tidak ada tag. Jika snapshot sumber dienkripsi, atau jika enkripsi secara default diaktifkan, snapshot yang disalin dienkripsi. Jika snapshot sumber tidak dienkripsi, Anda dapat mengaktifkan enkripsi. Jika Anda tidak menentukan kunci KMS, snapshot dienkripsi menggunakan kunci KMS default untuk enkripsi EBS di setiap Wilayah tujuan. Jika Anda menentukan kunci KMS untuk Wilayah tujuan, peran IAM yang dipilih harus memiliki akses ke kunci KMS.
**catatan**
Anda harus memastikan bahwa Anda tidak melebihi jumlah salinan snapshot bersamaan per Wilayah.
Jika kebijakan membuat snapshot di sebuahOutpost, Anda tidak dapat menyalin snapshot ke Wilayah atau ke wilayah lain Outpost dan setelan salinan lintas wilayah tidak tersedia.
1. Konfigurasikan berbagi lintas akun.
Dalam **berbagi lintas akun**, konfigurasikan kebijakan untuk secara otomatis membagikan snapshot yang dibuat oleh jadwal dengan akun lain AWS . Lakukan hal-hal berikut:
1. Untuk mengaktifkan berbagi dengan AWS akun lain, pilih **Aktifkan berbagi lintas akun**.
1. Untuk menambahkan akun yang dapat digunakan untuk berbagi snapshot, pilih **Tambahkan akun**, masukkan 12 digit ID akun AWS , dan pilih **Tambah**.
1. Untuk membatalkan berbagi snapshot yang dibagikan secara otomatis setelah periode tertentu, pilih **Batalkan pembagian secara otomatis**. Jika Anda memilih untuk secara otomatis membatalkan pembagian snapshot yang dinagikan, periode setelah itu untuk secara otomatis membatalkan pembagian snapshot tidak dapat lebih lama dari periode untuk kebijakan mempertahankan snapshotnya. Misalnya, jika konfigurasi retensi kebijakan mempertahankan snapshot selama 5 hari, Anda dapat mengonfigurasi kebijakan untuk secara otomatis membatalkan pembagian snapshot yang dibagikan setelah periode hingga 4 hari. Hal ini berlaku untuk kebijakan dengan konfigurasi penyimpanan snapshot berbasis usia dan jumlah.
Jika Anda tidak mengaktifkan pembatalan pembagian otomatis, snapshot akan dibagikan hingga dihapus.
**catatan**
Anda hanya dapat berbagi snapshot yang tidak dienkripsi atau yang dienkripsi menggunakan kunci yang dikelola pelanggan. Anda tidak dapat berbagi snapshot yang dienkripsi dengan kunci KMS enkripsi EBS default. Jika Anda berbagi snapshot terenkripsi, kemudian Anda juga harus berbagi kunci KMS yang digunakan untuk mengenkripsi volume sumber dengan akun target. Untuk informasi selengkapnya, lihat [Mengizinkan pengguna di akun lain untuk menggunakan kunci KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) di *Panduan Developer AWS Key Management Service *.
1. Untuk menambahkan jadwal tambahan, pilih **Tambahkan jadwal lain**, yang terletak di bagian atas layar. Untuk setiap jadwal tambahan, lengkapi bidang seperti yang dijelaskan sebelumnya dalam topik ini.
1. Setelah Anda menambahkan jadwal yang diperlukan, pilih **Tinjau kebijakan**.
1. Tinjau ringkasan kebijakan, lalu pilih **Buat kebijakan**.
**catatan**
Jika Anda mendapatkan kesalahan `Role with name AWSDataLifecycleManagerDefaultRole already exists`, lihat [Memecahkan masalah Amazon Data Lifecycle Manager](dlm-troubleshooting.md) untuk informasi selengkapnya.
------
#### [ Command line ]
Gunakan [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)perintah untuk membuat kebijakan siklus hidup snapshot. Untuk `PolicyType`, tentukan `EBS_SNAPSHOT_MANAGEMENT`.
**catatan**
Untuk menyederhanakan sintaksis, contoh berikut menggunakan file JSON, `policyDetails.json`, yang mencakup detail kebijakan.
**Contoh 1—Kebijakan siklus hidup snapshot dengan dua jadwal**
Contoh ini membuat kebijakan siklus hidup snapshot yang membubat snapshot dari semua volume yang memiliki kunci tanda `costcenter` dengan nilai `115`. Kebijakan tersebut mencakup dua jadwal. Jadwal pertama membuat snapshot setiap hari pada pukul 03.00 UTC. Jadwal kedua membuat snapshot mingguan setiap Jumat pukul 17.00 UTC.
```
aws dlm create-lifecycle-policy \
--description "My volume policy" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Berikut ini adalah contoh file `policyDetails.json`.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"VOLUME"
],
"TargetTags": [{
"Key": "costcenter",
"Value": "115"
}],
"Schedules": [{
"Name": "DailySnapshots",
"TagsToAdd": [{
"Key": "type",
"Value": "myDailySnapshot"
}],
"CreateRule": {
"Interval": 24,
"IntervalUnit": "HOURS",
"Times": [
"03:00"
]
},
"RetainRule": {
"Count": 5
},
"CopyTags": false
},
{
"Name": "WeeklySnapshots",
"TagsToAdd": [{
"Key": "type",
"Value": "myWeeklySnapshot"
}],
"CreateRule": {
"CronExpression": "cron(0 17 ? * FRI *)"
},
"RetainRule": {
"Count": 5
},
"CopyTags": false
}
]}
```
Jika permintaan berhasil, perintah mengembalikan ID kebijakan yang baru dibuat. Berikut ini adalah output contoh.
```
{
"PolicyId": "policy-0123456789abcdef0"
}
```
**Contoh 2—Kebijakan siklus hidup snapshot yang menargetkan instans dan membuat snapshot dari subset volume data (non-root)**
Contoh ini membuat kebijakan siklus hidup snapshot yang membuat set snapshot multi-volume dari instans yang ditandai dengan `code=production`. Kebijakan ini hanya mencakup satu jadwal. Jadwal tidak membuat snapshot dari volume data yang ditandai dengan `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
```
Berikut ini adalah contoh file `policyDetails.json`.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": [
"INSTANCE"
],
"TargetTags": [{
"Key": "code",
"Value": "production"
}],
"Parameters": {
"ExcludeDataVolumeTags": [{
"Key": "code",
"Value": "temp"
}]
},
"Schedules": [{
"Name": "DailySnapshots",
"TagsToAdd": [{
"Key": "type",
"Value": "myDailySnapshot"
}],
"CreateRule": {
"Interval": 24,
"IntervalUnit": "HOURS",
"Times": [
"03:00"
]
},
"RetainRule": {
"Count": 5
},
"CopyTags": false
}
]}
```
Jika permintaan berhasil, perintah mengembalikan ID kebijakan yang baru dibuat. Berikut ini adalah output contoh.
```
{
"PolicyId": "policy-0123456789abcdef0"
}
```
**Contoh 3—Kebijakan siklus hidup Snapshot yang mengotomatiskan snapshot lokal sumber daya Outpost**
Contoh ini membuat kebijakan siklus hidup snapshot yang membuat snapshot volume yang diberi tag di semua data Anda. `team=dev` Outposts Kebijakan membuat snapshot Outposts sama dengan volume sumber. Kebijakan ini menciptakan snapshot setiap `12` jam mulai pukul `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
```
Berikut ini adalah contoh file `policyDetails.json`.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": "VOLUME",
"ResourceLocations": "OUTPOST",
"TargetTags": [{
"Key": "team",
"Value": "dev"
}],
"Schedules": [{
"Name": "on-site backup",
"CreateRule": {
"Interval": 12,
"IntervalUnit": "HOURS",
"Times": [
"00:00"
],
"Location": [
"OUTPOST_LOCAL"
]
},
"RetainRule": {
"Count": 1
},
"CopyTags": false
}
]}
```
**Contoh 4—Kebijakan siklus hidup snapshot yang membuat snapshot di Wilayah dan menyalinnya ke Outpost**
Kebijakan contoh berikut membuat snapshot volume yang ditandai dengan `team=dev`. Snapshot dibuat di Wilayah yang sama dengan volume sumber. Snapshot dibuat setiap `12` jam mulai pukul `00:00` UTC, dan mempertahankan maksimum `1` snapshot. Kebijakan ini juga menyalin snapshot ke Outpost`arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0`, mengenkripsi snapshot yang disalin menggunakan kunci KMS enkripsi default, dan menyimpan salinannya selama sebulan. `1`
```
aws dlm create-lifecycle-policy \
--description "Copy snapshots to Outpost" \
--state ENABLED \
--execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole \
--policy-details file://policyDetails.json
```
Berikut ini adalah contoh file `policyDetails.json`.
```
{
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"ResourceTypes": "VOLUME",
"ResourceLocations": "CLOUD",
"TargetTags": [{
"Key": "team",
"Value": "dev"
}],
"Schedules": [{
"Name": "on-site backup",
"CopyTags": false,
"CreateRule": {
"Interval": 12,
"IntervalUnit": "HOURS",
"Times": [
"00:00"
],
"Location": "CLOUD"
},
"RetainRule": {
"Count": 1
},
"CrossRegionCopyRules" : [
{
"Target": "arn:aws:outposts:us-east-1:123456789012:outpost/op-1234567890abcdef0",
"Encrypted": true,
"CopyTags": true,
"RetainRule": {
"Interval": 1,
"IntervalUnit": "MONTHS"
}
}]
}
]}
```
**Contoh 5—Kebijakan siklus hidup snapshot dengan jadwal berbasis usia dengan pengarsipan aktif**
Contoh ini membuat kebijakan siklus hidup snapshot yang menargetkan volume yang ditandai dengan `Name=Prod`. Kebijakan ini memiliki satu jadwal berbasis usia yang membuat snapshot pada hari pertama setiap bulan pada pukul 09:00. Jadwal ini mempertahankan setiap snapshot di tingkat standar selama satu hari, setelah itu memindahkannya ke tingkat arsip. Snapshot disimpan di tingkat arsip selama 90 hari sebelum dihapus.
```
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
```
Berikut ini adalah contoh file `policyDetails.json`.
```
{
"ResourceTypes": [ "VOLUME"],
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"Schedules" : [
{
"Name": "sched1",
"TagsToAdd": [
{"Key":"createdby","Value":"dlm"}
],
"CreateRule": {
"CronExpression": "cron(0 9 1 * ? *)"
},
"CopyTags": true,
"RetainRule":{
"Interval": 1,
"IntervalUnit": "DAYS"
},
"ArchiveRule": {
"RetainRule":{
"RetentionArchiveTier": {
"Interval": 90,
"IntervalUnit": "DAYS"
}
}
}
}
],
"TargetTags": [
{
"Key": "Name",
"Value": "Prod"
}
]
}
```
**Contoh 6—Kebijakan siklus hidup snapshot dengan jadwal berbasis jumlah dengan pengarsipan aktif**
Contoh ini membuat kebijakan siklus hidup snapshot yang menargetkan volume yang ditandai dengan `Purpose=Test`. Kebijakan ini memiliki satu jadwal berbasis jumlah yang membuat snapshot pada hari pertama setiap bulan pada pukul 09:00. Jadwal ini mengarsipkan snapshot segera setelah pembuatan dan mempertahankan maksimal tiga snapshot di tingkat arsip.
```
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
```
Berikut ini adalah contoh file `policyDetails.json`.
```
{
"ResourceTypes": [ "VOLUME"],
"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
"Schedules" : [
{
"Name": "sched1",
"TagsToAdd": [
{"Key":"createdby","Value":"dlm"}
],
"CreateRule": {
"CronExpression": "cron(0 9 1 * ? *)"
},
"CopyTags": true,
"RetainRule":{
"Count": 0
},
"ArchiveRule": {
"RetainRule":{
"RetentionArchiveTier": {
"Count": 3
}
}
}
}
],
"TargetTags": [
{
"Key": "Purpose",
"Value": "Test"
}
]
}
```
------
## Pertimbangan untuk kebijakan siklus hidup snapshot
**Pertimbangan umum** berikut ini berlaku untuk snapshot kebijakan siklus hidup:
+ Kebijakan siklus hidup snapshot hanya menargetkan instans atau volume yang berada di Wilayah yang sama dengan kebijakan.
+ Operasi pembuatan snapshot pertama dimulai dalam waktu satu jam setelah waktu mulai yang ditentukan. Operasi pembuatan snapshot selanjutnya dimulai dalam waktu yang dijadwalkan selama satu jam.
+ Anda dapat membuat lebih dari satu kebijakan untuk mencadangkan volume atau instans. Misalnya, jika volume memiliki dua tanda, yaitu tanda *A* adalah target untuk kebijakan *A* untuk membuat snapshot setiap 12 jam, dan tanda *B* adalah target untuk kebijakan *B* untuk membuat snapshot setiap 24 jam, Amazon Data Lifecycle Manager membuat snapshot sesuai jadwal untuk kedua kebijakan. Atau, Anda dapat mencapai hasil yang sama dengan membuat satu kebijakan yang memiliki beberapa jadwal. Misalnya, Anda dapat membuat kebijakan tunggal yang hanya menargetkan tanda *A*, dan menentukan dua jadwal — satu untuk setiap 12 jam dan satu untuk setiap 24 jam.
+ Tanda sumber daya peka huruf besar dan kecil.
+ Jika Anda menghapus tanda target dari sumber daya yang ditargetkan oleh kebijakan, Amazon Data Lifecycle Manager tidak lagi mengelola snapshot yang ada di tingkat standar dan tingkat arsip; Anda harus menghapusnya secara manual jika tidak diperlukan lagi.
+ Jika Anda membuat kebijakan yang menargetkan instans, dan volume baru dilampirkan ke instans target setelah kebijakan dibuat, volume yang baru ditambahkan disertakan dalam pencadangan pada saat pelaksanaan kebijakan berikutnya. Semua volume yang dilampirkan pada instans saat pelaksanaan kebijakan disertakan.
+ Jika Anda membuat kebijakan dengan jadwal berbasis cron kustom yang dikonfigurasi untuk membuat hanya satu snapshot, kebijakan tidak akan secara otomatis menghapus snapshot ketika ambang retensi tercapai. Anda harus menghapus snapshot secara manual jika tidak lagi diperlukan.
+ Jika Anda membuat kebijakan berbasis usia dengan periode retensi lebih pendek dari frekuensi pembuatan, Amazon Data Lifecycle Manager akan selalu mempertahankan snapshot terakhir hingga snapshot berikutnya dibuat. Misalnya, jika kebijakan berbasis usia membuat satu snapshot setiap bulan dengan periode retensi tujuh hari, Amazon Data Lifecycle Manager akan mempertahankan setiap snapshot selama satu bulan, meskipun periode retensi adalah tujuh hari.
Pertimbangan berikut berlaku untuk **[pengarsipan snapshot](snapshot-archive.md)**:
+ Anda dapat mengaktifkan pengarsipan snapshot hanya untuk kebijakan snapshot yang menargetkan volume.
+ Anda dapat menentukan aturan pengarsipan hanya untuk satu jadwal untuk setiap kebijakan.
+ Jika menggunakan konsol, Anda dapat mengaktifkan pengarsipan snapshot hanya jika frekuensi pembuatannya adalah bulanan atau tahunan, atau jika Anda menjadwalkan ekspresi cron dengan frekuensi pembuatan minimal 28 hari.
Jika Anda menggunakan AWS API AWS CLI, atau AWS SDK, Anda dapat mengaktifkan pengarsipan snapshot hanya jika jadwal memiliki ekspresi cron dengan frekuensi pembuatan minimal 28 hari.
+ Periode retensi minimum di tingkat arsip adalah 90 hari.
+ Ketika diarsipkan, snapshot dikonversi ke snapshot penuh ketika dipindahkan ke tingkat arsip. Hal ini dapat mengakibatkan biaya penyimpanan snapshot yang lebih tinggi. Untuk informasi selengkapnya, lihat [Harga dan penagihan untuk pengarsipan snapshot Amazon EBS](snapshot-archive-pricing.md).
+ Pemulihan snapshot cepat dan berbagi snapshot dinonaktifkan untuk snapshot saat diarsipkan.
+ Jika, dalam kasus tahun kabisat, aturan retensi Anda menghasilkan periode penyimpanan arsip kurang dari 90 hari, Amazon Data Lifecycle Manager memastikan bahwa snapshot dipertahankan untuk periode minimum 90 hari.
+ Jika Anda mengarsipkan snapshot yang dibuat oleh Amazon Data Lifecycle Manager secara manual, dan snapshot masih diarsipkan saat ambang retensi jadwal tercapai, Amazon Data Lifecycle Manager tidak lagi mengelola snapshot tersebut. Namun, jika Anda mengembalikan snapshot ke tingkat standar sebelum ambang retensi jadwal tercapai, jadwal akan terus mengelola snapshot sesuai aturan retensi.
+ Jika Anda mengarsipkan snapshot yang dibuat oleh Amazon Data Lifecycle Manager secara manual, dan snapshot masih diarsipkan saat ambang penyimpanan jadwal tercapai, Amazon Data Lifecycle Manager tidak lagi mengelola snapshot tersebut. Namun, jika Anda mengarsipkan ulang snapshot sebelum ambang retensi jadwal tercapai, jadwal akan menghapus snapshot saat ambang retensi terpenuhi.
+ Snapshot yang diarsipkan oleh Amazon Data Lifecycle Manager dihitung terhadap kuota `Archived snapshots per volume` dan `In-progress snapshot archives per account` Anda.
+ Jika jadwal tidak dapat mengarsipkan snapshot setelah mencoba lagi selama 24 jam, snapshot tetap berada di tingkat standar dan dijadwalkan untuk dihapus berdasarkan waktu yang akan dihapus dari tingkat arsip. Misalnya, jika jadwal mengarsipkan snapshot selama 120 hari, snapshot tetap dalam tingkat standar selama 120 hari setelah pengarsipan gagal sebelum dihapus secara permanen. Untuk jadwal berbasis jumlah, snapshot tidak dihitung terhadap jumlah retensi jadwal.
+ Snapshot harus diarsipkan di Wilayah yang sama dengan tempat pembuatannya. Jika Anda mengaktifkan salinan lintas Wilayah dan pengarsipan snapshot, Amazon Data Lifecycle Manager tidak mengarsipkan salinan snapshot.
+ Snapshot yang diarsipkan oleh Amazon Data Lifecycle Manager ditandai dengan tanda sistem `aws:dlm:archived=true`. Selain itu, snapshot yang dibuat oleh jadwal berbasis usia yang diaktifkan arsip ditandai dengan tanda sistem `aws:dlm:expirationTime`, yang menunjukkan tanggal dan waktu snapshot dijadwalkan untuk diarsipkan.
Pertimbangan berikut berlaku untuk **mengecualikan volume root dan volume data (non-root**):
+ Jika Anda memilih untuk mengecualikan volume boot dan Anda menentukan tag yang akibatnya mengecualikan semua volume data tambahan yang dilampirkan ke instance, maka Amazon Data Lifecycle Manager tidak akan membuat snapshot apa pun untuk instance yang terpengaruh, dan akan mengeluarkan metrik. `SnapshotsCreateFailed` CloudWatch Untuk informasi selengkapnya, lihat [Memantau kebijakan menggunakan CloudWatch](monitor-dlm-cw-metrics.md).
Pertimbangan berikut berlaku untuk **menghapus volume atau mengakhiri instans yang ditargetkan oleh kebijakan siklus hidup snapshot**:
+ Jika Anda menghapus volume atau mengakkhiri instans yang ditargetkan oleh kebijakan dengan jadwal retensi berbasis jumlah, Amazon Data Lifecycle Manager tidak lagi mengelola snapshot di tingkat standar dan tingkat arsip yang dibuat dari volume atau instans yang dihapus. Anda harus menghapus snapshot secara manual jika tidak lagi diperlukan.
+ Jika Anda menghapus volume atau mengakhiri instans yang ditargetkan oleh kebijakan dengan jadwal penyimpanan berbasis usia, kebijakan tersebut terus menghapus snapshot dari tingkat standar dan tingkat arsip yang dibuat dari volume atau instans yang dihapus pada jadwal yang ditentukan hingga, tetapi tidak termasuk snapshot terakhir. Anda harus menghapus snapshot secara manual jika tidak lagi diperlukan.
Pertimbangan berikut ini berlaku untuk kebijakan siklus hidup snapshot dan **[pemulihan snapshot cepat](ebs-fast-snapshot-restore.md)**:
+ Amazon Data Lifecycle Manager dapat mengaktifkan pemulihan snapshot cepat hanya untuk snapshot dengan ukuran 16 TiB atau kurang. Untuk informasi selengkapnya, lihat [Pemulihan snapshot cepat Amazon EBS](ebs-fast-snapshot-restore.md).
+ Snapshot yang diaktifkan untuk pemulihan snapshot cepat tetap aktif meskipun Anda menghapus atau menonaktifkan kebijakan, menonaktifkan pemulihan snapshot cepat untuk kebijakan, atau menonaktifkan pemulihan snapshot cepat untuk Zona Ketersediaan. Anda harus menonaktifkan pemulihan snapshot cepat untuk snapshot ini secara manual.
+ Jika Anda mengaktifkan pemulihan snapshot cepat untuk suatu kebijakan dan melebihi jumlah maksimum snapshot yang dapat diaktifkan untuk pemulihan snapshot cepat, Amazon Data Lifecycle Manager membuat snapshot sesuai jadwal, tetapi tidak mengaktifkannya untuk pemulihan snapshot cepat. Setelah snapshot yang diaktifkan untuk pemulihan snapshot cepat dihapus, snapshot berikutnya yang dibuat Amazon Data Lifecycle Manager diaktifkan untuk pemulihan snapshot cepat.
+ Ketika pemulihan snapshot cepat diaktifkan untuk snapshot, hal ini memakan waktu 60 menit per TiB untuk mengoptimalkan snapshot. Sebaiknya konfigurasikan jadwal Anda sehingga setiap snapshot sepenuhnya dioptimalkan sebelum Amazon Data Lifecycle Manager membuat snapshot berikutnya.
+ Jika Anda mengaktifkan pemulihan snapshot cepat untuk kebijakan yang menargetkan instans, Amazon Data Lifecycle Manager mengaktifkan pemulihan snapshot cepat untuk setiap snapshot dalam snapshot multi-volume yang diatur secara individu. Jika gagal mengaktifkan pemulihan snapshot cepat untuk salah satu snapshot dalam set snapshot multi-volume, Amazon Data Lifecycle Manager masih akan mencoba mengaktifkan pemulihan snapshot cepat untuk snapshot yang tersisa dalam set snapshot.
+ Anda dikenai biaya untuk setiap menit pengaktifan pemulihan snapshot cepat untuk snapshot dalam Zona Ketersediaan tertentu. Biaya bersifat pro-rata minimal satu jam. Untuk informasi selengkapnya, lihat [Harga dan Penagihan](ebs-fast-snapshot-restore.md#fsr-pricing).
**catatan**
Bergantung pada konfigurasi kebijakan siklus hidup, Anda dapat mengaktifkan banyak snapshot untuk pemulihan snapshot cepat di banyak Zona Ketersediaan secara bersamaan.
Pertimbangan berikut ini berlaku untuk kebijakan siklus hidup snapshot dan **volume dengan dukungan [Multi-Lampiran](ebs-volumes-multi.md)**:
+ Saat membuat kebijakan siklus hidup yang menargetkan instans yang memiliki volume Multi-Lampiran aktif, Amazon Data Lifecycle Manager memulai snapshot volume untuk setiap instans yang dilampirkan. Gunakan tanda *stempel waktu* untuk mengidentifikasi sejumlah snapshot yang konsisten dengan waktu yang dibuat dari instans yang dilampirkan.
Pertimbangan berikut berlaku untuk **berbagi snapshot antar-akun**:
+ Anda hanya dapat berbagi snapshot yang tidak dienkripsi atau yang dienkripsi menggunakan kunci yang dikelola pelanggan.
+ Anda tidak dapat berbagi snapshot yang dienkripsi dengan kunci KMS enkripsi EBS default.
+ Jika Anda berbagi snapshot terenkripsi, Anda juga harus berbagi kunci KMS yang digunakan untuk mengenkripsi volume sumber dengan akun target. Untuk informasi selengkapnya, lihat [Mengizinkan pengguna di akun lain untuk menggunakan kunci KMS](https://docs.aws.amazon.com//kms/latest/developerguide/key-policy-modifying-external-accounts.html) di *Panduan Developer AWS Key Management Service *.
Pertimbangan berikut berlaku untuk kebijakan snapshot dan **[pengarsipan snapshot](snapshot-archive.md)**:
+ Jika Anda mengarsipkan snapshot yang dibuat oleh kebijakan secara manual, dan snapshot tersebut ada di tingkat arsip saat ambang penyimpanan kebijakan tercapai, Amazon Data Lifecycle Manager tidak akan menghapus snapshot tersebut. Amazon Data Lifecycle Manager tidak mengelola snapshot saat disimpan di tingkat arsip. Jika Anda tidak lagi membutuhkan snapshot yang disimpan di tingkat arsip, Anda harus menghapusnya secara manual.
Pertimbangan berikut berlaku untuk kebijakan snapshot dan [Recycle](recycle-bin.md) Bin:
+ Jika Amazon Data Lifecycle Manager menghapus snapshot dan mengirimkannya ke Keranjang Sampah saat ambang penyimpanan kebijakan tercapai, dan memulihkan snapshot dari Keranjang Sampah secara manual, Anda harus menghapus snapshot tersebut secara manual saat tidak diperlukan lagi. Amazon Data Lifecycle Manager tidak akan lagi mengelola snapshot.
+ Jika Anda menghapus snapshot yang dibuat oleh kebijakan secara manual, dan snapshot tersebut ada di Keranjang Sampah saat ambang penyimpanan kebijakan tercapai, Amazon Data Lifecycle Manager tidak akan menghapus snapshot tersebut. Amazon Data Lifecycle Manager tidak mengelola snapshot saat disimpan di Keranjang Sampah.
Jika snapshot dipulihkan dari Keranjang Sampah sebelum ambang retensi kebijakan tercapai, Amazon Data Lifecycle Manager akan menghapus snapshot tersebut saat ambang retensi kebijakan tercapai.
Jika snapshot dipulihkan dari Keranjang Sampah setelah ambang batas retensi kebijakan tercapai, Amazon Data Lifecycle Manager tidak akan lagi menghapus snapshot tersebut. Anda harus menghapus snapshot secara manual saat tidak lagi diperlukan.
Pertimbangan umum berikut ini berlaku untuk kebijakan siklus hidup snapshot yang berada dalam status **kesalahan**:
+ Untuk kebijakan dengan jadwal retensi berbasis usia, snapshot yang akan kedaluwarsa saat kebijakan berada dalam status `error` akan dipertahankan tanpa batas. Anda harus menghapus snapshot secara manual. Saat Anda mengaktifkan ulang kebijakan, Amazon Data Lifecycle Manager akan melanjutkan penghapusan snapshot karena periode retensinya kedaluwarsa.
+ Untuk kebijakan dengan jadwal retensi berbasis jumlah, kebijakan berhenti membuat dan menghapus AMI saat berada dalam status `error`. Saat Anda mengaktifkan kembali kebijakan, Amazon Data Lifecycle Manager akan melanjutkan pembuatan snapshot, dan melanjutkan penghapusan snapshot saat ambang retensi terpenuhi.
Pertimbangan berikut berlaku untuk kebijakan snapshot dan **[kunci snapshot](ebs-snapshot-lock.md)**:
+ Jika Anda mengunci snapshot yang dibuat secara manual oleh Amazon Data Lifecycle Manager, dan snapshot tersebut masih terkunci ketika ambang batas retensinya tercapai, Amazon Data Lifecycle Manager tidak lagi mengelola snapshot tersebut. Anda harus menghapus snapshot secara manual jika tidak lagi diperlukan.
+ Jika Anda mengunci snapshot secara manual yang dibuat dan diaktifkan untuk pemulihan snapshot cepat oleh Amazon Data Lifecycle Manager, dan snapshot masih terkunci saat ambang batas retensinya tercapai, Amazon Data Lifecycle Manager tidak akan menonaktifkan pemulihan snapshot cepat atau menghapus snapshot. Anda harus menghapus snapshot secara manual jika tidak lagi diperlukan.
+ Jika Anda mendaftarkan snapshot yang dibuat secara manual oleh Amazon Data Lifecycle Manager dengan AMI, lalu mengunci snapshot tersebut, dan snapshot tersebut masih terkunci serta dikaitkan dengan AMI saat ambang batas retensinya tercapai, Amazon Data Lifecycle Manager akan terus berusaha menghapus snapshot tersebut. Ketika AMI dibatalkan pendaftarannya dan snapshot tidak terkunci, Amazon Data Lifecycle Manager akan secara otomatis menghapus snapshot tersebut.
## Sumber daya tambahan
Untuk informasi selengkapnya, lihat [Mengotomatiskan snapshot Amazon EBS dan manajemen AMI menggunakan blog penyimpanan Amazon Data AWS Lifecycle Manager](https://aws.amazon.com/blogs/storage/automating-amazon-ebs-snapshot-and-ami-management-using-amazon-dlm/).
# Mengotomatiskan snapshot yang konsisten dengan aplikasi dengan Data Lifecycle Manager
Anda dapat mengotomatiskan snapshot yang konsisten dengan aplikasi menggunakan Amazon Data Lifecycle Manager dengan mengaktifkan skrip pra dan pasca dalam kebijakan siklus hidup snapshot yang menargetkan instans.
Amazon Data Lifecycle Manager terintegrasi dengan (Systems AWS Systems Manager Manager) untuk mendukung snapshot yang konsisten dengan aplikasi. Amazon Data Lifecycle Manager menggunakan dokumen perintah Systems Manager (SSM) yang menyertakan skrip pra dan pasca untuk mengotomatisasi tindakan yang diperlukan untuk menyelesaikan snapshot yang konsisten dengan aplikasi. Sebelum Amazon Data Lifecycle Manager memulai pembuatan snapshot, ia menjalankan perintah dalam skrip pra untuk membekukan dan menyiram. I/O. After Amazon Data Lifecycle Manager initiates snapshot creation, it runs the commands in the post script to thaw I/O
Menggunakan Amazon Data Lifecycle Manager, Anda dapat mengotomatisasi snapshot yang konsisten dengan aplikasi berikut ini:
+ Aplikasi Windows yang menggunakan Volume Shadow Copy Service (VSS)
+ SAP HANA menggunakan dokumen SSDM AWS terkelola. Untuk informasi selengkapnya, lihat [Snapshot Amazon EBS untuk SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/ebs-sap-hana.html).
+ Database yang dikelola sendiri, seperti MySQL, PostgreSQL atau IRIS, menggunakan templat dokumen SSM InterSystems
**Topics**
+ [Persyaratan untuk menggunakan skrip pra dan pasca](#app-consistent-prereqs)
+ [Memulai snapshot yang konsisten dengan aplikasi](#app-consistent-get-started)
+ [Pertimbangan untuk Pencadangan VSS dengan Amazon Data Lifecycle Manager](#app-consistent-vss)
+ [Tanggung jawab bersama untuk snapshot yang konsisten dengan aplikasi](#shared-responsibility)
## Persyaratan untuk menggunakan skrip pra dan pasca
Tabel berikut menguraikan persyaratan untuk menggunakan skrip pra dan pasca dengan Amazon Data Lifecycle Manager.
| | Snapshot yang konsisten dengan aplikasi | |
| --- |--- |--- |
| Persyaratan | Cadangan VSS | Dokumen SSM Kustom | Kasus penggunaan lainnya |
| --- |--- |--- |--- |
| Agen SSM diinstal dan berjalan pada instance target | ✓ | ✓ | ✓ |
| Persyaratan sistem VSS terpenuhi pada instance target | ✓ | | |
| Profil instans berkemampuan VSS yang terkait dengan instance target | ✓ | | |
| Komponen VSS diinstal pada instance target | ✓ | | |
| Siapkan dokumen SSM dengan perintah skrip pra dan pasca | | ✓ | ✓ |
| Siapkan peran IAM Amazon Data Lifecycle Manager yang menjalankan skrip pra dan pasca | ✓ | ✓ | ✓ |
| Buat kebijakan snapshot yang menargetkan instance dan dikonfigurasi untuk skrip pra dan pasca | ✓ | ✓ | ✓ |
## Memulai snapshot yang konsisten dengan aplikasi
Bagian ini menjelaskan langkah-langkah yang perlu Anda ikuti untuk mengotomatisasi snapshot yang konsisten dengan aplikasi menggunakan Amazon Data Lifecycle Manager.
### Langkah 1: Menyiapkan instans target
Anda perlu menyiapkan instans yang ditargetkan untuk snapshot yang konsisten dengan aplikasi menggunakan Amazon Data Lifecycle Manager. Lakukan salah satu langkah berikut sesuai dengan kasus penggunaan Anda.
------
#### [ Prepare for VSS Backups ]
**Untuk mempersiapkan instans target Anda untuk cadangan VSS**
1. Instal SSM Agent pada instans target Anda, jika belum diinstal. Jika SSM Agent sudah diinstal pada instans target Anda, lewati langkah ini.
Untuk informasi selengkapnya, lihat [Bekerja dengan Agen SSM pada instans EC2 untuk](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) server Windows.
1. Pastikan SSM Agent berjalan. Untuk informasi selengkapnya, lihat [Memeriksa status SSM Agent dan memulai agen](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Siapkan Systems Manager untuk instans Amazon EC2. Untuk informasi selengkapnya, lihat [Menyiapkan Systems Manager untuk instans Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) di *Panduan Pengguna AWS Systems Manager *.
1. [ Pastikan persyaratan sistem untuk cadangan VSS terpenuhi](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-prereqs.html).
1. [ Lampirkan profil instans dengan VSS yang diaktifkan ke instans target](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vss-iam-reqs.html).
1. [ Instal komponen VSS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots-getting-started.html).
------
#### [ Prepare for SAP HANA backups ]
**Untuk mempersiapkan instans target Anda untuk cadangan SAP HANA**
1. Siapkan lingkungan SAP HANA pada instans target Anda.
1. Siapkan instans Anda dengan SAP HANA. Jika Anda belum memiliki lingkungan SAP HANA yang ada, Anda dapat merujuk ke [Penyiapan Lingkungan SAP HANA di AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/std-sap-hana-environment-setup.html).
1. Masuk ke SystemDB sebagai pengguna administrator yang sesuai.
1. Buat pengguna cadangan basis data untuk digunakan dengan Amazon Data Lifecycle Manager.
```
CREATE USER username PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
```
Misalnya, perintah berikut membuat pengguna bernama `dlm_user` dengan kata sandi `password`.
```
CREATE USER dlm_user PASSWORD password NO FORCE_FIRST_PASSWORD_CHANGE;
```
1. Tetapkan `BACKUP OPERATOR` peran ke pengguna cadangan basis data yang Anda buat di langkah sebelumnya.
```
GRANT BACKUP OPERATOR TO username
```
Misalnya, perintah berikut menetapkan peran untuk pengguna bernama `dlm_user`.
```
GRANT BACKUP OPERATOR TO dlm_user
```
1. Masuk ke sistem operasi sebagai administrator, misalnya `sidadm`.
1. Buat entri `hdbuserstore` untuk menyimpan informasi koneksi sehingga dokumen SSM SAP HANA dapat terhubung ke SAP HANA tanpa pengguna harus memasukkan informasi tersebut.
```
hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:3hana_instance_number13 username password
```
Misalnya:
```
hdbuserstore set DLM_HANADB_SNAPSHOT_USER localhost:30013 dlm_user password
```
1. Uji koneksi.
```
hdbsql -U DLM_HANADB_SNAPSHOT_USER "select * from dummy"
```
1. Instal SSM Agent pada instans target Anda, jika belum diinstal. Jika SSM Agent sudah diinstal pada instans target Anda, lewati langkah ini.
Untuk informasi selengkapnya, lihat [Menginstal Agen SSM secara manual pada instans EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) untuk Linux.
1. Pastikan SSM Agent berjalan. Untuk informasi selengkapnya, lihat [Memeriksa status SSM Agent dan memulai agen](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Siapkan Systems Manager untuk instans Amazon EC2. Untuk informasi selengkapnya, lihat [Menyiapkan Systems Manager untuk instans Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) di *Panduan Pengguna AWS Systems Manager *.
------
#### [ Prepare for custom SSM documents ]
**Untuk menyiapkan dokumen SSM kustom instans target Anda**
1. Instal SSM Agent pada instans target Anda, jika belum diinstal. Jika SSM Agent sudah diinstal pada instans target Anda, lewati langkah ini.
+ (Instans Linux) [Menginstal Agen SSM secara manual pada instans EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) untuk Linux
+ (Instans Windows) [Bekerja dengan Agen SSM pada instans EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) untuk Windows Server
1. Pastikan SSM Agent berjalan. Untuk informasi selengkapnya, lihat [Memeriksa status SSM Agent dan memulai agen](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Siapkan Systems Manager untuk instans Amazon EC2. Untuk informasi selengkapnya, lihat [Menyiapkan Systems Manager untuk instans Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) di *Panduan Pengguna AWS Systems Manager *.
------
### Langkah 2: Siapkan Dokumen SSM
**catatan**
Langkah ini hanya diperlukan untuk dokumen SSM kustom. Hal ini tidak diperlukan untuk Cadangan VSS atau SAP HANA. Untuk Pencadangan VSS dan SAP HANA, Amazon Data Lifecycle Manager menggunakan dokumen SSM terkelola. AWS
Jika Anda mengotomatiskan snapshot yang konsisten aplikasi untuk database yang dikelola sendiri, seperti MySQL, PostgreSQL, atau InterSystems IRIS, Anda harus membuat dokumen perintah SSM yang menyertakan skrip pra untuk dibekukan dan disiram I/O sebelum pembuatan snapshot dimulai, dan skrip posting untuk dicairkan setelah pembuatan snapshot dimulai. I/O
Jika database MySQL, PostgreSQL, atau IRIS menggunakan konfigurasi standar InterSystems , Anda dapat membuat dokumen perintah SSM menggunakan contoh konten dokumen SSM di bawah ini. Jika database MySQL, PostgreSQL, atau IRIS Anda menggunakan konfigurasi non-standar InterSystems , Anda dapat menggunakan konten sampel di bawah ini sebagai titik awal untuk dokumen perintah SSM Anda dan kemudian menyesuaikannya untuk memenuhi kebutuhan Anda. Atau, jika Anda ingin membuat dokumen SSM baru dari awal, Anda dapat menggunakan templat dokumen SSM kosong di bawah ini dan menambahkan praperintah dan pascaperintah Anda di bagian dokumen yang sesuai.
**Perhatikan hal-hal berikut:**
Anda bertanggung jawab untuk memastikan bahwa dokumen SSM melakukan tindakan yang benar dan diperlukan untuk konfigurasi basis data Anda.
Snapshot dijamin konsisten aplikasi hanya jika skrip pra dan pasca dalam dokumen SSM Anda berhasil membekukan, menyiram, dan mencairkan I/O.
Dokumen SSM harus menyertakan bidang wajib untuk `allowedValues`, termasuk, `pre-script`, `post-script`, dan `dry-run`. Amazon Data Lifecycle Manager akan menjalankan perintah pada instans Anda berdasarkan konten bagian tersebut. Jika dokumen SSM Anda tidak memiliki bagian tersebut, Amazon Data Lifecycle Manager akan memperlakukannya sebagai eksekusi yang gagal.
------
#### [ 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
```
Untuk informasi lebih lanjut, lihat [GitHub repositori](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."
```
------
Setelah Anda memiliki konten dokumen SSM, gunakan salah satu prosedur berikut untuk membuat dokumen SSM kustom.
------
#### [ Console ]
**Untuk membuat dokumen perintah SSM**
1. Buka AWS Systems Manager konsol di [https://console.aws.amazon.com//systems-manager/](https://console.aws.amazon.com//systems-manager/).
1. Di panel navigasi, pilih **Dokumen**, lalu pilih **Buat dokumen**, **Perintah atau Sesi**.
1. Untuk **Nama**, masukkan nama deskriptif untuk dokumen.
1. Untuk **jenis Target**, pilih**/AWS::EC2::Instance**.
1. Untuk **Jenis dokumen**, pilih **Perintah**.
1. Di bidang **Konten**, pilih **YAML** lalu tempel konten dokumen.
1. Di bagian **Tanda dokumen**, tambahkan tanda dengan kunci tanda `DLMScriptsAccess`, dan nilai tanda `true`.
**penting**
`DLMScriptsAccess:true`Tag diperlukan oleh kebijakan AWS terkelola **AWSDataLifecycleManagerSSMFullAccess** yang digunakan pada *Langkah 3: Siapkan peran IAM Amazon Data Lifecycle Manager*. Kebijakan menggunakan kunci syarat `aws:ResourceTag` untuk membatasi akses ke dokumen SSM yang memiliki tanda ini.
1. Pilih **Buat dokumen**.
------
#### [ AWS CLI ]
**Untuk membuat dokumen perintah SSM**
Gunakan perintah [create-document](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html). Untuk `--name`, tentukan nama deskriptif untuk dokumen. Untuk `--document-type`, tentukan `Command`. Untuk `--content`, tentukan jalur ke file .yaml dengan konten dokumen SSM. Untuk `--tags`, tentukan `"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"
```
------
### Langkah 3: Siapkan peran IAM Amazon Data Lifecycle Manager
**catatan**
Langkah ini diperlukan jika:
Anda membuat atau memperbarui kebijakan snapshot pre/post berkemampuan skrip yang menggunakan peran IAM kustom.
Anda menggunakan baris perintah untuk membuat atau memperbarui kebijakan snapshot pre/post berkemampuan skrip yang menggunakan default.
Jika Anda menggunakan konsol untuk membuat atau memperbarui kebijakan snapshot pre/post berkemampuan skrip yang menggunakan peran default untuk mengelola snapshot (**AWSDataLifecycleManagerDefaultRole**), lewati langkah ini. Dalam hal ini, kami secara otomatis melampirkan kebijakan **AWSDataLifecycleManagerSSMFullAccess** ke peran tersebut.
Anda harus memastikan bahwa peran IAM yang Anda gunakan untuk kebijakan memberikan izin kepada Amazon Data Lifecycle Manager untuk melakukan tindakan SSM yang diperlukan untuk menjalankan skrip pra dan pasca pada instans yang ditargetkan oleh kebijakan.
Amazon Data Lifecycle Manager menyediakan kebijakan terkelola (**AWSDataLifecycleManagerSSMFullAccess**) yang menyertakan izin yang diperlukan. Anda dapat melampirkan kebijakan ini ke peran IAM untuk mengelola snapshot guna memastikan bahwa kebijakan tersebut menyertakan izin.
**penting**
Kebijakan yang dikelola AWSData LifecycleManager SSMFull Access menggunakan kunci `aws:ResourceTag` kondisi untuk membatasi akses ke dokumen SSM tertentu saat menggunakan skrip pra dan pasca. Untuk mengizinkan Amazon Data Lifecycle Manager mengakses dokumen SSM, Anda harus memastikan bahwa dokumen SSM Anda ditandai dengan `DLMScriptsAccess:true`.
Atau, Anda dapat membuat kebijakan kustom secara manual atau menetapkan izin yang diperlukan langsung ke peran IAM yang Anda gunakan. Anda dapat menggunakan izin yang sama yang ditentukan dalam kebijakan terkelola AWSData LifecycleManager SSMFull Access, namun, kunci `aws:ResourceTag` kondisi bersifat opsional. Jika Anda memutuskan untuk tidak menyertakan kunci syarat itu, Anda tidak perlu menandai dokumen SSM Anda dengan `DLMScriptsAccess:true`.
Gunakan salah satu metode berikut untuk menambahkan kebijakan **AWSDataLifecycleManagerSSMFullAccess** ke peran IAM Anda.
------
#### [ Console ]
**Untuk melampirkan kebijakan terkelola ke peran kustom**
1. Buka konsol IAM di [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Di panel navigasi, pilih **Peran**.
1. Cari dan pilih peran kustom Anda untuk mengelola snapshot.
1. Pada tab **Izin**, pilih **Tambahkan izin**, **Lampirkan kebijakan**.
1. Cari dan pilih kebijakan terkelola **AWSDataLifecycleManagerSSMFullAccess**, lalu pilih **Tambah izin**.
------
#### [ AWS CLI ]
**Untuk melampirkan kebijakan terkelola ke peran kustom**
Gunakan perintah [ attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Untuk `---role-name`, tentukan nama peran kustom Anda. Untuk `--policy-arn`, tentukan `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess`.
```
$ aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
```
------
### Langkah 4: Membuat kebijakan siklus hidup snapshot
Untuk mengotomatisasi snapshot yang konsisten dengan aplikasi, Anda harus membuat kebijakan siklus hidup snapshot yang menargetkan instans, dan mengonfigurasi skrip pra dan pasca untuk kebijakan tersebut.
------
#### [ Console ]
**Untuk membuat kebijakan siklus hidup snapshot**
1. Buka konsol Amazon EC2 di. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Di panel navigasi, pilih **Elastic Block Store**, **Lifecycle Manager**, lalu pilih **Buat kebijakan siklus hidup**.
1. Pada layar **Pilih jenis kebijakan**, pilih **Kebijakan snapshot EBS**, lalu pilih **Berikutnya**.
1. Di bagian **Sumber daya target**, lakukan hal berikut ini:
1. Untuk **Jenis sumber daya target**, pilih `Instance`.
1. Untuk **Tanda sumber daya target**, tentukan tanda sumber daya yang mengidentifikasi instans yang akan dicadangkan. Hanya sumber daya yang memiliki tanda tertentu yang akan dicadangkan.
1. Untuk **peran IAM**, pilih **AWSDataLifecycleManagerDefaultRole**(peran default untuk mengelola snapshot), atau pilih peran khusus yang Anda buat dan siapkan untuk skrip pra dan pasca.
1. Konfigurasikan jadwal dan opsi tambahan sesuai kebutuhan. Sebaiknya jadwalkan waktu pembuatan snapshot untuk periode waktu yang sesuai dengan beban kerja Anda, seperti selama jendela pemeliharaan.
Untuk SAP HANA, kami menyarankan Anda mengaktifkan pemulihan snapshot cepat.
**catatan**
Jika Anda mengaktifkan jadwal untuk Cadangan VSS, Anda tidak dapat mengaktifkan **Kecualikan volume data tertentu** atau **Salin tanda dari sumber**.
1. Di bagian **Skrip pra dan pasca**, pilih **Aktifkan skrip pra dan pasca**, lalu lakukan hal berikut, bergantung pada beban kerja Anda:
+ **Untuk membuat snapshot yang konsisten dengan aplikasi dari aplikasi Windows Anda, pilih Cadangan VSS**.
+ **Untuk membuat snapshot yang konsisten dengan aplikasi dari beban kerja SAP HANA Anda, pilih SAP HANA.**
+ **Untuk membuat snapshot yang konsisten dengan aplikasi dari semua database dan beban kerja lainnya, termasuk database MySQL, PostgreSQL, atau IRIS yang dikelola sendiri, menggunakan dokumen SSM kustom, pilih dokumen SSM khusus. InterSystems **
1. Untuk **Opsi otomatisasi**, pilih **Skrip pra dan pasca**.
1. Untuk **Dokumen SSM**, pilih dokumen SSM yang Anda siapkan.
1. Bergantung pada opsi yang Anda pilih, konfigurasikan opsi tambahan berikut:
+ **Batas waktu skrip** — (*Khusus dokumen SSM kustom*) Periode batas waktu sebelum Amazon Data Lifecycle Manager menggagalkan upaya menjalankan skrip jika belum selesai. Jika skrip tidak selesai dalam periode batas waktu, Amazon Data Lifecycle Manager menggagalkan upaya tersebut. Periode batas waktu berlaku untuk skrip pra dan pasca secara individual. Periode batas waktu minimum dan default-nya adalah 10 detik. Dan periode batas waktu maksimumnya adalah 120 detik.
+ **Coba lagi skrip yang gagal** — Pilih opsi ini untuk mencoba lagi skrip yang tidak selesai dalam periode batas waktu. Jika skrip pra gagal, Amazon Data Lifecycle Manager akan mencoba ulang seluruh proses pembuatan snapshot, termasuk menjalankan skrip pra dan pasca. Jika skrip pasca gagal, Amazon Data Lifecycle Manager mencoba ulang skrip pasca saja; dalam hal ini, skrip pra akan selesai dan snapshot mungkin telah dibuat.
+ **Default ke snapshot crash-consistent** — Pilih opsi ini ke default ke snapshot crash-consistent jika skrip pra gagal dijalankan. Ini adalah perilaku pembuatan snapshot default untuk Amazon Data Lifecycle Manager jika skrip pra dan pasca tidak diaktifkan. Jika Anda mengaktifkan percobaan ulang, Amazon Data Lifecycle Manager akan default ke snapshot crash-consistent hanya setelah semua upaya percobaan ulang habis. Jika skrip pra gagal dan Anda tidak menetapkan default ke snapshot crash-consistent, Amazon Data Lifecycle Manager tidak akan membuat snapshot untuk instans selama jadwal berjalan.
**catatan**
Jika Anda membuat snapshot untuk SAP HANA, Anda mungkin ingin menonaktifkan opsi ini. Snapshot crash-consistent dari beban kerja SAP HANA tidak dapat dipulihkan dengan cara yang sama.
1. Pilih **Buat kebijakan default**.
**catatan**
Jika Anda mendapatkan kesalahan `Role with name AWSDataLifecycleManagerDefaultRole already exists`, lihat [Memecahkan masalah Amazon Data Lifecycle Manager](dlm-troubleshooting.md) untuk informasi selengkapnya.
------
#### [ AWS CLI ]
**Untuk membuat kebijakan siklus hidup snapshot**
Gunakan [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)perintah, dan sertakan `Scripts` parameter di`CreateRule`. Untuk informasi selengkapnya tentang parameter, lihat [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
```
Di mana `policyDetails.json` termasuk salah satu hal berikut, tergantung pada kasus penggunaan Anda:
+ **Cadangan 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
}
}]
}
```
+ **Pencadangan 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
}
}]
}
```
+ **Dokumen SSM Kustom**
```
{
"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
}
}]
}
```
------
## Pertimbangan untuk Pencadangan VSS dengan Amazon Data Lifecycle Manager
Dengan Amazon Data Lifecycle Manager, Anda dapat mencadangkan dan memulihkan aplikasi Windows berkemampuan VSS (Volume Shadow Copy Service) yang berjalan di instans Amazon EC2. Jika aplikasi memiliki penulis VSS yang terdaftar dengan Windows VSS, Amazon Data Lifecycle Manager membuat snapshot yang akan bersifat konsisten aplikasi untuk aplikasi itu.
**catatan**
Amazon Data Lifecycle Manager saat ini mendukung snapshot sumber daya yang konsisten aplikasi yang berjalan di Amazon EC2 saja, khusus untuk skenario pencadangan di mana data aplikasi dapat dipulihkan dengan mengganti instans yang ada dengan instans baru yang dibuat dari cadangan. Tidak semua tipe instans atau aplikasi didukung untuk pencadangan VSS. *Untuk informasi selengkapnya, lihat [snapshot Windows VSS yang konsisten dengan aplikasi di Panduan Pengguna](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html) Amazon EC2.*
**Tipe instans yang didukung**
Tipe instans Amazon EC2 berikut tidak didukung untuk pencadangan VSS. Jika kebijakan Anda menargetkan salah satu tipe instans ini, Amazon Data Lifecycle Manager mungkin masih membuat cadangan VSS, tetapi snapshot mungkin tidak ditandai dengan tanda sistem yang diperlukan. Tanpa tanda ini, snapshot tidak akan dikelola oleh Amazon Data Lifecycle Manager setelah pembuatan. Anda mungkin perlu menghapus snapshot tersebut secara manual.
+ T3: \$1 `t3.nano` `t3.micro`
+ T3a: \$1 `t3a.nano` `t3a.micro`
+ T2: \$1 `t2.nano` `t2.micro`
## Tanggung jawab bersama untuk snapshot yang konsisten dengan aplikasi
**Anda harus memastikan bahwa:**
+ Agen SSM diinstal, up-to-date, dan berjalan pada instance target Anda
+ Systems Manager memiliki izin untuk melakukan tindakan yang diperlukan pada instans target
+ Amazon Data Lifecycle Manager memiliki izin untuk melakukan tindakan Systems Manager yang diperlukan untuk menjalankan skrip pra dan pasca pada instans target.
+ Untuk beban kerja kustom, seperti database MySQL, PostgreSQL, atau InterSystems IRIS yang dikelola sendiri, dokumen SSM yang Anda gunakan menyertakan tindakan yang benar dan diperlukan untuk pembekuan, pembilasan, dan pencairan konfigurasi database Anda. I/O
+ Waktu pembuatan snapshot selaras dengan jadwal beban kerja Anda. Misalnya, cobalah untuk menjadwalkan pembuatan snapshot selama jendela pemeliharaan terjadwal.
**Amazon Data Lifecycle Manager memastikan bahwa:**
+ Pembuatan snapshot dimulai dalam waktu 60 menit dari waktu pembuatan snapshot yang dijadwalkan.
+ Skrip pra dijalankan sebelum pembuatan snapshot dimulai.
+ Skrip pasca berjalan setelah skrip pra berhasil dan pembuatan snapshot telah dimulai. Amazon Data Lifecycle Manager menjalankan skrip pasca hanya jika skrip pra berhasil. Jika skrip pra gagal, Amazon Data Lifecycle Manager tidak akan menjalankan skrip pasca.
+ Snapshot ditandai dengan tanda yang sesuai pada pembuatan.
+ CloudWatch metrik dan peristiwa dipancarkan ketika skrip dimulai, dan ketika mereka gagal atau berhasil.
# Kasus penggunaan lain untuk skrip pra dan pasca Manajer Siklus Hidup Data
Selain menggunakan skrip pra dan pasca untuk mengotomatiskan snapshot yang konsisten dengan aplikasi, Anda dapat menggunakan skrip pra dan pasca bersama-sama, atau secara individual, untuk mengotomatiskan tugas administratif lainnya sebelum atau sesudah pembuatan snapshot. Misalnya:
+ Menggunakan skrip pra untuk menerapkan patch sebelum membuat snapshot. Ini dapat membantu Anda membuat snapshot setelah menerapkan pembaruan perangkat lunak mingguan atau bulanan reguler Anda.
**catatan**
Jika Anda memilih untuk menjalankan skrip pra saja, **Tetapkan default ke snapshot crash-consistent** diaktifkan secara default.
+ Menggunakan skrip pasca untuk menerapkan patch sebelum membuat snapshot. Ini dapat membantu Anda membuat snapshot setelah menerapkan pembaruan perangkat lunak mingguan atau bulanan reguler Anda.
## Memulai untuk kasus penggunaan lainnya
Bagian ini menjelaskan langkah-langkah yang perlu Anda lakukan saat menggunakan skrip pra and/or posting untuk **kasus penggunaan selain snapshot yang konsisten dengan aplikasi**.
### Langkah 1: Menyiapkan instans target
**Untuk mempersiapkan instance target Anda untuk skrip pra and/or posting**
1. Instal SSM Agent pada instans target Anda, jika belum diinstal. Jika SSM Agent sudah diinstal pada instans target Anda, lewati langkah ini.
+ (Instans Linux) [Menginstal Agen SSM secara manual pada instans EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) untuk Linux
+ (Instans Windows) [Bekerja dengan Agen SSM pada instans EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-windows.html) untuk Windows Server
1. Pastikan SSM Agent berjalan. Untuk informasi selengkapnya, lihat [Memeriksa status SSM Agent dan memulai agen](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
1. Siapkan Systems Manager untuk instans Amazon EC2. Untuk informasi selengkapnya, lihat [Menyiapkan Systems Manager untuk instans Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) di *Panduan Pengguna AWS Systems Manager *.
### Langkah 2: Siapkan Dokumen SSM
Anda harus membuat dokumen perintah SSM yang menyertakan skrip pra and/or posting dengan perintah yang ingin Anda jalankan.
Anda dapat membuat dokumen SSM menggunakan templat dokumen SSM kosong di bawah ini dan menambahkan perintah pra dan pasca Anda di bagian dokumen yang sesuai.
**Perhatikan hal-hal berikut:**
Anda bertanggung jawab untuk memastikan bahwa dokumen SSM melakukan tindakan yang benar dan diperlukan untuk beban kerja Anda.
Dokumen SSM harus menyertakan bidang wajib untuk `allowedValues`, termasuk, `pre-script`, `post-script`, dan `dry-run`. Amazon Data Lifecycle Manager akan menjalankan perintah pada instans Anda berdasarkan konten bagian tersebut. Jika dokumen SSM Anda tidak memiliki bagian tersebut, Amazon Data Lifecycle Manager akan memperlakukannya sebagai eksekusi yang gagal.
```
###===============================================================================###
# 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."
```
### Langkah 3: Siapkan peran IAM Amazon Data Lifecycle Manager
**catatan**
Langkah ini diperlukan jika:
Anda membuat atau memperbarui kebijakan snapshot pre/post berkemampuan skrip yang menggunakan peran IAM kustom.
Anda menggunakan baris perintah untuk membuat atau memperbarui kebijakan snapshot pre/post berkemampuan skrip yang menggunakan default.
Jika Anda menggunakan konsol untuk membuat atau memperbarui kebijakan snapshot pre/post berkemampuan skrip yang menggunakan peran default untuk mengelola snapshot (**AWSDataLifecycleManagerDefaultRole**), lewati langkah ini. Dalam hal ini, kami secara otomatis melampirkan kebijakan **AWSDataLifecycleManagerSSMFullAccess** ke peran tersebut.
Anda harus memastikan bahwa peran IAM yang Anda gunakan untuk kebijakan memberikan izin Amazon Data Lifecycle Manager untuk melakukan tindakan SSM yang diperlukan untuk menjalankan skrip pra dan pasca pada instans yang ditargetkan oleh kebijakan.
Amazon Data Lifecycle Manager menyediakan kebijakan terkelola (**AWSDataLifecycleManagerSSMFullAccess**) yang menyertakan izin yang diperlukan. Anda dapat melampirkan kebijakan ini ke peran IAM untuk mengelola snapshot guna memastikan bahwa kebijakan tersebut menyertakan izin.
**penting**
Kebijakan yang dikelola AWSData LifecycleManager SSMFull Access menggunakan kunci `aws:ResourceTag` kondisi untuk membatasi akses ke dokumen SSM tertentu saat menggunakan skrip pra dan pasca. Untuk mengizinkan Amazon Data Lifecycle Manager mengakses dokumen SSM, Anda harus memastikan bahwa dokumen SSM Anda ditandai dengan `DLMScriptsAccess:true`.
Atau, Anda dapat membuat kebijakan kustom secara manual atau menetapkan izin yang diperlukan langsung ke peran IAM yang Anda gunakan. Anda dapat menggunakan izin yang sama yang ditentukan dalam kebijakan terkelola AWSData LifecycleManager SSMFull Access, namun, kunci `aws:ResourceTag` kondisi bersifat opsional. Jika Anda memutuskan untuk tidak menyertakan kunci syarat itu, Anda tidak perlu menandai dokumen SSM Anda. `DLMScriptsAccess:true`
Gunakan salah satu metode berikut untuk menambahkan kebijakan **AWSDataLifecycleManagerSSMFullAccess** ke peran IAM Anda.
------
#### [ Console ]
**Untuk melampirkan kebijakan terkelola ke peran kustom**
1. Buka konsol IAM di [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Di panel navigasi, pilih **Peran**.
1. Cari dan pilih peran kustom Anda untuk mengelola snapshot.
1. Pada tab **Izin**, pilih **Tambahkan izin**, **Lampirkan kebijakan**.
1. Cari dan pilih kebijakan terkelola **AWSDataLifecycleManagerSSMFullAccess**, lalu pilih **Tambah izin**.
------
#### [ AWS CLI ]
**Untuk melampirkan kebijakan terkelola ke peran kustom**
Gunakan perintah [ attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html). Untuk `---role-name`, tentukan nama peran kustom Anda. Untuk `--policy-arn`, tentukan `arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess`.
```
$ aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AWSDataLifecycleManagerSSMFullAccess \
--role-name your_role_name
```
------
### Membuat kebijakan siklus hidup snapshot
------
#### [ Console ]
**Untuk membuat kebijakan siklus hidup snapshot**
1. Buka konsol Amazon EC2 di. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Di panel navigasi, pilih **Elastic Block Store**, **Lifecycle Manager**, lalu pilih **Buat kebijakan siklus hidup**.
1. Pada layar **Pilih jenis kebijakan**, pilih **Kebijakan snapshot EBS**, lalu pilih **Berikutnya**.
1. Di bagian **Sumber daya target**, lakukan hal berikut ini:
1. Untuk **Jenis sumber daya target**, pilih `Instance`.
1. Untuk **Tanda sumber daya target**, tentukan tanda sumber daya yang mengidentifikasi instans yang akan dicadangkan. Hanya sumber daya yang memiliki tanda tertentu yang akan dicadangkan.
1. Untuk **peran IAM**, pilih **AWSDataLifecycleManagerDefaultRole**(peran default untuk mengelola snapshot), atau pilih peran khusus yang Anda buat dan siapkan untuk skrip pra dan pasca.
1. Konfigurasikan jadwal dan opsi tambahan sesuai kebutuhan. Sebaiknya jadwalkan waktu pembuatan snapshot untuk periode waktu yang sesuai dengan beban kerja Anda, seperti selama jendela pemeliharaan.
1. Di bagian **Skrip pra dan pasca**, pilih **Aktifkan skrip pra dan pasca**, lalu lakukan hal berikut:
1. Pilih **Dokumen SSM Kustom**.
1. Untuk **Opsi otomatis**, pilih opsi yang cocok dengan skrip yang ingin Anda jalankan.
1. Untuk **Dokumen SSM**, pilih dokumen SSM yang Anda siapkan.
1. Konfigurasikan opsi tambahan berikut jika diperlukan:
+ **Batas waktu skrip** - Periode batas waktu setelah Amazon Data Lifecycle Manager menggagalkan upaya menjalankan skrip jika belum selesai. Jika skrip tidak selesai dalam periode batas waktu, Amazon Data Lifecycle Manager menggagalkan upaya tersebut. Periode batas waktu berlaku untuk skrip pra dan pasca secara individual. Periode batas waktu minimum dan default-nya adalah 10 detik. Dan periode batas waktu maksimumnya adalah 120 detik.
+ **Coba lagi skrip yang gagal** — Pilih opsi ini untuk mencoba lagi skrip yang tidak selesai dalam periode batas waktu. Jika skrip pra gagal, Amazon Data Lifecycle Manager akan mencoba ulang seluruh proses pembuatan snapshot, termasuk menjalankan skrip pra dan pasca. Jika skrip pasca gagal, Amazon Data Lifecycle Manager mencoba ulang skrip pasca saja; dalam hal ini, skrip pra akan selesai dan snapshot mungkin telah dibuat.
+ **Default ke snapshot crash-consistent** — Pilih opsi ini ke default ke snapshot crash-consistent jika skrip pra gagal dijalankan. Ini adalah perilaku pembuatan snapshot default untuk Amazon Data Lifecycle Manager jika skrip pra dan pasca tidak diaktifkan. Jika Anda mengaktifkan percobaan ulang, Amazon Data Lifecycle Manager akan default ke snapshot crash-consistent hanya setelah semua upaya percobaan ulang habis. Jika skrip pra gagal dan Anda tidak menetapkan default ke snapshot crash-consistent, Amazon Data Lifecycle Manager tidak akan membuat snapshot untuk instans selama jadwal berjalan.
1. Pilih **Buat kebijakan default**.
**catatan**
Jika Anda mendapatkan kesalahan `Role with name AWSDataLifecycleManagerDefaultRole already exists`, lihat [Memecahkan masalah Amazon Data Lifecycle Manager](dlm-troubleshooting.md) untuk informasi selengkapnya.
------
#### [ AWS CLI ]
**Untuk membuat kebijakan siklus hidup snapshot**
Gunakan [create-lifecycle-policy](https://docs.aws.amazon.com/cli/latest/reference/dlm/create-lifecycle-policy.html)perintah, dan sertakan `Scripts` parameter di`CreateRule`. Untuk informasi selengkapnya tentang parameter, lihat [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
```
Di mana `policyDetails.json` termasuk yang berikut.
```
{
"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
}
}]
}
```
------
# Cara kerja skrip pra dan pasca Amazon Data Lifecycle Manager
Gambar berikut menunjukkan alur proses untuk skrip pra dan pasca saat menggunakan dokumen SSM kustom. Hal ini tidak berlaku untuk Pencadangan VSS.
![\[Alur proses skrip pra dan pasca Amazon Data Lifecycle Manager\]](http://docs.aws.amazon.com/id_id/ebs/latest/userguide/images/dlm-scripts.png)
Pada waktu pembuatan snapshot yang dijadwalkan, tindakan berikut dan interaksi lintas layanan terjadi.
1. Amazon Data Lifecycle Manager memulai tindakan skrip pra dengan memanggil dokumen SSM dan meneruskan parameter `pre-script`.
**catatan**
Langkah 1 hingga 3 hanya terjadi jika Anda menjalankan skrip pra. Jika Anda menjalankan skrip pasca saja, langkah 1 hingga 3 dilewati.
1. Systems Manager mengirimkan perintah pra skrip ke SSM Agent yang berjalan pada instans target. SSM Agent menjalankan perintah pada instans, dan mengirimkan informasi status kembali ke Systems Manager.
Misalnya, jika dokumen SSM digunakan untuk membuat snapshot yang konsisten dengan aplikasi, skrip pra mungkin membeku dan rata I/O untuk memastikan bahwa semua data buffer ditulis ke volume sebelum snapshot diambil.
1. Systems Manager mengirimkan pembaruan status perintah skrip pra ke Amazon Data Lifecycle Manager. Jika skrip pra gagal, Amazon Data Lifecycle Manager mengambil salah satu tindakan berikut, tergantung pada cara Anda mengonfigurasi opsi skrip pra dan pasca:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/ebs/latest/userguide/script-flow.html)
1. Amazon Data Lifecycle Manager memulai pembuatan snapshot.
1. Amazon Data Lifecycle Manager memulai tindakan pasca skrip dengan memanggil dokumen SSM dan meneruskan parameter `post-script`.
**catatan**
Langkah 5 hingga 7 hanya terjadi jika Anda menjalankan skrip pra. Jika Anda menjalankan skrip pasca saja, langkah 1 hingga 3 dilewati.
1. Systems Manager mengirimkan perintah post script ke SSM Agent yang berjalan pada instans target. SSM Agent menjalankan perintah pada instans, dan mengirimkan informasi status kembali ke Systems Manager.
Misalnya, jika dokumen SSM mengaktifkan snapshot yang konsisten dengan aplikasi, skrip posting ini mungkin mencair I/O untuk memastikan bahwa database Anda melanjutkan operasi I/O normal setelah snapshot diambil.
1. Jika Anda menjalankan skrip pasca dan Systems Manager menunjukkan bahwa itu selesai dengan sukses, proses selesai.
Jika skrip pasca gagal, Amazon Data Lifecycle Manager mengambil salah satu tindakan berikut, tergantung pada cara Anda mengonfigurasi opsi skrip pra dan pasca:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/ebs/latest/userguide/script-flow.html)
Perlu diingat bahwa jika skrip pasca gagal, skrip pra (jika diaktifkan) akan berhasil diselesaikan, dan snapshot mungkin telah dibuat. Anda mungkin perlu mengambil tindakan lebih lanjut pada instans untuk memastikan bahwa itu beroperasi seperti yang diharapkan. Misalnya jika skrip pra berhenti dan memerah. I/O, but the post script failed to thaw I/O, you might need to configure your database to auto-thaw I/O or you need to manually thaw I/O
1. Proses pembuatan snapshot mungkin selesai setelah skrip pasca selesai. Waktu yang dibutuhkan untuk menyelesaikan snapshot tergantung pada ukuran snapshot.
# Identifikasi snapshot yang dibuat dengan skrip pra dan pasca Data Lifecycle Manager
Amazon Data Lifecycle Manager secara otomatis menetapkan tanda sistem berikut ke snapshot yang dibuat dengan skrip pra dan pasca.
+ Nilai: `aws:dlm:pre-script`; Kunci: `SUCCESS`\$1`FAILED`
Nilai tanda `SUCCESS` menunjukkan bahwa skrip pra berhasil dieksekusi. Nilai tanda `FAILED` menunjukkan bahwa skrip pra gagal dieksekusi.
+ Nilai: `aws:dlm:post-script`; Kunci: `SUCCESS`\$1`FAILED`
Nilai tanda `SUCCESS` menunjukkan bahwa skrip pasca berhasil dieksekusi. Nilai tanda `FAILED` menunjukkan bahwa skrip pasca gagal dieksekusi.
Untuk dokumen SSM kustom dan cadangan SAP HANA, Anda dapat menyimpulkan pembuatan snapshot yang konsisten aplikasi yang berhasil jika snapshot ditandai dengan `aws:dlm:pre-script:SUCCESS` dan `aws:dlm:post-script:SUCCESS`.
Selain itu, snapshot konsisten aplikasi yang dibuat menggunakan cadangan VSS secara otomatis ditandai dengan:
+ Nilai: `AppConsistent tag`; Kunci: `true`\$1`false`
Nilai tanda `true` menunjukkan bahwa pencadangan VSS berhasil dan bahwa snapshot bersifat konsisten aplikasi. Nilai tanda `false` menunjukkan bahwa pencadangan VSS gagal dan bahwa snapshot tidak bersifat konsisten aplikasi.
# Pantau skrip pra dan pasca Amazon Data Lifecycle Manager
**CloudWatch Metrik Amazon**
Amazon Data Lifecycle Manager menerbitkan CloudWatch metrik berikut saat skrip pra dan pasca gagal dan berhasil serta saat pencadangan VSS gagal dan berhasil.
+ `PreScriptStarted`
+ `PreScriptCompleted`
+ `PreScriptFailed`
+ `PostScriptStarted`
+ `PostScriptCompleted`
+ `PostScriptFailed`
+ `VSSBackupStarted`
+ `VSSBackupCompleted`
+ `VSSBackupFailed`
Untuk informasi selengkapnya, lihat [Memantau kebijakan Pengelola Siklus Hidup Data menggunakan CloudWatch](monitor-dlm-cw-metrics.md).
**Amazon EventBridge**
Amazon Data Lifecycle Manager memancarkan peristiwa EventBridge Amazon berikut saat skrip pra atau pasca dimulai, berhasil, atau gagal
+ `DLM Pre Post Script Notification`
Untuk informasi selengkapnya, lihat [Memantau kebijakan Pengelola Siklus Hidup Data menggunakan EventBridge](monitor-cloudwatch-events.md).