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 6025-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-10-07Ransomware forces IDC Frontier to isolate its East Japan Region 1 data centerShirakawa, Fukushima, Japan
- 2026-10-08Google Cloud Storage write errors in us-central1 last about 12.5 hoursus-central1 (Iowa), United States
- 2026-09-30Azure gateway outage cuts ExpressRoute, VPN and Firewall connectivity across 18 regionsMulti-region (18 Azure regions, incl. West US, North Europe, Southeast Asia, Japan West, South Africa North)
- 2026-09-30West Java halts construction of BDx 640 MW CGK4 AI campus eight days after groundbreakingJatiluhur, Purwakarta, West Java, Indonesia
- 2026-09-29Fire: STT Seoul 1 (Gasan-dong)Seoul, South Korea
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.
Bandingkan penawaran colocation dari operator terverifikasi: gratis, dibalas dalam satu hari kerja
Minta Penawaran →