การวางแผนสำหรับภัยพิบัติ

ฉันทำงานให้กับ บริษัท การตลาดขนาดเล็กที่ทำหน้าที่ออกแบบและพัฒนาเว็บไซต์ด้วย เราโฮสต์การออกแบบเว็บและการพัฒนาลูกค้าของเราบนเซิร์ฟเวอร์เฉพาะที่ Hostgator เรามีเซิร์ฟเวอร์เฉพาะที่มีฮาร์ดไดรฟ์ที่กำหนดค่า RAID 1 นอกจากนี้เรายังทำการสำรองข้อมูลรายสัปดาห์โดยอัตโนมัติผ่าน cPanel และดาวน์โหลดโดยซอฟต์แวร์ FTP อัตโนมัติในพื้นที่

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

ไม่จำเป็นต้องพูดว่าเราต้องการเตรียมพร้อมสำหรับเหตุการณ์ประเภท "สถานการณ์ที่เลวร้ายที่สุด" เนื่องจากจะทำให้เราต้องเลิกกิจการ ดังนั้นคำถามสองข้อของฉันคือ:

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

2. แผนสำรองที่มีประสิทธิภาพจะรวมข้อมูลสำคัญใดไม่เคยสูญหาย ทางออกที่ดีจะเป็นไปโดยอัตโนมัติ

คุณสามารถสันนิษฐานได้ว่าค่าใช้จ่ายไม่ใช่ปัญหาในคำตอบของคุณ

ฉันขอแนะนำให้คุณ:

1. ทำมิเรอร์เนื้อหาทั้งหมดและการกำหนดค่าเซิร์ฟเวอร์หลักของคุณโดยอัตโนมัติไปยังเซิร์ฟเวอร์สำรองข้อมูลสำรองบนเครือข่ายที่แยกจากกันโดยสิ้นเชิงในศูนย์ข้อมูลอื่น ใช้ RSync, FXP, cPanel วูดูหรือวิธีการใด ๆ ที่คุณต้องการทำการซิงค์โดยอัตโนมัติ

2. ใช้ DNS failover switchingเพื่อกำหนดเส้นทางทราฟฟิกไปยังเซิร์ฟเวอร์สำรองโดยอัตโนมัติหากเซิร์ฟเวอร์ Hostgator ไม่ตอบสนอง

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

คุณสามารถตั้งค่า DNS ล้มเหลวโดยใช้ผู้ให้บริการเช่นDNS Made Easy สำหรับแต่ละโดเมนที่คุณโฮสต์คุณจะตั้งค่าที่อยู่ IP สำรองได้สูงสุดห้าที่อยู่หนึ่งแห่งสำหรับเซิร์ฟเวอร์สำรองแต่ละแห่งของคุณ เมื่อเสร็จแล้ว ...

1. DNS Made Easy ตรวจสอบเซิร์ฟเวอร์หลักของคุณเป็นเวลาสองถึงสี่นาทีและหากไม่พบการตอบสนองก็จะกำหนดเส้นทางการรับส่งข้อมูลไปยังที่อยู่ IP สำรอง

2. DNS Made Easy ยังคงตรวจสอบเซิร์ฟเวอร์หลัก เมื่อมาถึงมันจะเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังเซิร์ฟเวอร์เครื่องแรกหรือ - หากคุณต้องการ - เก็บไว้ที่การสำรองข้อมูลในขณะที่คุณวิเคราะห์สิ่งที่ผิดพลาดและแก้ไขเซิร์ฟเวอร์หลัก

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

นอกเหนือจากนั้น:

ทำซ้ำทำซ้ำทำซ้ำ

การสำรองข้อมูลที่อิสระมากขึ้นคุณมีมากขึ้น ฉันจัดเก็บข้อมูลสำรองระยะไกลไว้ในฮาร์ดไดรฟ์ภายในเครื่องซึ่งถูกทำมิเรอร์ไปยังฮาร์ดไดรฟ์ภายนอกไปยัง Dropbox, ที่เก็บ git และบัญชี FTP ระยะไกล ไม่มีโอกาส ทำซ้ำให้มากที่สุด หากคุณต้องกู้คืนจากการสำรองข้อมูลด้วยตนเองจะดีกว่าถ้ามีตัวเลือกห้าตัวเลือก ความหวาดระแวง underrated

ฝึกการเรียกคืนการสำรองข้อมูลด้วยตนเอง

หากคุณไม่เคยพยายามกู้คืนจากหนึ่งในข้อมูลสำรองของคุณคุณจะรู้ได้อย่างไรว่ามันทำงานอย่างไร ควรทำการฝึกซ้อมฉุกเฉินเพื่อดูว่าจะเกิดอะไรขึ้นหากกระบวนการอัตโนมัติของคุณล้มเหลว

