การกู้คืนหลังเกิดภัย
การเลือกไซต์ DR
ไซต์ disaster recovery ต้องอยู่ห่างไกลเพียงพอที่จะไม่ได้รับผลกระทบจากภัยพิบัติเดียวกัน และใกล้เพียงพอสำหรับ replication mode ที่คุณต้องการ ข้อจำกัดทั้งสองประการนี้ — บวกกับ facility ที่มีอยู่จริงในตลาดผู้สมัครใจ — กำหนดรายชื่อย่อก่อนการสนทนากับผู้ขาย เครื่องมือด้านล่างนี้จะประเมินทั้งสามข้อกับข้อมูลจริง: เวลาไป-กลับที่วัดได้ระหว่าง 14 ตลาด และ แคตตาล็อก 1629 facility
ตัวค้นหา DR pair
เลือกตลาดหลักของคุณ ผู้สมัครจะได้รับการจัดอันดับตามเวลาไป-กลับ พร้อมกับ replication mode ที่แต่ละระยะทางรองรับ
| สถานที่สำรอง DR | RTT | Replication ที่รองรับ | Facility ในตลาด |
|---|
ตัวเลข RTT คือการวัด cloud inter-region ที่เผยแพร่ (Azure, cloudping.co) — แหล่งที่มาบน latency matrix เส้นทางไฟเบอร์ระหว่าง colocation facility ปฏิบัติตามเส้นทางที่คล้ายกัน ยืนยันคู่ที่ถูกต้องกับผู้ดำเนินการก่อนการให้ RPO กับมัน
Replication mode ถูกกำหนดโดยฟิสิกส์
แสงในไฟเบอร์เดินทางประมาณ 100 กม. ต่อมิลลิวินาทีของ round trip ตัวเลขเพียงตัวเดียวนี้เป็นตัวกำหนด architecture: synchronous replication จำเป็นต้องให้เวลา round trip อยู่ในงบประมาณการเขียนของแอปพลิเคชัน ซึ่งจำกัดระยะทางไว้ประมาณ 100 กม. ส่วนระยะทางไกลกว่านั้นต้องเป็น asynchronous ไม่ว่า storage layer จะสัญญาอะไรก็ตาม
| โหมด | งบประมาณ RTT | RPO | ความหมาย |
|---|---|---|---|
| ซิงโครนัส | ≤ ~10 ms | ศูนย์ | ทุกการเขียนได้รับการยืนยันที่ทั้งสองไซต์ก่อนแอปพลิเคชันดำเนินการต่อ ความล่าช้าของธุรกรรมรวมเวลาการเดินทางไปกลับ ดังนั้นระยะทางจึงกลายเป็นต้นทุนสำหรับแอปพลิเคชัน |
| เกือบซิงโครนัส | ~10–25 ms | วินาที | การเขียนไหลต่อเนื่องโดยการยืนยันผ่อนคลาย ตัวเลือกที่ใช้ได้จริงสำหรับคู่เมืองใกล้กันเช่น Frankfurt–Amsterdam หรือ Singapore–Kuala Lumpur |
| แบบอะซิงโครนัส | ใดก็ได้ | นาที | ไซต์ DR ล่าช้าตามช่วงเวลาการจำลองข้อมูล ตัวเลือกเดียวสำหรับระยะทางไกล — และเป็นตัวเลือกที่ถูกต้องสำหรับ workload ส่วนใหญ่ |
สี่แบบ DR ตั้งราคาอย่างซื่อสัตย์
ต้นทุนแสดงเป็นส่วนแบ่งของต้นทุนการทำงานของไซต์หลัก แบบรูปแบบกำหนด RTO โหมดการจำลองข้อมูลกำหนด RPO และการรวมกันกำหนดงบประมาณ ส่วนใหญ่ใช้แบบรูปแบบต่างๆ สำหรับระดับ workload ต่างๆ — active-active สำหรับเส้นทางรายได้ และ backup-restore สำหรับทุกสิ่งที่สามารถรอได้วันหนึ่ง
| รูปแบบ | RPO | RTO | ต้นทุนเทียบกับไซต์หลัก | วิธีการทำงาน |
|---|---|---|---|---|
| สำรองและกู้คืน | ชั่วโมง–วัน | วัน | ~5% | สำรองข้อมูลจำลองไปสถานที่อื่น โครงสร้างพื้นฐานสร้างเมื่อเกิดภัยพิบัติ ราคาถูก ช้า และการกู้คืนคือส่วนที่ยังไม่มีใครทดสอบ |
| ระบบรอพร้อม | Minutes–hours | Hours | ~10–20% | ข้อมูลแก่นกลางจำลองไปยังพื้นที่ขั้นต่ำที่ขยายตัวเมื่อ failover racks เพียงไม่กี่ตัวที่ไซต์ DR บรรจุฐานข้อมูล compute มาเมื่อต้องการ |
| ระบบอุ่น | Seconds–minutes | Minutes–hour | ~30–50% | สำเนาขนาดเล็กของ production ทำงานอย่างต่อเนื่อง failover คือการเลื่อนระดับ ไม่ใช่การสร้างใหม่ |
| Active-active | ≈ ศูนย์ | ≈ ศูนย์ | 100%+ | ไซต์ทั้งสองให้บริการ traffic การสูญเสียไซต์หนึ่งเป็นเหตุการณ์ด้านความจุ ไม่ใช่ outage ต้องสร้างแอปพลิเคชันสำหรับสิ่งนี้ — retrofitting คือการเขียนใหม่ |
คำนวณต้นทุน footprint ของ standby ด้วย colocation cost estimator ที่ Index rate ของตลาดเป้าหมาย
สิ่งที่ล้มเหลวจริง
การวางแผน DR มักจะตั้งสมมติฐานเกี่ยวกับแผ่นดินไหว แต่ incident log แสดงว่าภัยคุกคามจริงอยู่ใกล้มิเตอร์มากขึ้น: การหยุดไฟฟ้าขาเข้า ไฟขัดข้องแบตเตอรี่ UPS ความล้มเหลวระบายความร้อน และฮาร์ดแวร์เครือข่ายบกพร่อง ไซต์ DR บนตารางไฟฟ้าเดียวกัน ในพื้นที่น้ำท่วมเดียวกัน เบื้องหลัง carrier hotel เดียวกัน ป้องกันสิ่งเหล่านี้เกือบไม่ได้ รายการล่าสุด:
- 2026-09-01Google Cloud: network degradation in us-central1-b takes down 15 products for up to 4h08mus-central1-b (Council Bluffs, Iowa)
- 2026-08-31Microsoft 365: authentication-configuration fault disrupts Exchange Online, Teams, SharePoint and Defender XDR for multiple daysGlobal (Microsoft 365 cloud services)
- 2026-08-27Proton: total cooling failure at Frankfurt datacenter takes down Mail, VPN, Drive and Pass for 2h18mFrankfurt, Germany (Proton-operated datacenter)
- 2026-08-20Google Cloud us-west1 (Oregon) region: multi-service degradation for about 3h40mus-west1 region (The Dalles, Oregon)
- 2026-08-17GitHub outage: retry storm and Central US datacenter network saturation cause 7h47m disruption to Issues, PRs, Actions and CopilotCentral US datacenter region, with failover traffic routed to Northern Virginia
รายการตรวจสอบไซต์ DR
- ตารางไฟฟ้าขาเข้าต่างจากหลัก — ตรวจสอบสถานีย่อยจริง ไม่ใช่คำกล่าวประชาสัมพันธ์
- อยู่นอกพื้นที่น้ำท่วมและโซนแผ่นดินไหวของไซต์หลัก
- เส้นทาง fiber ที่แตกต่างกัน: ไซต์ทั้งสองต้องไม่ใช้ carrier hotel หรือจุดลงจ่ายเคเบิลร่วมกัน
- RTT ที่วัด ไม่ใช่ประมาณการ — และอยู่ในงบประมาณของโหมด replication ที่เลือก
- สิ่งอำนวยความสะดวกได้รับการรับรองตามระดับที่ผู้กำกับดูแลคาดหวัง — ตรวจสอบ ไดเรกทอรี่การรับรอง
- ความจุสามารถขยายได้ตามสัญญา: ไซต์ DR ที่ไม่สามารถ scale ระหว่างภัยพิบัติที่แท้จริงเป็นเพียงการตกแต่ง
- Remote hands ที่มีเวลาตอบสนองตามสัญญา — ในเหตุการณ์ระดับภูมิภาค คุณจะไม่ต้องบินเข้ามา
- Failover ทดสอบ end-to-end ก่อนเปิดตัว จากนั้นทุกปี — แผนไม่ใช่ความสามารถ
คำถามที่พบบ่อย
ศูนย์ข้อมูล Primary และ DR ควรห่างกันเท่าไร
ไกลพอที่ไม่ต้องแบ่งปันภัยพิบัติ ใกล้พอสำหรับโหมด replication ของคุณ ขั้นต่ำคือ utility grids แยก flood plains แยก และ carrier paths แยก — ในทางปฏิบัติ 50 กม. ขึ้นไป Synchronous replication จำกัดระยะห่างประมาณ 100 กม. (ประมาณ 10 ms round-trip); asynchronous replication ลบขีดจำกัดไปแล้ว ผู้กำกับดูแลจำนวนมากในเอเชีย-แปซิฟิก ต้องการ out-of-country DR ซึ่งบังคับให้ใช้ async
ความแตกต่างระหว่าง RPO และ RTO คืออะไร
RPO (recovery point objective) คือปริมาณข้อมูลที่คุณยอมรับได้ที่จะสูญหาย กำหนดโดยโหมด replication RTO (recovery time objective) คือระยะเวลาที่คุณยอมรับได้ที่จะออฟไลน์ กำหนดโดย DR pattern — backup-restore กู้คืนในหน่วยวัน active-active ในวินาที ค่าใช้จ่ายเพิ่มตามทั้งสอง: การทำให้เข้มงวดขึ้นหนึ่งลำดับขนาดจะทำให้งบประมาณ DR เพิ่มขึ้นประมาณสองเท่า
Synchronous replication ทำงานระหว่างประเทศได้หรือไม่
เฉพาะระหว่างประเทศที่อยู่ติดกันเท่านั้น สิงคโปร์–กัวลาลัมเปอร์ ที่ ~8 ms RTT รองรับได้; แฟรงก์เฟิร์ต–อัมสเตอร์ดัม ที่ ~11 ms อยู่ที่ขอบเขต สิ่งใดๆ ที่เกิน ~25 ms เป็น asynchronous territory ไม่ว่า datasheet ของผู้ขายพื้นที่เก็บข้อมูลจะบอกอะไร — write ทุกครั้งจะดำเนิน round trip และทีม application จะรู้สึกก่อนทีม DR
อะไรที่ทำให้ศูนย์ข้อมูลหยุดทำงาน
บันทึกเหตุการณ์ของเรา ครอบงำโดย power events (utility disturbances และ UPS failures) ไฟไหม้ (lithium-ion battery rooms ปรากฏซ้ำๆ) cooling failures และ network hardware faults — ไม่ใช่ภัยพิบัติธรรมชาติระดับภูมิภาค ผลในทางปฏิบัติ: ไซต์ DR ในเมืองเดียวกัน บนกริดเดียวกัน ป้องกันเหตุการณ์ที่เกิดขึ้นจริงที่ระดับ facility เกือบไม่มี ในขณะที่ไซต์ต่างประเทศ ป้องกันเกือบทั้งหมด
Public cloud เป็นไซต์ DR ที่เหมาะสมสำหรับ colocation workloads หรือไม่
สำหรับ backup-restore และ pilot-light patterns มักจะใช่ — คุณจ่ายสำหรับ standby capacity เฉพาะเมื่อทำงาน ซึ่งเป็น cloud pricing model พอดี ข้อเสีย คือ egress ในการกลับมา และช่องว่าง operational: การกู้คืน colocation estate ไปยัง cloud infrastructure หมายถึงรักษา deployment targets สองอย่างอย่างถาวร ทดสอบ full restore ไม่ใช่ replication
ควรทดสอบ DR บ่อยแค่ไหน
Full failover อย่างน้อยปีละครั้ง component restores ทุกไตรมาส และหลังจากการเปลี่ยนแปลง infrastructure ที่สำคัญ DR plan ที่ไม่ได้ทดสอบเป็นเอกสาร ไม่ใช่ความสามารถ — บันทึกเหตุการณ์แสดงให้เห็นความล้มเหลวกระจุกตัวใน mechanisms เดียวกัน (power switchover cooling restart) ที่เพียง real test เท่านั้นทำได้
ต้องการคัดเลือกตลาด DR
บอกเราถึง primary site RPO ที่คุณต้องการ และ compliance regime เราจะกลับมาพร้อม facilities ในตลาด DR ที่ทำได้ benchmark pricing และคำถามที่คุ้มค่าที่จะถามผู้ประกอบการแต่ละราย