กลยุทธ์การสำรองข้อมูล Amazon EC2

ฉันมีการตั้งค่าเซิร์ฟเวอร์ / DB เซิร์ฟเวอร์คู่โดยใช้ EC2 ของ Amazon ขณะนี้ฉันกำลังถ่ายภาพสแน็ปช็อตทุกวันของระบบและไดรฟ์ EBS ทั้งหมดที่มีไฟล์แอปพลิเคชันของฉันทั้งหมด, ไฟล์ DB, ซอร์สโค้ดและการสำรองฐานข้อมูล ฉันมีแอปพลิเคชั่นคอนโซลที่สร้างการสำรองข้อมูลตามกำหนดเวลา ภาพของฉันเป็นภาพ EBS

ฉันกำลังทำงานที่จะทำสแนปชอตของฉันหลังจากผ่านไปหลายวัน ฉันเดาว่าคำถามของฉันคือ / ฉันควรกำหนดเวลางานรูปภาพ / EBS ให้สมบูรณ์ด้วยหรือไม่? วิธีนี้หากเซิร์ฟเวอร์ล้มเหลวหรือเสียหายฉันสามารถเปิดภาพล่าสุดแล้วใช้ภาพรวมล่าสุด

ขณะที่ฉันทำงานกับกลยุทธ์การสำรองข้อมูลของฉันฉันใช้ Jungle Disc เพื่อสำรองดิสก์ข้อมูลของฉัน

คำแนะนำของฉัน:

1. จัดทำเอกสารและ / หรือสคริปต์การตั้งค่าของแต่ละอินสแตนซ์ใหม่เพื่อให้คุณสามารถสร้างการติดตั้งซอฟต์แวร์และการกำหนดค่าระบบใหม่ได้ในกรณีที่คุณทำอินสแตนซ์หาย ทดสอบสิ่งนี้โดยเริ่มต้นอินสแตนซ์ใหม่และทำตามขั้นตอน คุณสามารถใช้ AMI ส่วนตัวที่กำหนดเองได้หากการติดตั้งใช้เวลานานและคุณต้องเริ่มต้นอินสแตนซ์อย่างรวดเร็ว แต่ AMI นั้นควรสร้างขึ้นเองโดยใช้ขั้นตอนที่ทำเป็นเอกสารและ / หรือสคริปต์

2. เก็บข้อมูลสำคัญของคุณในปริมาณ EBS แยกจากกันและไม่ได้อยู่ในปริมาณ EBS รูท สิ่งนี้มีประโยชน์มากมายรวมถึงทำให้ง่ายต่อการย้ายข้อมูลของคุณไปยังอินสแตนซ์ใหม่ (เช่นอิง AMI ที่แตกต่างกัน) และทำให้ง่ายต่อการรับสำเนาข้อมูลของคุณในอินสแตนซ์อื่น ๆ (เช่นสแน็ปช็อตและเล่มใหม่)

3. สร้างสแน็ปช็อตปกติของปริมาณข้อมูล EBS หากเป็นไปได้ / ใช้งานได้ให้ใช้เครื่องมือเช่นec2-สอดคล้องกัน-snapshotของฉันเพื่อปรับปรุงโอกาสที่คุณจะถ่ายภาพระบบไฟล์ / ฐานข้อมูลที่สอดคล้องกัน สำรองข้อมูลนอก AWS / EC2 เนื่องจากบัญชี AWS ของคุณเป็นจุดที่เกิดความล้มเหลวเพียงจุดเดียว

4. สร้างสแน็ปช็อตของปริมาณ EBS รูทเป็นครั้งคราวในอินสแตนซ์ที่สำคัญ แม้ว่าสิ่งนี้อาจช่วยคุณในกรณีของอินสแตนซ์หรือความล้มเหลวของโวลุ่ม EBS แต่ส่วนนั้นไม่สำคัญมากเนื่องจาก # 1 และ # 2 ด้านบน เหตุผลหลักที่ฉันทำเช่นนี้คือการสร้างสแน็ปช็อตช่วยลดความเสี่ยงของความล้มเหลวของโวลุ่ม EBS เอง

อัตราความล้มเหลวของไดรฟ์ข้อมูล EBS เกี่ยวข้องโดยตรงกับจำนวนบล็อกที่มีการแก้ไขบนไดรฟ์ข้อมูลนั้นตั้งแต่สแน็ปช็อต EBS ล่าสุด

ฉันควร / สามารถกำหนดเวลางานรูปภาพ / EBS ทั้งหมดได้เช่นกันหรือไม่?

ใช่มันแนะนำให้เลือก ครั้งหนึ่งมันช่วยฉันได้เพราะฉันต้องรีเซ็ตหลายครั้งเนื่องจากปัญหาเคอร์เนลจนกระทั่งดิสก์สำหรับบูตไม่สามารถอ่านได้อีกต่อไปและฉันก็บูตจากสแน็ปช็อตล่าสุด

หากคุณสนใจฉันเขียนคลาส Java เพื่อจับภาพไดรฟ์ข้อมูล EBS ที่เชื่อมต่อทั้งหมดและลบออกหลังจากเวลาผ่านไประยะหนึ่ง ขณะนี้ฉันทำการสำรองข้อมูลทุกสัปดาห์และยกเลิกการสำรองข้อมูลครั้งที่สามหลังจากสองสัปดาห์

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

มันใช้งานเพียงหนึ่งแอคชั่นต่อการวิ่งเช่นถ่ายหรือลบสแน็ปช็อตเพราะมันจะถูกใส่ใน cron ทุกชั่วโมงเพื่อหลีกเลี่ยงการโอเวอร์โหลดด้วยสแนปช็อตนับสิบในเวลาเดียวกันในกรณีที่คุณมี EBS มากมาย

เราใช้กลยุทธ์การสำรองข้อมูลที่เรียบง่าย แต่มีประสิทธิภาพ: สร้าง AMI ใหม่บนพื้นฐานของการใช้งานอินสแตนซ์ EC2 EBS สองครั้งต่อวันและลบ AMI "เก่า" ผ่าน API (CreateImage) คุณสามารถตั้งค่าสถานะไม่รีบูตอินสแตนซ์ในขณะที่สร้าง AMI ใหม่หรือถ้าคุณใช้ซอฟต์แวร์จู่โจม - ssh ไปยังอินสแตนซ์ก่อนการโทร CreateIImage API และหยุดระบบไฟล์ด้วย "fsfreeze" บนระบบไฟล์ที่นิยมมากที่สุด คุณใช้เคอร์เนลและ xfs ที่เก่ากว่า

สร้าง "การสำรองข้อมูล" AMI จดจำการเชื่อมต่อทั้งหมดกับอินสแตนซ์ที่ทำงานอยู่เดิมดิสก์ EBS (ผ่านลิงก์ไปยังสแน็ปช็อตที่สร้างขึ้น) และในกรณีของการใช้ซอฟต์แวร์ตรวจค้นด้วยดิสก์หลาย ๆ ตัว -อินเตอร์เฟซ.