

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Backup dan pemulihan untuk Amazon EC2 dengan volume EBS
<a name="backup-recovery-ec2-ebs"></a>

AWS menyediakan beberapa metode untuk mencadangkan instans Amazon EC2 Anda. Bagian ini mencakup berbagai aspek pencadangan volume Amazon Elastic Block Store (Amazon EBS) atau volume penyimpanan instans untuk penyimpanan. Pertimbangkan AWS Backup sebagai pilihan pertama Anda untuk mengelola cadangan AWS jika memenuhi persyaratan Anda. Ingatlah bahwa cadangan hanya baik jika mereka dapat dikembalikan ke fungsi yang dimaksudkan. Fungsi pemulihan dan pemulihan harus diuji secara teratur untuk mengonfirmasi hal ini.

Arsitektur solusi dalam diagram berikut menjelaskan lingkungan beban kerja yang sepenuhnya ada AWS dengan sebagian besar arsitektur berdasarkan Amazon EC2. Seperti yang ditunjukkan gambar berikut, skenario mencakup server web, server aplikasi, server pemantauan, database, Active Directory, dan replikasi pemulihan bencana (DR).

![\[Diagram lingkungan contoh dengan dua Availability Zones, database pribadi dan replika di subnet pribadi, dan replikasi pemulihan bencana.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/backup-recovery/images/workload-environment-aws.png)


AWS menyediakan banyak layanan berfitur lengkap untuk banyak server Amazon EC2 yang diwakili dalam arsitektur ini untuk melakukan pekerjaan yang tidak terdiferensiasi dalam membuat, menyediakan, mencadangkan, memulihkan, dan mengoptimalkan instans dan penyimpanan. Pertimbangkan apakah layanan ini masuk akal dalam arsitektur Anda untuk mengurangi kompleksitas dan manajemen. AWS juga menyediakan layanan untuk meningkatkan ketersediaan arsitektur berbasis Amazon EC2 Anda. Secara khusus, pertimbangkan Amazon EC2 Auto Scaling dan Elastic Load Balancing untuk melengkapi beban kerja Anda di Amazon EC2. Menggunakan layanan ini dapat meningkatkan ketersediaan dan toleransi kesalahan arsitektur Anda dan membantu Anda memulihkan instans yang rusak dengan dampak pengguna minimal.

Instans EC2 terutama menggunakan volume Amazon EBS untuk penyimpanan persisten. Amazon EBS menyediakan sejumlah fitur untuk pencadangan dan pemulihan yang dibahas secara rinci di bagian ini.

**Topics**
+ [Pencadangan dan pemulihan Amazon EC2 dengan snapshot dan AMIs](ec2-backup.md)
+ [Membuat backup volume EBS dengan AMIs dan snapshot EBS](new-ebs-volume-backups.md)
+ [Memulihkan volume Amazon EBS atau instans EC2](restore.md)

# Pencadangan dan pemulihan Amazon EC2 dengan snapshot dan AMIs
<a name="ec2-backup"></a>

Pertimbangkan apakah Anda perlu membuat cadangan lengkap instans EC2 dengan Amazon Machine Image (AMI) atau mengambil snapshot dari volume individual.

## Menggunakan AMIs atau snapshot Amazon EBS untuk backup
<a name="amis-snapshots"></a>

AMI mencakup yang berikut ini:
+ Satu atau lebih snapshot. Instance-store-backed AMIs menyertakan template untuk volume root instance (misalnya, sistem operasi, server aplikasi, dan aplikasi).
+ Luncurkan izin yang mengontrol AWS akun mana yang dapat menggunakan AMI untuk meluncurkan instance.
+ Pemetaan perangkat blok yang menentukan volume yang akan dilampirkan ke instance saat diluncurkan.

**catatan**  
Dalam kebanyakan kasus, AMIs untuk Windows, Red Hat, SUSE, dan SQL Server memerlukan informasi lisensi yang benar untuk hadir di AMI. Untuk informasi selengkapnya, lihat [Memahami informasi penagihan AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-billing-info.html). Saat membuat AMI dari snapshot, `RegisterImage` operasi memperoleh informasi penagihan yang benar dari metadata snapshot, tetapi ini memerlukan metadata yang sesuai untuk hadir. Untuk memverifikasi apakah informasi penagihan yang benar diterapkan, periksa bidang **Detail Platform** pada AMI baru. Jika bidang kosong atau tidak cocok dengan kode sistem operasi yang diharapkan (misalnya, Windows, Red Hat, SUSE, atau SQL), pembuatan AMI tidak berhasil, dan Anda harus membuang AMI dan mengikuti instruksi di [Buat AMI dari sebuah instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami).

Anda dapat menggunakan AMI untuk meluncurkan instance baru dengan perangkat lunak dan data yang telah dikonfigurasi sebelumnya. Anda dapat membuat AMI saat Anda ingin membuat baseline, yang merupakan konfigurasi yang dapat digunakan kembali untuk meluncurkan lebih banyak instance. Saat Anda membuat AMI dari instans EC2 yang ada, snapshot diambil untuk semua volume yang dilampirkan ke instance. Snapshot mencakup pemetaan perangkat.

Anda tidak dapat menggunakan snapshot untuk meluncurkan instance baru, tetapi Anda dapat menggunakannya untuk mengganti volume pada instance yang ada. Jika Anda mengalami kerusakan data atau kegagalan volume, Anda dapat membuat volume dari snapshot yang telah Anda ambil dan mengganti volume lama. Anda juga dapat menggunakan snapshot untuk menyediakan volume baru dan melampirkannya selama peluncuran instance baru.

Jika Anda menggunakan platform dan aplikasi yang AMIs dikelola dan dipublikasikan oleh AWS atau dari AWS Marketplace, pertimbangkan untuk mempertahankan volume terpisah untuk data Anda. Anda dapat mencadangkan volume data Anda sebagai snapshot yang terpisah dari sistem operasi dan volume aplikasi. Kemudian gunakan snapshot volume data dengan yang baru diperbarui AMIs diterbitkan oleh AWS atau dari file. AWS Marketplace Pendekatan ini memerlukan pengujian dan perencanaan yang cermat untuk mencadangkan dan memulihkan semua data kustom, termasuk informasi konfigurasi, pada yang baru diterbitkan AMIs.

Proses pemulihan dipengaruhi oleh pilihan Anda antara cadangan AMI atau cadangan snapshot. Jika Anda membuat AMI untuk dijadikan cadangan instans, Anda harus meluncurkan instans EC2 dari AMI sebagai bagian dari proses pemulihan Anda. Anda mungkin juga perlu mematikan instance yang ada untuk menghindari potensi tabrakan. Contoh potensi tabrakan adalah pengidentifikasi keamanan (SIDs) untuk instance Windows yang bergabung dengan domain. Proses pemulihan untuk snapshot mungkin mengharuskan Anda melepaskan volume yang ada dan melampirkan volume yang baru dipulihkan. Atau Anda mungkin perlu membuat perubahan konfigurasi untuk mengarahkan aplikasi Anda ke volume yang baru dilampirkan.

AWS Backup mendukung pencadangan tingkat instance sebagai dan pencadangan tingkat volume sebagai snapshot AMIs terpisah:
+ Untuk cadangan lengkap semua volume EBS pada instans, [buat AMI instans EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html). Saat Anda ingin memutar kembali, gunakan wizard instance peluncuran untuk membuat instance. Di wizard peluncuran instance, pilih **My AMIs**.
+ Untuk mencadangkan volume individual, [buat snapshot](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html). Untuk mengembalikan snapshot, lihat [Membuat volume dari snapshot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html#ebs-create-volume-from-snapshot). Anda dapat menggunakan Konsol Manajemen AWS atau AWS Command Line Interface (AWS CLI).

Biaya instance AMI adalah penyimpanan semua volume pada instance, tetapi bukan metadata. Biaya untuk snapshot EBS adalah penyimpanan volume individu. Untuk informasi selengkapnya tentang biaya penyimpanan volume, lihat [halaman harga Amazon EBS](https://aws.amazon.com/ebs/pricing/).

## Volume server
<a name="server-volumes"></a>

Volume EBS adalah opsi penyimpanan persisten utama untuk Amazon EC2. Anda dapat menggunakan penyimpanan blok ini untuk data terstruktur, seperti database, atau data tidak terstruktur, seperti file dalam sistem file pada volume.

Volume EBS ditempatkan di Availability Zone tertentu. Volume direplikasi di beberapa server untuk mencegah hilangnya data dari kegagalan komponen tunggal. Kegagalan mengacu pada hilangnya volume secara keseluruhan atau sebagian, tergantung pada ukuran dan kinerja volume.

Volume EBS dirancang untuk tingkat kegagalan tahunan (AFR) sebesar 0,1-0,2 persen. Ini membuat volume EBS 20 kali lebih andal daripada disk drive komoditas biasa, yang gagal dengan AFR sekitar 4 persen. Misalnya, jika Anda memiliki 1.000 volume EBS yang berjalan selama 1 tahun, Anda harus mengharapkan satu atau dua volume akan mengalami kegagalan.

Amazon EBS juga mendukung fitur snapshot untuk mengambil point-in-time cadangan data Anda. Semua jenis volume EBS menawarkan kemampuan snapshot yang tahan lama dan dirancang untuk ketersediaan 99,999 persen. Untuk informasi selengkapnya, lihat [Perjanjian Tingkat Layanan Komputasi Amazon](https://aws.amazon.com/ec2/sla/).

Amazon EBS menyediakan kemampuan untuk membuat snapshot (backup) dari volume EBS apa pun. Snapshot adalah fitur dasar untuk membuat cadangan volume EBS Anda. Sebuah snapshot mengambil salinan volume EBS dan menempatkannya di Amazon S3, di mana ia disimpan secara berlebihan di beberapa Availability Zone. Snapshot awal adalah salinan lengkap volume; snapshot yang sedang berlangsung hanya menyimpan perubahan tingkat blok tambahan. Lihat [dokumentasi Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-creating-snapshot.html) untuk detail tentang cara membuat snapshot Amazon EBS.

Anda dapat melakukan operasi pemulihan, menghapus snapshot, atau memperbarui metadata snapshot, seperti tag, yang terkait dengan snapshot dari [konsol Amazon EC2 di Wilayah](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/restore.html) yang sama dengan yang Anda ambil snapshot.

Memulihkan snapshot akan membuat volume Amazon EBS baru dengan data volume penuh. Jika Anda hanya memerlukan pemulihan sebagian, Anda dapat melampirkan volume ke instance yang sedang berjalan di bawah nama perangkat yang berbeda. Kemudian pasang, dan gunakan perintah salin sistem operasi untuk menyalin data dari volume cadangan ke volume produksi.

[Snapshot Amazon EBS juga dapat disalin antar AWS Wilayah dengan menggunakan kemampuan menyalin snapshot Amazon EBS, seperti yang dijelaskan dalam dokumentasi Amazon EBS.](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-copy-snapshot.html) Anda dapat menggunakan fitur ini untuk menyimpan cadangan Anda di Wilayah lain tanpa harus mengelola teknologi replikasi yang mendasarinya.

## Menetapkan volume server terpisah
<a name="separate-server"></a>

Anda mungkin sudah menggunakan satu set standar volume terpisah untuk sistem operasi, log, aplikasi, dan data. Dengan menetapkan volume server terpisah, Anda dapat mengurangi cakupan dampak ketika ada kegagalan aplikasi atau platform yang disebabkan oleh kelelahan ruang disk. Risiko ini biasanya lebih besar dengan hard drive fisik, karena Anda tidak memiliki fleksibilitas untuk memperluas volume dengan cepat. Dengan drive fisik, Anda harus membeli drive baru, mencadangkan data, dan kemudian mengembalikan data pada drive baru. Dengan AWS, risiko ini sangat berkurang karena Anda dapat menggunakan Amazon EBS untuk memperluas volume yang disediakan. Lihat informasi yang lebih lengkap dalam [dokumentasi AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/modify-volume-requirements.html).

Pertahankan volume terpisah untuk data aplikasi, data pengguna, log, dan file swap sehingga Anda dapat menggunakan kebijakan pencadangan dan pemulihan terpisah untuk sumber daya ini. Dengan memisahkan volume untuk data Anda, Anda juga dapat menggunakan jenis volume yang berbeda berdasarkan kinerja dan persyaratan penyimpanan untuk data. Anda kemudian dapat mengoptimalkan dan menyempurnakan biaya Anda untuk beban kerja yang berbeda.

## Pertimbangan misalnya volume toko
<a name="instance-store-volumes"></a>

penyimpanan instans menyediakan penyimpanan tingkat blok sementara untuk instans Anda. Penyimpanan ini terletak pada disk yang secara fisik terpasang pada komputer host. Penyimpanan instans ideal untuk penyimpanan sementara informasi yang sering berubah, seperti buffer, cache, data awal, dan konten sementara lainnya. Mereka juga lebih disukai untuk data yang direplikasi di seluruh armada instance, seperti kumpulan server web yang seimbang beban.

Data dalam penyimpanan instans hanya bertahan selama masaterkait. Jika suatu instans me-reboot (secara sengaja atau tidak sengaja), data pada saat penyimpanan tetap ada. Namun, data di penyimpanan instance hilang dalam salah satu keadaan berikut.
+ Drive yang mendasarinya gagal.
+ Contoh tersebut berhenti.
+ Instans berakhir

Oleh karena itu, jangan mengandalkan penyimpanan instance untuk data jangka panjang yang berharga. Sebaliknya, gunakan penyimpanan data yang lebih tahan lama, seperti Amazon S3, Amazon EBS, atau Amazon EFS.

Strategi umum dengan volume penyimpanan instans adalah menyimpan data yang diperlukan ke Amazon S3 secara teratur sesuai kebutuhan, berdasarkan tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO). Anda kemudian dapat mengunduh data dari Amazon S3 ke penyimpanan instans Anda saat instance baru diluncurkan. Anda juga dapat mengunggah data ke Amazon S3 sebelum instance dihentikan. Untuk persistensi, buat volume EBS, lampirkan ke instans Anda, dan salin data dari volume penyimpanan instans ke volume EBS secara berkala. Untuk informasi lebih lanjut, lihat [Pusat AWS Pengetahuan](https://aws.amazon.com/premiumsupport/knowledge-center/back-up-instance-store-ebs/).

## Menandai dan menegakkan standar untuk snapshot EBS dan AMIs
<a name="tagging"></a>

Menandai semua AWS sumber daya Anda adalah praktik penting untuk alokasi biaya, audit, pemecahan masalah, dan pemberitahuan. Penandaan penting untuk volume EBS sehingga informasi terkait yang diperlukan untuk mengelola dan memulihkan volume hadir. Tag tidak secara otomatis disalin dari instans EC2 ke AMIs atau dari volume sumber ke snapshot. Pastikan proses pencadangan Anda menyertakan tag yang relevan dari sumber-sumber ini. Ini membantu Anda mengatur metadata snapshot, seperti kebijakan akses, informasi lampiran, dan alokasi biaya, untuk menggunakan cadangan ini di masa mendatang. Untuk informasi selengkapnya tentang menandai AWS sumber daya Anda, lihat [paper teknis praktik terbaik penandaan](https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf).

Selain tag yang Anda gunakan untuk semua AWS sumber daya, gunakan tag khusus cadangan berikut:
+ ID contoh sumber
+ ID volume sumber (untuk snapshot)
+ Deskripsi titik pemulihan

Anda dapat menerapkan kebijakan penandaan dengan menggunakan AWS Config aturan dan izin IAM. IAM mendukung penggunaan tag yang diterapkan, sehingga Anda dapat menulis kebijakan IAM yang mengamanatkan penggunaan tag tertentu saat bertindak pada snapshot Amazon EBS. Jika `CreateSnapshot` operasi dicoba tanpa tag yang ditentukan dalam kebijakan izin IAM memberikan hak, pembuatan snapshot gagal dengan akses ditolak. Untuk informasi selengkapnya, lihat [posting blog tentang menandai snapshot Amazon EBS tentang pembuatan dan menerapkan kebijakan keamanan yang lebih kuat](https://aws.amazon.com/blogs/compute/tag-amazon-ebs-snapshots-on-creation-and-implement-stronger-security-policies/).

Anda dapat menggunakan AWS Config aturan untuk mengevaluasi pengaturan konfigurasi AWS sumber daya Anda secara otomatis. Untuk membantu Anda memulai, AWS Config berikan aturan yang dapat disesuaikan dan telah ditentukan sebelumnya yang disebut aturan terkelola. Anda juga dapat membuat aturan kustom Anda sendiri. Sementara AWS Config terus melacak perubahan konfigurasi di antara sumber daya Anda, ia memeriksa apakah perubahan ini melanggar salah satu kondisi dalam aturan Anda. *Jika sumber daya melanggar aturan, AWS Config tandai sumber daya dan aturan sebagai tidak patuh.* Perhatikan bahwa aturan [terkelola tag](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html) yang diperlukan saat ini tidak mendukung snapshot dan. AMIs

# Membuat backup volume EBS dengan AMIs dan snapshot EBS
<a name="new-ebs-volume-backups"></a>

AWS menyediakan banyak pilihan untuk membuat dan mengelola AMIs dan snapshot. Anda dapat menggunakan pendekatan yang memenuhi kebutuhan Anda. Masalah umum yang dihadapi banyak pelanggan adalah mengelola siklus hidup snapshot dan menyelaraskan snapshot dengan jelas berdasarkan tujuan, kebijakan retensi, dll. Tanpa penandaan yang tepat, ada risiko bahwa snapshot mungkin dihapus secara tidak sengaja atau sebagai bagian dari proses pembersihan otomatis. Anda mungkin juga akhirnya membayar untuk snapshot usang yang dipertahankan karena tidak ada pemahaman yang jelas apakah mereka masih diperlukan.

## Mempersiapkan volume EBS sebelum membuat snapshot atau AMI
<a name="prepare-volume"></a>

Sebelum Anda mengambil snapshot atau membuat AMI, buat persiapan yang diperlukan untuk volume EBS Anda. Membuat AMI menghasilkan snapshot baru untuk setiap volume EBS yang dilampirkan ke instance, jadi persiapan ini juga berlaku untuk. AMIs

Anda dapat mengambil snapshot dari volume EBS terlampir yang digunakan oleh instans EC2 yang diaktifkan. Namun, snapshot hanya menangkap data yang telah ditulis ke volume EBS Anda pada saat perintah snapshot dikeluarkan. Ini mungkin mengecualikan data apa pun yang telah di-cache oleh aplikasi atau sistem operasi. Praktik terbaik adalah memiliki sistem dalam keadaan di mana ia tidak melakukan I/O. Idealnya, mesin tidak menerima lalu lintas dan dalam keadaan berhenti, tetapi ini jarang terjadi karena operasi TI 24/7 menjadi norma. Jika Anda dapat menyiram data apa pun dari memori sistem ke disk yang digunakan oleh aplikasi Anda dan menjeda file apa pun yang menulis ke volume cukup lama untuk mengambil snapshot, snapshot Anda harus lengkap.

Untuk membuat cadangan yang bersih, Anda harus menghentikan database atau sistem file. Cara Anda melakukan ini tergantung pada database atau sistem file Anda.

Proses untuk database adalah sebagai berikut:

1. Jika memungkinkan, masukkan database ke mode cadangan panas.

1. Jalankan perintah snapshot Amazon EBS.

1. Keluarkan database dari mode cadangan panas atau, jika menggunakan replika baca, hentikan instance replika baca.

Proses untuk sistem file serupa, tetapi itu tergantung pada kemampuan sistem operasi atau sistem file. Misalnya, XFS adalah sistem file yang dapat menyiram datanya untuk cadangan yang konsisten. Untuk informasi selengkapnya, lihat [xfs\$1freeze](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/xfsfreeze). Atau, Anda dapat memfasilitasi proses ini dengan menggunakan manajer volume logis yang mendukung pembekuan I/O.

Namun, jika Anda tidak dapat menyiram atau menjeda semua penulisan file ke volume, lakukan hal berikut:

1. Lepaskan volume dari sistem operasi.

1. Keluarkan perintah snapshot.

1. Remount volume untuk mencapai snapshot yang konsisten dan lengkap. Anda dapat melakukan remount dan menggunakan volume Anda saat status snapshot tertunda.

Proses snapshot berlanjut di latar belakang dan pembuatan snapshot cepat dan menangkap titik waktu. Volume yang Anda cadangkan dilepas hanya dalam hitungan detik. Anda dapat menjadwalkan jendela cadangan kecil di mana pemadaman diharapkan dan ditangani oleh klien dengan anggun.

Saat Anda membuat snapshot untuk volume EBS yang berfungsi sebagai perangkat root, hentikan instance sebelum mengambil snapshot. Windows menyediakan Volume Shadow Copy Service (VSS) untuk membantu membuat snapshot yang konsisten dengan aplikasi. AWS menyediakan dokumen Systems Manager yang dapat Anda jalankan untuk mengambil cadangan tingkat gambar dari aplikasi sadar VSS. Snapshot mencakup data dari transaksi yang tertunda antara aplikasi ini dan disk. Anda tidak perlu mematikan instans Anda atau memutuskannya saat Anda mencadangkan semua volume terlampir. Lihat informasi yang lebih lengkap dalam [dokumentasi AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html).

**catatan**  
Jika Anda membuat AMI Windows sehingga Anda dapat menerapkan instance serupa lainnya, gunakan [EC2Config EC2 atau](https://aws.amazon.com/premiumsupport/knowledge-center/sysprep-create-install-ec2-windows-amis/) Launch [to](https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--system-preparation--overview) Sysprep instance Anda. Kemudian buat AMI dari instance yang dihentikan. Sysprep menghapus informasi unik dari instans Windows Amazon EC2, termasuk, nama komputer SIDs, dan driver. Duplikat SIDs dapat menyebabkan masalah dengan Active Directory, Windows Server Update Services (WSUS), masalah login, aktivasi tombol volume Windows, Microsoft Office, dan produk pihak ketiga. Jangan gunakan Sysprep dengan instans Anda jika AMI Anda untuk tujuan pencadangan dan Anda ingin memulihkan instance yang sama dengan semua informasi uniknya yang utuh.

## Membuat snapshot volume EBS secara manual dari konsol
<a name="manual-snapshots"></a>

Buat snapshot dari volume yang sesuai atau seluruh instance sebelum Anda membuat perubahan besar yang belum sepenuhnya diuji pada instance. Misalnya, Anda mungkin ingin membuat snapshot sebelum memutakhirkan atau menambal aplikasi atau perangkat lunak sistem pada instans Anda.

Anda dapat membuat snapshot secara manual dari konsol. Di konsol Amazon EC2, pada halaman **Volume Toko Blok Elastis**, pilih volume yang ingin Anda cadangkan. Kemudian pada menu **Actions**, pilih **Create Snapshot**. Anda dapat mencari volume yang dilampirkan ke instance tertentu dengan memasukkan ID instans di kotak filter.

Masukkan deskripsi dan tambahkan tag yang sesuai. Tambahkan `Name` tag untuk membuatnya lebih mudah untuk menemukan volume nanti. Tambahkan tag lain yang sesuai berdasarkan strategi penandaan Anda.

## Menciptakan AMIs
<a name="create-ami"></a>

AMI menyediakan informasi yang diperlukan untuk meluncurkan sebuah instance. AMI menyertakan volume root dan snapshot dari volume EBS yang dilampirkan ke instance saat gambar dibuat. Anda tidak dapat meluncurkan instans baru dari snapshot EBS saja; Anda harus meluncurkan instans baru dari AMI.

Saat Anda membuat AMI, AMI dibuat di akun dan Wilayah yang Anda gunakan. Proses pembuatan AMI membuat snapshot Amazon EBS untuk setiap volume yang dilampirkan ke instance, dan AMI mengacu pada snapshot Amazon EBS ini. Snapshot ini berada di Amazon S3 dan sangat tahan lama.

Setelah membuat AMI instans EC2, Anda dapat menggunakan AMI untuk membuat ulang instans atau meluncurkan lebih banyak salinan instans. Anda juga dapat menyalin AMIs dari satu Wilayah ke Wilayah lain untuk migrasi aplikasi atau DR.

![\[Membuat gambar, meluncurkan gambar ke sebuah instance, dan membuat salinan gambar.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/backup-recovery/images/ami-process.png)


AMI harus dibuat dari instans EC2 kecuali Anda memigrasikan mesin virtual, seperti mesin virtual VMWARE, ke. AWS Untuk membuat AMI dari konsol Amazon EC2, pilih instans, pilih **Tindakan**, pilih **Gambar**, lalu pilih **Buat** Gambar.

## Amazon Data Lifecycle Manager
<a name="amazon-dlm"></a>

[Untuk mengotomatiskan pembuatan, penyimpanan, dan penghapusan snapshot Amazon EBS, Anda dapat menggunakan Amazon Data Lifecycle Manager.](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-lifecycle.html) Mengotomatiskan manajemen snapshot membantu Anda melakukan hal berikut:
+ Lindungi data berharga dengan menerapkan jadwal pencadangan rutin.
+ Mempertahankan cadangan sebagaimana diwajibkan oleh auditor atau kepatuhan internal.
+ Mengurangi biaya penyimpanan dengan menghapus cadangan yang usang.

Menggunakan Amazon Data Lifecycle Manager, Anda dapat mengotomatiskan proses pengelolaan snapshot untuk instans EC2 (dan volume EBS terlampir) atau memisahkan volume EBS. Ini mendukung opsi seperti salinan lintas wilayah, sehingga Anda dapat menyalin snapshot secara otomatis ke Wilayah lain AWS . Menyalin snapshot ke Wilayah alternatif adalah salah satu pendekatan untuk mendukung upaya DR dan memulihkan opsi di Wilayah alternatif. [Anda juga dapat menggunakan Amazon Data Lifecycle Manager untuk membuat kebijakan siklus hidup snapshot yang mendukung pemulihan snapshot cepat.](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html)

Amazon Data Lifecycle Manager adalah fitur yang disertakan dari Amazon EC2 dan Amazon EBS. Tidak ada biaya untuk Amazon Data Lifecycle Manager.

## AWS Backup
<a name="aws-backup-volume"></a>

AWS Backup unik dari Amazon Data Lifecycle Manager karena Anda dapat membuat paket cadangan yang menyertakan sumber daya di beberapa layanan. AWS Anda dapat mengoordinasikan cadangan Anda untuk menutupi sumber daya yang Anda gunakan bersama daripada mengoordinasikan cadangan sumber daya secara individual.

AWS Backup juga mencakup konsep brankas cadangan, yang dapat membatasi akses ke titik pemulihan untuk cadangan Anda yang telah selesai. Operasi pemulihan dapat dimulai dari AWS Backup bukan melanjutkan ke setiap sumber daya individu dan memulihkan cadangan yang dibuat. AWS Backup juga mencakup sejumlah fitur tambahan, seperti manajemen audit dan pelaporan. Untuk informasi lebih lanjut, lihat [Backup dan pemulihan menggunakan AWS Backup[Backup dan pemulihan menggunakan AWS Backup](aws-backup.md)](aws-backup.md) bagian panduan ini.

## Melakukan backup multi-volume
<a name="multi-volume"></a>

Jika Anda ingin mencadangkan data pada volume EBS dalam array RAID menggunakan snapshot, snapshot harus konsisten. Ini karena snapshot volume ini dibuat secara independen. Memulihkan volume EBS dalam array RAID dari snapshot yang tidak sinkron menurunkan integritas array.

**Untuk membuat kumpulan snapshot yang konsisten untuk array RAID Anda, gunakan operasi [CreateSnapshots](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateSnapshots.html)API, atau masuk ke konsol Amazon EC2 dan **pilih Elastic Block** Store**, Snapshots,** Create Snapshot.**

![\[Layar Create Snapshot untuk membuat snapshot beberapa volume.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/backup-recovery/images/multi-volume-snapshot.png)


Snapshot instance yang memiliki beberapa volume yang dilampirkan dalam konfigurasi RAID diambil sebagai snapshot multi-volume, secara kolektif. Snapshot multi-volume menyediakan snapshot point-in-time, terkoordinasi data, dan konsisten crash di beberapa volume EBS yang dilampirkan ke instans EC2. Anda tidak perlu menghentikan instans Anda untuk berkoordinasi antar volume untuk mencapai konsistensi karena snapshot secara otomatis diambil di beberapa volume EBS. Setelah snapshot untuk volume dimulai (biasanya satu atau dua detik), sistem file dapat melanjutkan operasinya.

Setelah snapshot dibuat, setiap snapshot diperlakukan sebagai snapshot individu. Anda dapat melakukan semua operasi snapshot, seperti memulihkan, menghapus, dan Cross-region dan salinan akun, seperti yang Anda lakukan dengan snapshot volume tunggal. Anda juga dapat menandai snapshot multi-volume Anda seperti halnya snapshot volume tunggal. Kami menyarankan Anda menandai snapshot multi-volume untuk mengelolanya secara kolektif selama pemulihan, penyalinan, atau penyimpanan. Lihat informasi yang lebih lengkap dalam [dokumentasi AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/application-consistent-snapshots.html).

Anda juga dapat melakukan pencadangan ini dari manajer volume logis atau pencadangan tingkat sistem file. Dalam kasus ini, menggunakan agen cadangan tradisional memungkinkan data dicadangkan melalui jaringan. Sejumlah solusi cadangan berbasis agen tersedia di internet dan di. [AWS Marketplace](https://aws.amazon.com/marketplace/)

Pendekatan alternatif adalah membuat replika volume sistem primer yang ada pada satu volume besar. Ini menyederhanakan proses pencadangan, karena hanya satu volume besar yang harus dicadangkan, dan pencadangan tidak terjadi pada sistem utama. Namun, pertama-tama tentukan apakah volume tunggal dapat bekerja cukup selama pencadangan dan apakah ukuran volume maksimum sesuai untuk aplikasi.

## Melindungi cadangan Amazon EC2 Anda
<a name="protecting"></a>

Penting untuk mempertimbangkan keamanan cadangan Anda dan untuk mencegah penghapusan cadangan Anda secara tidak sengaja atau berbahaya. Anda dapat menggunakan sejumlah pendekatan secara kolektif untuk mencapai hal ini. Untuk mencegah hilangnya cadangan penting Anda karena pelanggaran keamanan, kami sarankan Anda menyalin cadangan Anda ke akun lain. AWS Jika Anda memiliki beberapa AWS akun, Anda dapat menetapkan akun terpisah sebagai akun arsip Anda di mana semua akun lain dapat menyalin cadangan. Misalnya, Anda dapat melakukannya dengan [cadangan lintas akun](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html) di. AWS Backup

Rencana pemulihan bencana Anda mungkin juga mengharuskan Anda untuk dapat mereproduksi instans EC2 di tempat lain Wilayah AWS jika terjadi kegagalan regional. Anda dapat mendukung tujuan ini dengan menyalin cadangan Anda ke Wilayah lain dalam akun yang sama. Ini dapat memberikan lapisan tambahan perlindungan penghapusan yang tidak disengaja serta mendukung tujuan pemulihan bencana (DR). AWS Backup memberikan dukungan untuk [backup Lintas wilayah](https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html).

Pertimbangkan untuk memblokir izin IAM ke tindakan [ec2: DeleteSnapshot dan [ec2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeregisterImage.html):](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteSnapshot.html). DeregisterImage Sebagai gantinya, Anda dapat mengizinkan kebijakan dan metode retensi mengelola siklus hidup snapshot EBS dan Amazon EC2. AMIs Memblokir tindakan penghapusan adalah salah satu cara untuk menerapkan strategi write-once, read-many (WORM) untuk snapshot EBS Anda. Anda juga dapat menggunakan [AWS Backup Vault Lock](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html), yang menyediakan dukungan untuk snapshot EBS dan sumber daya lainnya. AWS 

Selain itu, pertimbangkan untuk memblokir kemampuan pengguna untuk berbagi AMIs dan snapshot EBS dengan memblokir tindakan [EC2: ModifyImageAttribute dan [ec2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html):](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyImageAttribute.html) IAM. ModifySnapshotAttribute Ini akan mencegah Anda AMIs dan snapshot dibagikan dengan AWS akun yang berada di luar organisasi Anda. Jika Anda menggunakan AWS Backup, batasi pengguna dari melakukan operasi serupa pada brankas cadangan. Untuk informasi lebih lanjut, lihat [Backup dan pemulihan menggunakan AWS Backup](aws-backup.md) bagian panduan ini.

Amazon EBS menyertakan [fitur Recycle Bin](https://docs.aws.amazon.com/ebs/latest/userguide/recycle-bin.html) yang dapat membantu Anda memulihkan snapshot EBS yang terhapus secara tidak sengaja. Jika Anda mengizinkan pengguna menghapus snapshot, aktifkan fitur ini agar snapshot yang diperlukan tidak dihapus secara permanen. Pengguna harus sangat berhati-hati dalam menghapus beberapa snapshot, karena konsol Amazon EC2 memungkinkan Anda memilih beberapa snapshot dan menghapusnya dalam satu operasi. Selain itu, berhati-hatilah saat Anda menggunakan skrip pembersihan dan otomatisasi sehingga Anda tidak sengaja menghapus snapshot yang Anda butuhkan. Fitur Recycle Bin membantu memberikan perlindungan dari jenis situasi ini.

## Mengarsipkan snapshot EBS
<a name="archiving"></a>

[Mengarsipkan snapshot EBS Anda](https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-archive.html) bisa menjadi metode hemat biaya untuk menyimpan salinan volume untuk tujuan referensi yang tidak ingin Anda pulihkan selama 90 hari atau lebih. Ini bisa menjadi langkah perantara yang baik sebelum menghapus semua snapshot terkait secara permanen untuk volume EBS. Misalnya, Anda dapat mempertimbangkan pengarsipan snapshot sebagai end-of-lifecycle langkah untuk volume EBS yang tidak lagi digunakan. Pengarsipan daripada menghapus juga bisa menjadi metode retensi penghapusan yang lebih hemat biaya daripada menggunakan Recycle Bin.

## Mengotomatiskan snapshot dan pembuatan AMI dengan Systems Manager, the AWS CLI, dan AWS SDKs
<a name="automating"></a>

Pendekatan pencadangan Anda mungkin memerlukan operasi sebelum dan sesudah snapshot atau AMI dibuat. Misalnya, Anda mungkin perlu menghentikan dan memulai layanan untuk menghentikan sistem file. Atau Anda mungkin perlu berhenti dan memulai instance Anda selama pembuatan AMI. Anda mungkin juga perlu membuat cadangan beberapa komponen dalam arsitektur Anda secara kolektif, masing-masing dengan langkah pra-pembuatan dan pasca-pembuatannya sendiri.

Anda dapat mengurangi waktu jendela pemeliharaan untuk pencadangan Anda dengan mengotomatiskan proses Anda dan memverifikasi bahwa proses pencadangan Anda diterapkan secara konsisten. Untuk mengotomatiskan operasi pra-pembuatan dan pasca-pembuatan kustom Anda, buat skrip proses pencadangan Anda dengan menggunakan AWS CLI dan SDK.

Otomatisasi Anda dapat didefinisikan dalam runbook Systems Manager yang dapat dijalankan sesuai permintaan atau selama jendela pemeliharaan Systems Manager. Anda dapat memberi pengguna akses untuk menjalankan runbook Systems Manager tanpa perlu memberi mereka izin untuk perintah mengganggu Amazon EC2. Ini juga dapat membantu Anda memverifikasi bahwa proses pencadangan dan tag diterapkan secara konsisten oleh pengguna Anda. Anda dapat menggunakan [AWS- CreateSnapshot dan [AWS- CreateImage](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-createimage.html)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-createsnapshot.html) runbook untuk membuat snapshot dan AMIs, atau Anda dapat memberikan izin kepada pengguna lain untuk menggunakannya. Systems Manager juga menyertakan [AWS- UpdateLinuxAmi dan [AWS- UpdateWindowsAmi](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-updatewindowsami.html)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-aws-updatelinuxami.html) runbook untuk mengotomatiskan patching AMI dan pembuatan AMI.

Anda juga dapat menggunakan AWS CLI dan [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/)untuk mengotomatiskan snapshot dan proses pembuatan AMI Anda. Anda dapat menggunakan AWS CLI perintah [aws ec2 create-snapshot untuk membuat snapshot](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-snapshot.html) volume EBS sebagai satu langkah dalam otomatisasi Anda. Anda dapat menggunakan perintah [aws ec2 create-snapshots untuk membuat snapshot tersinkronisasi](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-snapshots.html) yang konsisten dengan crash dari semua volume yang dilampirkan ke instans EC2 Anda.

Anda dapat menggunakan AWS CLI untuk membuat yang baru. AMIs Anda dapat menggunakan perintah [aws ec2 register-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html) untuk membuat gambar baru untuk instans EC2 Anda. [Untuk mengotomatiskan shutdown, pembuatan gambar, dan restart instance Anda, gabungkan perintah ini dengan perintah [aws ec2 stop-instance dan aws ec2 start-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/stop-instances.html).](https://docs.aws.amazon.com/cli/latest/reference/ec2/start-instances.html)

# Memulihkan volume Amazon EBS atau instans EC2
<a name="restore"></a>

Jika Anda hanya perlu mengembalikan satu volume yang terpasang pada instans EC2, Anda dapat mengembalikan volume tersebut secara terpisah, melepaskan volume yang ada, dan melampirkan volume yang dipulihkan ke instans EC2 Anda. Jika Anda perlu memulihkan seluruh instans EC2, termasuk semua volume yang terkait, Anda harus menggunakan cadangan Amazon Machine Image (AMI) dari instans Anda.

Untuk mengurangi waktu pemulihan dan dampak pada aplikasi dan proses yang bergantung, proses pemulihan Anda harus mempertimbangkan sumber daya yang digantikannya. Untuk hasil terbaik, uji proses pemulihan Anda secara teratur di lingkungan yang lebih rendah (misalnya, non-produksi) untuk memverifikasi bahwa proses Anda memenuhi tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO) dan bahwa proses pemulihan berfungsi seperti yang diharapkan. Pertimbangkan bagaimana proses pemulihan akan memengaruhi aplikasi dan layanan yang bergantung pada contoh yang Anda pulihkan, dan kemudian koordinasikan pemulihan seperlunya. Cobalah untuk mengotomatisasi dan menguji proses pemulihan sebanyak mungkin untuk mengurangi risiko proses pemulihan Anda gagal atau diimplementasikan secara tidak konsisten.

Jika Anda menggunakan Elastic Load Balancing, dengan beberapa instans yang melayani lalu lintas, Anda dapat menghilangkan instans yang gagal atau terganggu. Kemudian Anda dapat memulihkan instance baru untuk menggantinya sementara instance lain terus melayani lalu lintas tanpa gangguan kepada pengguna.

Proses pemulihan berikut yang dijelaskan adalah untuk contoh yang tidak menggunakan Elastic Load Balancing:
+ Memulihkan file dan direktori individual dari snapshot EBS
+ Memulihkan volume EBS dari snapshot Amazon EBS
+ Membuat atau memulihkan instans EC2 dari snapshot EBS
+ Memulihkan instance yang sedang berjalan dari AMI

## Memulihkan file dan direktori dari snapshot EBS
<a name="restore-files"></a>

[Snapshot EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html) memberikan replika point-in-time yang tepat dari volume asli yang digunakan untuk membuat snapshot. Untuk mengembalikan file atau direktori individual, Anda harus melakukan hal berikut: 

1. [Pertama, kembalikan volume dari snapshot EBS](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/restore.html#restore-snapshot) yang berisi file atau direktori.

1. Lampirkan volume ke instans EC2 yang ingin Anda pulihkan file.

1. Salin file dari volume yang dipulihkan ke volume instans EC2 Anda.

1. Lepaskan dan hapus volume yang dipulihkan.

## Memulihkan volume EBS dari snapshot Amazon EBS
<a name="restore-snapshot"></a>



Anda dapat memulihkan volume yang dilampirkan ke instans EC2 yang ada dengan membuat volume dari snapshot dan melampirkannya ke instans Anda. Anda dapat menggunakan konsol, operasi AWS CLI, atau API untuk membuat volume dari snapshot yang ada. Anda kemudian dapat memasang volume ke instance dengan menggunakan sistem operasi.

Perhatikan bahwa data dari snapshot Amazon EBS dimuat secara asinkron ke dalam volume EBS. Jika aplikasi mengakses volume di mana data tidak dimuat, ada latensi yang lebih tinggi dari biasanya saat data dimuat dari Amazon S3. Untuk menghindari dampak ini untuk aplikasi yang sensitif terhadap latensi, Anda memiliki dua opsi:
+ Anda dapat [menginisialisasi volume EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-initialize.html).
+ Dengan biaya tambahan, Amazon EBS mendukung [pemulihan snapshot cepat](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html), yang menghilangkan kebutuhan inisialisasi volume Anda.

Jika Anda mengganti volume yang harus menggunakan titik pemasangan yang sama, lepaskan volume itu sehingga Anda dapat memasang volume baru di tempatnya. Untuk melepas volume, pertama-tama hentikan proses apa pun yang menggunakan volume. Jika Anda mengganti volume root, Anda harus menghentikan instance terlebih dahulu sebelum Anda dapat melepaskan volume root.

Misalnya, ikuti langkah-langkah berikut untuk mengembalikan volume ke point-in-time cadangan sebelumnya dengan menggunakan konsol:

1. **Di konsol Amazon EC2, pada menu **Elastic Block Store**, pilih Snapshots.**

1. Cari snapshot yang ingin Anda pulihkan, dan pilih.

1. Pilih **Tindakan**, lalu pilih **Buat Volume**.

1. Buat volume baru di Availability Zone yang sama dengan instans EC2 Anda.

1. Di konsol Amazon EC2, pilih instans.

1. Dalam detail instance, catat nama perangkat yang ingin Anda ganti di entri **perangkat Root** atau entri **Blokir Perangkat**.

1. Pasang volumenya. Prosesnya berbeda untuk volume root dan volume non-root.

   Untuk volume root:

   1. Hentikan instans EC2.

   1. Pada menu **EC2 Elastic Block Store Volumes**, pilih volume root yang ingin Anda ganti.

   1. Pilih **Tindakan**, lalu pilih **Lepaskan Volume**.

   1. Pada menu **EC2 Elastic Block Store Volumes**, pilih volume baru.

   1. Pilih **Tindakan**, lalu pilih **Lampirkan Volume**.

   1. Pilih instance yang ingin Anda lampirkan volumenya, dan gunakan nama perangkat yang sama dengan yang Anda catat sebelumnya.

   Untuk volume non-root:

   1. Pada menu **EC2 Elastic Block Store Volumes**, pilih volume non-root yang ingin Anda ganti.

   1. Pilih **Tindakan**, lalu pilih **Lepaskan Volume**.

   1. Pasang volume baru dengan memilihnya di menu **EC2 Elastic Block Store Volumes** dan kemudian pilih **Actions**, **Attach Volume**. Pilih instance yang ingin Anda lampirkan, lalu pilih nama perangkat yang tersedia.

   1. Menggunakan sistem operasi misalnya, lepaskan volume yang ada, dan kemudian pasang volume baru di tempatnya.

      Di Linux, Anda dapat menggunakan `umount` perintah. Di Windows, Anda dapat menggunakan manajer volume logis (LVM) seperti utilitas sistem Manajemen Disk.

   1. Lepaskan volume sebelumnya yang mungkin Anda ganti dengan memilihnya di menu **Volume Toko Blok Elastis EC2 dan kemudian pilih **Tindakan**, **Lepaskan** Volume**.

Anda juga dapat menggunakan kombinasi AWS CLI dengan perintah sistem operasi untuk mengotomatiskan langkah-langkah ini.

## Membuat atau memulihkan instans EC2 dari snapshot EBS
<a name="instance-from-snapshot"></a>

Untuk membuat cadangan yang akan digunakan untuk memulihkan seluruh instans EC2, sebaiknya buat Amazon Machine Image (AMI). AMI menangkap informasi mesin seperti jenis virtualisasi. Mereka juga membuat snapshot untuk setiap volume yang dilampirkan ke instans EC2, termasuk pemetaan perangkat mereka, sehingga mereka dapat dipulihkan dalam konfigurasi yang sama. 

**catatan**  
Dalam kebanyakan kasus, AMIs untuk Windows, Red Hat, SUSE, dan SQL Server memerlukan informasi lisensi yang benar untuk hadir di AMI. Untuk informasi selengkapnya, lihat [Memahami informasi penagihan AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-billing-info.html). Saat membuat AMI dari snapshot, `RegisterImage` operasi memperoleh informasi penagihan yang benar dari metadata snapshot, tetapi ini memerlukan metadata yang sesuai untuk hadir. Untuk memverifikasi apakah informasi penagihan yang benar diterapkan, periksa bidang **Detail Platform** pada AMI baru. Jika bidang kosong atau tidak cocok dengan kode sistem operasi yang diharapkan (misalnya, Windows, Red Hat, SUSE, atau SQL), pembuatan AMI tidak berhasil, dan Anda harus membuang AMI dan mengikuti instruksi di [Buat AMI dari sebuah instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami).

Jika Anda harus menggunakan snapshot EBS untuk memulihkan instance, pertama-tama buat AMI dari snapshot EBS yang akan menjadi volume root untuk instans EC2 baru Anda:

1. **Di konsol Amazon EC2, pada menu **Elastic Block Store**, pilih Snapshots.**

1. Cari snapshot yang akan digunakan untuk membuat volume root untuk instans EC2 baru Anda, dan pilih.

1. Pilih **Tindakan**, lalu pilih **Buat Gambar dari Snapshot**.

1. Masukkan nama untuk gambar Anda (misalnya,`YYYYMMDD-restore-for-i-012345678998765de`), dan pilih opsi yang sesuai untuk gambar baru Anda.

1. (Hanya Windows, Red Hat, SUSE, dan SQL Server) Untuk memverifikasi apakah informasi penagihan yang benar diterapkan, periksa bidang **Detail Platform** pada AMI baru. Jika bidang kosong atau tidak cocok dengan kode sistem operasi yang diharapkan (misalnya, **Windows** atau **Red Hat**), pembuatan AMI tidak berhasil, dan Anda harus membuang AMI dan mengikuti instruksi di [Buat AMI dari sebuah instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#how-to-create-ebs-ami).

Setelah gambar dibuat dan tersedia, Anda dapat meluncurkan instans EC2 baru yang akan menggunakan snapshot EBS untuk volume root.

## Memulihkan instance yang sedang berjalan dari AMI
<a name="restore-ami"></a>

Anda dapat memunculkan instance baru dari cadangan AMI untuk mengganti instance yang sudah berjalan. Salah satu pendekatannya adalah menghentikan instans yang ada, menjaganya tetap offline saat Anda meluncurkan instance baru dari AMI Anda, dan melakukan pembaruan yang diperlukan. Pendekatan ini mengurangi risiko konflik dari kedua contoh yang berjalan secara bersamaan. Ini adalah pendekatan yang dapat diterima jika layanan yang disediakan instans Anda sedang down atau Anda melakukan pemulihan selama jendela pemeliharaan. Setelah menguji instans baru, Anda dapat menetapkan kembali alamat IP Elastis yang dialokasikan ke instans lama. Kemudian Anda dapat memperbarui catatan Layanan Nama Domain (DNS) apa pun untuk menunjuk ke instance baru.

Namun, jika selama pemulihan Anda harus meminimalkan waktu henti instans dalam layanan Anda, pertimbangkan untuk meluncurkan dan menguji instance baru dari cadangan AMI Anda. Kemudian ganti instance yang ada dengan instance baru.

Saat kedua instance berjalan, Anda harus mencegah instans baru menyebabkan tabrakan tingkat platform atau tingkat aplikasi. Misalnya, Anda mungkin mengalami masalah dengan instance Windows yang bergabung dengan domain yang berjalan dengan nama komputer yang sama SIDs. Anda mungkin mengalami masalah serupa dengan aplikasi dan layanan jaringan yang memerlukan pengidentifikasi unik.

Untuk mencegah server dan layanan lain terhubung ke instans baru Anda sebelum siap, gunakan grup keamanan untuk memblokir sementara semua koneksi masuk untuk instance baru Anda kecuali untuk alamat IP Anda sendiri untuk akses dan pengujian. Anda juga dapat memblokir koneksi keluar sementara untuk instance baru untuk mencegah layanan dan aplikasi memulai koneksi atau pembaruan apa pun ke sumber daya lain. Ketika instance baru siap, hentikan instance yang ada, mulai layanan dan proses pada instance baru, lalu buka blokir koneksi jaringan masuk atau keluar yang Anda terapkan.