กลยุทธ์การสำรองข้อมูลอย่างง่ายสำหรับอินสแตนซ์ / เล่มของ Amazon EC2

คุณได้ป้อนข้อมูลสำรองเบื้องต้นสำหรับรูปภาพ Windows ที่สำรองไว้โดย Amazon EC2 EBS 010 ...

ฉันเรียกดูสมองของฉันเพื่อค้นหากลยุทธ์การสำรองข้อมูลอย่างง่าย ๆ สำหรับเซิร์ฟเวอร์ Windows 2008 เดียวที่ใช้งาน SharePoint Services นี่เป็นอิมเมจที่สำรองไว้ EBS ของเซิร์ฟเวอร์หนึ่งเครื่องที่มีปริมาณข้อมูลหนึ่ง ฉันไม่ต้องการอะไรแปลกใหม่ ฉันต้องการการสำรองข้อมูล "รายวัน" เท่านั้น (การสูญเสียข้อมูลต่อวันไม่ใช่ความหายนะ)

เราได้สร้างและบันทึกภาพ AMI ที่สนับสนุนโดย EBS (Windows 2008) ที่เราใช้งานได้อย่างสะดวกสบาย เราเริ่มทำการสำรองข้อมูลโดยเพียงแค่สร้างอิมเมจ EBS AMI ใหม่ มันง่ายมาก แต่เซิร์ฟเวอร์ที่ทำงานอยู่จะถูกทำให้ออฟไลน์ในช่วง 10 - 15 นาทีแรกของการสร้างภาพ - ไม่เหมาะ

วิธีมาตรฐานในการสร้างการสำรองข้อมูลดูเหมือนจะเป็นการสร้างสแน็ปช็อตของไดรฟ์ข้อมูลที่แนบกับอินสแตนซ์ที่กำลังทำงานอยู่ อีกครั้งมันค่อนข้างง่ายและเซิร์ฟเวอร์ยังคงใช้งานได้ในระหว่างการสร้างสแน็ปช็อต Catch-22 ที่เห็นได้ชัดคือคุณไม่สามารถเปิดตัวอินสแตนซ์ใหม่ได้โดยตรงจากสแน็ปช็อต

ฉันรู้วิธีรวมอินสแตนซ์ที่ทำงานอยู่กับที่จัดเก็บข้อมูล S3 แล้วลงทะเบียน AMI จากที่เก็บข้อมูล S3 นี่ทำให้ฉันสามารถสำรองข้อมูลอินสแตนซ์ที่กำลังทำงานอยู่ได้และหากอินสแตนซ์ที่ทำงานอยู่หายไปให้ลงทะเบียน AMI จากที่ฝากข้อมูล S3 และเปิดตัว AMI ใหม่เพื่อกู้คืนอินสแตนซ์ แต่นี่ดูเหมือนจะซับซ้อนจริง ๆ สลับไปมาระหว่าง AWS Console และปลั๊กอิน S3 Organizer สำหรับ Firefox เพื่อให้สิ่งนี้สำเร็จ (โปรดอย่าพูดถึงวิธีบรรทัดคำสั่งนี่เป็นหลักสูตรระดับ 010)

จากการเล่นกับภาพที่ได้รับการสนับสนุนจาก EBS วิธีการต่อไปนี้ดูเหมือนจะใช้ได้สำหรับฉัน (ทำในคอนโซล AWS):

1. สำหรับการสำรองข้อมูลของคุณเพียงแค่ถ่ายภาพระดับเสียงของระบบ (/ dev / sda1) ตามต้องการ 2. หากคุณทำอินสแตนซ์ที่ทำงานอยู่ให้ทำดังนี้: a. สร้างโวลุ่มใหม่จากสำเนาสำรองสแน็ปช็อตครั้งล่าสุดของคุณ b. เปิดใช้งานอินสแตนซ์อื่นของ AMI เริ่มต้นของคุณ (ต้องเป็น EBS d. ถอดไดรฟ์ข้อมูลระบบที่มีอยู่จากอินสแตนซ์หยุดทำงานใหม่และยกเลิก e.Attach ปริมาณที่สร้างขึ้นใหม่เป็นปริมาณระบบ (/ dev / sda1) กับอินสแตนซ์ที่หยุด f. เริ่มอินสแตนซ์ใหม่อีกครั้ง ฉันได้ทำการทดสอบสองสามครั้งและดูเหมือนว่าจะได้ผลสำหรับฉัน

คำถาม: มีวิธีการใดที่ผิดปกติหรือไม่?

วิธีการของคุณฟังดูดีมาก - แต่ฉันสามารถคิดถึงวิธีที่เป็นไปได้ในการปรับปรุง

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

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

ฉันสร้างสแน็ปช็อตสำหรับทุกโวลุ่มในบัญชีของฉันโดยใช้สคริปต์ทุบตี

#!/bin/bash

ec2-describe-volumes | awk '{ print $2 }' | sort -u >  /tmp/ebs_volumes

for i in $(cat /tmp/ebs_volumes); do
   echo $i;
   ec2-create-snapshot $i;
done

นี่คือสคริปต์ที่จะสร้างการสำรองข้อมูล AMI สำหรับทุกอินสแตนซ์ ec2 ภายใน VPC ของคุณ

#!/bin/bash
#Script to Automate AMI backup

echo "----------------------------------\n   `date`   \n----------------------------------"

aws ec2 describe-instances --filters Name=vpc-id,Values=vpc-xxx |   awk '{ print $8 }' | sort -n   | grep  "i-" > /tmp/instanceid.txt

echo "Starting the Daily AMI creation: "

 #To create AMI from instance-id 

for i in $(cat /tmp/instanceid.txt); do
        echo "Creating AMI for Instance id $i ......."


echo "instance-`date +%d%b%y`-$i" > /tmp/aminame.txt

aws ec2 create-image --instance-id $i --name "`cat /tmp/aminame.txt`" --description "This is created by ami-backup.sh" --no-reboot | grep -ir ami | awk '{print $4}' > /tmp/amiID.txt

echo  "AMI Name is: `cat /tmp/aminame.txt`\n"

done

echo done