• Cloudflareซึ่งเป็นผู้ให้บริการด้านความปลอดภัยและการแคชเพื่อให้ไซต์ทำงานต่อเมื่อเซิร์ฟเวอร์ของคุณหยุดทำงาน (พวกเขาทำมิเรอร์ไซต์ของคุณและให้บริการจากแคชกระจายทั่วโลกแทนที่จะมาจากเซิร์ฟเวอร์ของคุณโดยตรง)
• Codeguardผู้ให้การสำรองข้อมูลอัตโนมัติและการย้อนกลับของรหัสเว็บไซต์ (FTP เท่านั้น)
• การสำรองข้อมูลอัตโนมัติของไซต์ซึ่งให้การสำรองข้อมูลอัตโนมัติและการย้อนกลับของรหัสเว็บไซต์ข้อมูลอีเมลและข้อมูล MySQL ผ่านการสำรองข้อมูล cPanel โปรดทราบว่าสิ่งนี้ดำเนินการโดย Hostgator ดังนั้นจึงไม่เหมาะหากคุณโฮสต์เว็บไซต์ของคุณด้วย แต่อาจช่วยผู้อื่นได้

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

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

RTOนั้นเป็นสิ่งที่คาดหวังว่าจะใช้เวลานานเท่าใดจนกว่าจะมีการสำรองข้อมูล หากคุณมี RTO หนึ่งหรือสองนาที (หรือน้อยกว่า) คุณควรพิจารณาโซลูชันที่สอดคล้องกับสิ่งที่ Nick แนะนำซึ่งเกี่ยวข้องกับการเรพลิเคตไฟล์และข้อมูลแบบเรียลไทม์ของคุณไปยังศูนย์ข้อมูลรองและ DNS อัตโนมัติล้มเหลว ทำได้ด้วยบริการแบบชำระเงินหรือกับฮาร์ดแวร์ที่ศูนย์ข้อมูลทั้งสอง (เช่นBIG-IP Global Traffic Managerจากเครือข่าย F5 สิ่งนี้อาจได้รับค่าใช้จ่ายสูง แต่ส่วนใหญ่ขึ้นอยู่กับการตอบคำถาม "ค่าใช้จ่ายในการหยุดทำงานคืออะไร" หาก RTO ของคุณใช้เวลาสองสามชั่วโมงหรือสองสามวันคุณสามารถพิจารณาขั้นตอนการกู้คืนความเสียหายที่อาจเกี่ยวข้องกับการมีส่วนร่วมมากขึ้นเช่นการนำเซิร์ฟเวอร์ออนไลน์การเปลี่ยน DNS ฯลฯ น่าเบื่อ แต่คุ้มค่าแน่นอนถ้า RTO ของคุณอนุญาต

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

ดังที่ฉันได้กล่าวไปแล้วฉันเห็นด้วยกับสิ่งที่นิคพูดมาก อีกทางเลือกหนึ่งที่คุณอาจต้องการพิจารณาคือการใช้บริการบนคลาวด์จากหนึ่งในผู้ให้บริการคลาวด์ขนาดใหญ่เช่น Rackspace หรือ Amazon ผู้ให้บริการทั้งสองรายนี้มีโครงสร้างพื้นฐานขนาดใหญ่ที่สามารถรับมือกับภัยพิบัติที่เกิดขึ้นได้ ด้วยบางสิ่งบางอย่างเช่นไซต์คลาวด์หรือเซิร์ฟเวอร์คลาวด์ (คำศัพท์ที่ใช้โดย Rackspace) คุณจะได้เปรียบในการขยายขนาดและไม่จำเป็นต้องกังวลเกี่ยวกับลักษณะทางกายภาพของฮาร์ดแวร์

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

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

หวังว่าสิ่งนี้จะช่วยได้

แก้ไข : คิดว่านี่อาจช่วยได้หากคุณกำลังประเมินโซลูชันคลาวด์ รายงานGartner Magic Quadrant สำหรับโครงสร้างพื้นฐานและในฐานะที่เป็นบริการและเว็บโฮสติ้งอาจให้ข้อมูลเชิงลึกเกี่ยวกับผู้ให้บริการโซลูชันอื่น ๆ

การเรพลิเคทเซิร์ฟเวอร์แบบสมบูรณ์ที่สถานที่อื่นของ บริษัท โฮสติ้งอื่นดูเหมือนจะเป็นทางออกที่ชัดเจนที่สุด

ไฟล์สามารถถูกซิงค์กับเครื่องมือต่าง ๆ เช่น rsync และ unison การสำรองข้อมูล SQL สามารถ rsynced ด้วยแล้วอัปโหลดไปยัง slave db โดยสคริปต์

ตรวจสอบให้แน่ใจว่าคุณใช้การควบคุมเวอร์ชันของรหัสทั้งหมดของคุณด้วยที่เก็บซอร์สโค้ด (SVN หรือ GIT) คุณใช้ SVN หรือ GIT หรือไม่

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

คุณสามารถดำเนินการ SVN ของคุณกระทำ / เช็คเอาต์ผ่านบรรทัดคำสั่งหรือผ่านไคลเอนต์เช่นรุ่น (สำหรับ Mac) หรือ TortoiseSVN (สำหรับ Windows)