Strategi Cadangan Amazon EC2

Saya punya beberapa pengaturan server Web / server DB menggunakan Amazon EC2. Saat ini saya mengambil snapshot harian semua sistem saya dan drive EBS yang berisi semua file aplikasi, file DB, kode sumber, dan cadangan DB. Saya memiliki aplikasi konsol yang menjalankan kreasi cadangan sesuai jadwal. Gambar saya adalah gambar EBS.

Saya mengerjakan tugas yang akan menjatuhkan snapshot saya setelah sekian hari. Saya kira pertanyaan saya adalah, Haruskah saya juga dapat menjadwalkan tugas gambar / EBS lengkap? Dengan cara ini, jika server gagal atau rusak saya bisa meluncurkan gambar terbaru kemudian menerapkan snapshot terbaru.

Saat saya sedang mengerjakan strategi cadangan, saya menggunakan Jungle Disc untuk membuat cadangan data disk saya.

Rekomendasi saya:

1. Selalu dokumentasikan dan / atau skrip pengaturan setiap instance baru sehingga Anda dapat mereproduksi instalasi perangkat lunak dan konfigurasi sistem jika Anda kehilangan instance. Uji ini dengan memulai contoh baru dan mengikuti prosedur. Anda dapat menggunakan AMI khusus dan privat jika instalasi membutuhkan waktu lama dan Anda harus memulai instans dengan cepat, tetapi AMI itu sendiri harus dibuat menggunakan prosedur yang terdokumentasi dan / atau scripted.

2. Simpan data penting Anda pada volume EBS yang terpisah dan jangan di root volume EBS. Ini memiliki banyak manfaat termasuk membuatnya lebih mudah untuk mem-porting data Anda ke instance baru (misalnya, berdasarkan AMI yang berbeda) dan membuatnya lebih mudah untuk mendapatkan salinan data Anda pada instance lain (misalnya, dengan snapshot dan volume baru).

3. Buat snapshot reguler dari volume data EBS. Jika memungkinkan / berlaku, gunakan alat seperti EC2-konsisten-snapshot saya untuk meningkatkan peluang Anda mengambil snapshot dari sistem file / database yang konsisten. Cadangkan data di luar AWS / EC2, karena akun AWS Anda sendiri adalah satu titik kegagalan.

4. Buat snapshot dari volume EBS root dari waktu ke waktu pada contoh-contoh penting. Meskipun ini dapat membantu Anda jika terjadi kegagalan volume EBS, bagian itu tidak terlalu kritis karena # 1 dan # 2 di atas. Alasan utama saya melakukan ini adalah membuat snapshots mengurangi risiko kegagalan volume EBS itu sendiri.

Tingkat kegagalan volume EBS secara langsung terkait dengan jumlah blok yang telah dimodifikasi pada volume tersebut sejak cuplikan EBS terakhir.

Haruskah saya juga dapat menjadwalkan tugas gambar / EBS yang lengkap?

ya, disarankan. Suatu kali itu menyelamatkan saya, karena saya harus mengatur ulang berkali-kali karena masalah kernel, sampai disk boot tidak dapat dibaca lagi dan saya hanya boot dari snapshot terbaru.

Jika Anda tertarik, saya menulis kelas Java untuk memotret semua volume EBS yang terhubung dan juga menghapusnya setelah jangka waktu tertentu. Saat ini saya melakukan backup setiap minggu dan membuang backup ketiga setelah dua minggu.

https://github.com/stivlo/obliquid-cp/blob/master/src/main/java/org/obliquid/sherd/runner/RequestSnapshots.java

Hanya melakukan satu tindakan per jalankan, seperti mengambil atau menghapus snapshot, karena dimaksudkan untuk dimasukkan ke dalam cron setiap jam untuk menghindari kelebihan dengan puluhan snapshot pada waktu yang sama jika Anda memiliki banyak EBS seperti yang saya lakukan.

Kami menggunakan strategi pencadangan yang sederhana namun kuat: buat AMI baru berdasarkan menjalankan EC2 EBS instance dua kali sehari dan menghapus AMI "lama". Melalui API (CreateImage) Anda dapat mengatur flag jangan reboot instance saat membuat AMI baru atau, jika Anda menggunakan raid software - ssh sebagai contoh sebelum CreateIImage API memanggil dan membekukan filesystem dengan "fsfreeze" pada filesystem paling populer di kernel baru atau xfs_freeze jika Anda menggunakan kernel dan xfs yang lebih lama.

AMI "cadangan" yang dibuat mengingat semua yang terhubung ke disk EBS yang berjalan asli (melalui tautan ke snapshot yang dibuat) dan, dalam hal menggunakan serangan perangkat lunak dengan banyak disk, memungkinkan untuk memulihkan instance baru di AZ apa pun hanya dengan satu panggilan API atau melalui web -interface.