Pemulihan Bencana
Pemilihan situs DR
Situs pemulihan bencana harus cukup jauh agar tidak terkena bencana yang sama, dan cukup dekat untuk mode replikasi yang Anda perlukan. Dua batasan ini — ditambah fasilitas yang benar-benar ada di pasar kandidat — menentukan daftar singkat sebelum berkomunikasi dengan vendor. Alat berikut menjalankan ketiga-tiganya terhadap data nyata: waktu round-trip terukur antara 14 pasar, dan katalog 1629-fasilitas.
Pencari Pasangan DR
Pilih pasar utama Anda. Kandidat diurutkan berdasarkan waktu round-trip, dengan mode replikasi yang didukung setiap jarak.
| Kandidat DR | RTT | Mode Replikasi | Fasilitas di Pasar |
|---|
Angka RTT adalah pengukuran cloud inter-region yang dipublikasikan (Azure, cloudping.co) — sumber di matriks latensi. Rute serat optik antara fasilitas colocation mengikuti jalur serupa; verifikasi pasangan yang tepat dengan operator sebelum menetapkan target RPO untuk pasangan itu.
Mode replikasi ditentukan oleh fisika
Cahaya dalam serat optik menempuh sekitar 100 km per milidetik round trip. Angka tunggal tersebut menentukan arsitektur: replikasi sinkron memerlukan round trip dalam anggaran tulis aplikasi, yang membatasi jarak sekitar 100 km — dan semuanya yang lebih jauh adalah asinkron, apa pun yang dijanjikan lapisan penyimpanan.
| Mode | Anggaran RTT | RPO | Apa artinya |
|---|---|---|---|
| Sinkron | ≤ ~10 ms | Nol | Setiap write dikonfirmasi di kedua situs sebelum aplikasi melanjutkan. Latensi transaksi mencakup round trip, jadi jarak menjadi pajak aplikasi. |
| Hampir-sinkron | ~10–25 ms | Detik | Writes mengalir terus-menerus dengan konfirmasi fleksibel. Pilihan praktis untuk pasangan metro berdekatan seperti Frankfurt–Amsterdam atau Singapore–Kuala Lumpur. |
| Asinkron | Apa pun | Menit | Situs DR tertinggal berdasarkan interval replikasi. Satu-satunya opsi untuk jarak jauh — dan yang tepat untuk sebagian besar workload. |
Empat pola DR, harga jujur
Biaya dinyatakan sebagai bagian dari biaya operasional situs primer. Pola menentukan RTO; mode replikasi menentukan RPO; dan kombinasi keduanya menentukan anggaran. Sebagian besar infrastruktur menjalankan pola berbeda untuk tingkat workload berbeda — aktif-aktif untuk jalur revenue, cadangan-pemulihan untuk semua yang dapat menunggu sehari.
| Pola | RPO | RTO | Biaya vs primer | Cara kerjanya |
|---|---|---|---|---|
| Cadangan dan pemulihan | Jam–hari | Hari | ~5% | Cadangan direplikasi off-site, infrastruktur dibangun hanya saat bencana terjadi. Murah, lambat, dan pemulihan adalah yang tidak pernah diuji. |
| Cahaya pilot | Menit–jam | Jam | ~10–20% | Data inti direplikasi ke jejak minimal yang diskalakan ke atas saat failover. Beberapa rak di situs DR membawa database; komputasi tiba saat diperlukan. |
| Siaga hangat | Detik–menit | Menit–jam | ~30–50% | Salinan production yang diskalakan turun berjalan terus-menerus. Failover adalah aktivasi, bukan pembangunan. |
| Aktif-aktif | ≈ Nol | ≈ Nol | 100%+ | Kedua situs melayani traffic; kehilangan satu adalah peristiwa kapasitas, bukan pemadaman. Aplikasi harus dibangun untuk mendukung ini — retrofit memerlukan penulisan ulang. |
Model biaya jejak standby dengan estimator biaya colocation pada Index rate pasar target.
Apa yang benar-benar gagal
Perencanaan DR cenderung membayangkan gempa bumi. Log insiden menunjukkan bahwa ancaman nyata lebih dekat ke meter: gangguan daya listrik utilitas, kebakaran baterai UPS, kegagalan pendingin, dan kesalahan perangkat keras jaringan. Situs DR di grid yang sama, di dataran banjir yang sama, di belakang carrier hotel yang sama hampir tidak melindungi dari apapun di antara ini. Entri terbaru:
- 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
Daftar periksa situs DR
- Grid utilitas berbeda dari primary — verifikasi subestasi aktual, bukan klaim pemasaran
- Di luar dataran banjir dan zona seismik primary
- Jalur serat optik beragam: dua situs tidak boleh berbagi carrier hotel atau pendaratan kabel
- RTT diukur, bukan diestimasi — dan dalam anggaran mode replikasi yang dipilih
- Fasilitas bersertifikat sesuai dengan tingkat kepatuhan yang diperlukan — lihat direktori sertifikasi
- Kapasitas dapat diperluas sesuai kontrak: situs DR yang tidak dapat Anda skalakan saat bencana nyata hanyalah hiasan
- Remote hands dengan waktu respons terkontrak — saat peristiwa regional Anda tidak akan perlu terbang ke sana
- Failover diuji end-to-end sebelum go-live, kemudian setiap tahun — rencana bukan kemampuan
Pertanyaan yang sering diajukan
Seberapa jauh pusat data primer dan DR harus terpisah?
Jauh cukup agar tidak berbagi bencana, cukup dekat untuk mode replikasi Anda. Persyaratan minimum adalah jaringan listrik terpisah, dataran banjir terpisah, dan jalur pembawa terpisah — dalam praktik 50 km atau lebih. Replikasi sinkron membatasi jarak pada kira-kira 100 km (sekitar 10 ms round-trip); replikasi asinkron menghilangkan batasan sepenuhnya. Banyak regulator di Asia-Pasifik meminta DR lintas negara, yang memaksa asinkron.
Apa perbedaan antara RPO dan RTO?
RPO (recovery point objective) adalah berapa banyak data yang dapat Anda kehilangan, ditentukan oleh mode replikasi. RTO (recovery time objective) adalah berapa lama Anda dapat offline, ditentukan oleh pola DR — backup-restore pulih dalam hitungan hari, active-active dalam hitungan detik. Biaya meningkat dengan keduanya: mengetatkan salah satu satu orde besaran kira-kira menggandakan anggaran DR.
Dapatkah replikasi sinkron bekerja antar negara?
Hanya antara negara yang berdekatan. Singapore–Kuala Lumpur pada ~8 ms RTT mendukungnya; Frankfurt–Amsterdam pada ~11 ms berada di perbatasan. Apa pun yang lebih dari ~25 ms adalah wilayah asinkron, terlepas dari apa yang dikatakan lembar data vendor penyimpanan — setiap penulisan akan menanggung round-trip, dan tim aplikasi akan merasakannya sebelum tim DR melakukannya.
Apa yang sebenarnya menyebabkan pusat data turun?
Log insiden kami didominasi oleh peristiwa daya (gangguan utilitas dan kegagalan UPS), kebakaran (ruang baterai lithium-ion sering muncul), kegagalan pendingin dan kesalahan perangkat keras jaringan — bukan bencana alam regional. Implikasi praktis: situs DR di metro yang sama di jaringan yang sama hampir tidak memberikan perlindungan dari insiden yang benar-benar terjadi di tingkat fasilitas, sedangkan situs di negara yang berdekatan memberikan perlindungan dari hampir semua insiden.
Apakah cloud publik merupakan situs DR yang valid untuk beban kerja colocation?
Untuk pola backup-restore dan pilot-light, sering ya — Anda membayar kapasitas standby hanya saat berjalan, yang adalah model penetapan harga cloud yang tepat. Tangkapannya adalah egress pada perjalanan kembali dan celah operasional: memulihkan colocation estate ke infrastruktur cloud berarti mempertahankan dua target deployment secara permanen. Uji pemulihan penuh, bukan hanya replikasi.
Seberapa sering DR harus diuji?
Failover penuh setidaknya setiap tahun, pemulihan komponen setiap kuartal, dan setelah setiap perubahan infrastruktur yang material. Rencana DR yang tidak teruji adalah dokumen, bukan kemampuan — dan log insiden menunjukkan kegagalan terjadi terutama pada mekanisme yang sama (power switchover, cooling restart) yang hanya dapat diuji dengan tes nyata.
Membuat shortlist pasar DR?
Beritahu kami situs primer, RPO yang Anda butuhkan, dan rezim kepatuhan. Kami akan memberikan fasilitas di pasar DR yang layak, penetapan harga benchmark, dan pertanyaan penting untuk setiap operator.