Bali, Indonesia
Insights

Backup Offsite di Singapura atau Tetap di Indonesia? Cek Dulu Jalur Kabel Lautnya

October 31, 2026
0:00
Backup offsite di Singapura sering dianggap pilihan paling aman. Lokasinya beda negara, beda datacenter, dan latency dari Jakarta rendah. Masalahnya, beda negara belum tentu berarti beda jalur. Kalau server utama ada di Indonesia dan backup di Singapura, koneksi di antara keduanya biasanya lewat kabel laut yang juga dipakai sebagian besar trafik internasional kita. Di artikel ini kita telusuri cara mengecek apakah backup kamu benar-benar terpisah, dan bagian mana yang sebenarnya perlu dipisahkan.
Pola yang sering muncul begini. Server utama terlihat normal, website bisa diakses pengunjung lokal, tapi job backup ke Singapura tiba-tiba jauh lebih lambat atau gagal dengan pesan timeout atau connection reset. Replikasi database ke lokasi offsite tertinggal. Kalau kebetulan sedang perlu restore, transfer data dari Singapura berjalan pelan sekali. Di meja support, pertanyaan pertama dari pemilik server biasanya: disk saya penuh atau backup saya rusak? Sering kali dua-duanya tidak. Log backup cuma menunjukkan koneksi yang lambat atau putus di tengah transfer, sementara disk dan proses di kedua sisi sehat. Kalau polanya begitu, yang perlu dicek adalah jalur jaringan di antara kedua lokasi, bukan servernya.
Singapura adalah salah satu hub digital utama di kawasan ini. Sebagian besar trafik internet internasional Indonesia, yang diperkirakan sekitar 80% hingga 90%, selama ini bergantung pada jalur yang melalui atau terhubung dengan Singapura. Salah satu titik pentingnya adalah Batam, khususnya kawasan Nongsa Digital Park, yang terhubung ke Singapura lewat Sistem Komunikasi Kabel Laut (SKKL) seperti Batam Singapore Cable System (BSCS) dan jalur-jalur yang lebih baru. Hubungannya juga berlaku dua arah. Banyak kabel laut global yang mendarat di Singapura melintasi perairan Indonesia, jadi gangguan besar di infrastruktur itu tidak hanya terasa di Indonesia, tapi juga bisa mengganggu sebagian besar konektivitas Singapura. Bagi backup, artinya sederhana. Server di Jakarta dan backup di Singapura memang terpisah secara fisik. Kebakaran atau mati listrik di satu datacenter tidak akan menyentuh datacenter yang lain. Tapi jalur di antara keduanya sering kali sama dengan jalur yang dipakai trafik internasional lain. Kalau jalur itu terganggu, data di Singapura tidak hilang, hanya jadi sulit dijangkau. Trafik biasanya dialihkan ke kabel lain, latency naik, dan kapasitas yang tersisa dipakai bersama banyak pihak. Backup tetap aman, tapi restore bisa jauh lebih lama dari yang kamu rencanakan. Untuk pertimbangan dari sisi pengunjung website, bukan backup, pembahasannya ada di artikel Memilih Lokasi Server Indonesia atau Singapura di Hosting Lokal.
Jalur dari laptop kamu ke server backup tidak ada hubungannya dengan jalur yang dipakai job backup. Jalankan pengecekan langsung dari server utama ke alamat tujuan backup, dan kalau bisa, juga dari arah sebaliknya. Routing internet sering asimetris, jadi jalur pergi dan jalur pulang bisa berbeda. mtr cocok untuk ini karena menggabungkan traceroute dan ping. Opsi -z menampilkan nomor AS (Autonomous System, identitas jaringan milik satu operator) di tiap hop, jadi kamu bisa melihat di mana trafik pindah dari satu jaringan ke jaringan lain. Kalau backup berjalan lewat SSH atau rsync, uji juga dengan TCP ke port yang sama, karena sebagian router memperlakukan ICMP berbeda dari TCP.
BASH
# Laporan 100 paket, tampilkan IP + hostname + nomor AS
mtr -rwbz -c 100 backup.contoh.id

# Uji dengan TCP ke port SSH, sama seperti jalur rsync/SSH backup
mtr -rwbz -T -P 22 -c 100 backup.contoh.id
Perintah di atas hanya membaca dan tidak mengubah apa pun. Di sebagian sistem, mode TCP butuh hak root. Berikut contoh format output dengan IP dan ASN dokumentasi. Ini bukan data jaringan sungguhan:
TEXT
HOST: server-utama                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS64500  gw.dc-jkt.contoh (192.0.2.1)    0.0%   100    0.5   0.5   0.3   1.0   0.1
  2. AS64500  core.jkt.contoh (192.0.2.9)     0.0%   100    1.0   1.1   0.9   2.0   0.2
  3. AS64501  edge.btm.transit (198.51.100.5)  0.0%   100   10.0  10.2   9.8  12.0   0.3
  4. AS64502  ix.sin.transit (198.51.100.20)   0.0%   100   15.0  15.1  14.9  17.0   0.2
  5. AS64510  backup.contoh.id (203.0.113.10)  0.0%   100   15.0  15.2  15.0  16.0   0.1
Cara membacanya: perhatikan hop tempat nomor AS berganti, dan hop tempat latency naik lalu stabil di level baru. Kenaikan seperti itu biasanya menandai lompatan antarkota atau antarnegara. Sebagian operator memasukkan kode kota di hostname router, tapi tidak ada standarnya, jadi anggap itu petunjuk, bukan bukti. Simpan hasilnya. Hasil pengecekan saat jaringan normal jadi pembanding yang berguna ketika nanti backup mulai lambat.
Ada beberapa asumsi yang perlu dicoret dulu sebelum mengambil kesimpulan. Beda provider tidak berarti beda jalur. Dua provider bisa membeli transit dari upstream yang sama, sehingga trafiknya bertemu di router dan kabel yang sama. Hasil mtr dengan nomor AS biasanya langsung memperlihatkan hal ini. Backup di Indonesia juga belum tentu bebas dari Singapura. Kalau jaringan server utama dan jaringan lokasi backup tidak saling peering di dalam negeri, trafik antar dua kota di Indonesia bisa memutar keluar dulu lalu masuk lagi. Tandanya di mtr: latency melonjak di tengah jalan, padahal kedua ujungnya ada di Indonesia. Kalau itu yang terlihat, backup domestik kamu ternyata tetap bergantung pada jalur internasional. Latency rendah ke Singapura bukan bukti jalurnya aman. Angka kecil hanya berarti jalurnya pendek dan langsung. Jalur langsung yang paling ramai justru biasanya dipakai bersama paling banyak trafik. Packet loss di hop tengah, sementara hop terakhir bersih, biasanya bukan masalah. Banyak router membatasi balasan ICMP untuk dirinya sendiri. Yang perlu diperhatikan adalah loss yang muncul di satu hop lalu terbawa sampai tujuan.
Setelah jalurnya jelas, bedakan tiga jenis risiko yang sering tercampur. Risiko fisik datacenter, seperti kebakaran, listrik, atau bencana di satu lokasi. Untuk risiko ini, backup di Singapura sudah memadai karena lokasinya memang jauh. Risiko jalur jaringan. Risiko ini tidak menghapus data, tapi menentukan seberapa cepat kamu bisa restore dan seberapa jauh replikasi tertinggal. Kalau kamu bisa menerima restore yang lambat saat jalur internasional terganggu, Singapura tetap masuk akal. Kalau kamu perlu memulihkan layanan untuk pengguna Indonesia secepatnya, pertimbangkan salinan kedua di kota lain di Indonesia, di jaringan yang hasil mtr-nya terbukti tidak memutar ke luar negeri. Risiko akun dan akses. Satu provider, satu panel, dan kredensial yang tersimpan di server utama berarti satu kebocoran bisa mengenai produksi sekaligus backup. Ini sering terlewat karena orang terlalu fokus pada lokasi. Pegangan klasik 3-2-1 (tiga salinan, dua media, satu di luar lokasi) tetap relevan di sini. Satu catatan tambahan: salinan offsite sebaiknya punya kredensial terpisah, dan pastikan juga bisa benar-benar di-restore. Langkahnya ada di Cara Memastikan Backup WHM Benar-Benar Bisa Di-restore Sebelum Dibutuhkan.
Label region di halaman order tidak cukup. Tanyakan hal berikut, dan kalau jawabannya mengambang, minta hasil traceroute atau akses looking glass (alat tes jaringan dari sisi provider) kalau tersedia:
  1. Di kota mana datacenter fisiknya, dan apakah lokasi backup dan server utama berada di gedung atau kota yang berbeda.
  2. Upstream transit apa saja yang dipakai, dan apakah ada lebih dari satu jalur keluar internasional.
  3. Apakah jaringan mereka terhubung ke internet exchange lokal dan peering dengan jaringan tempat server utama kamu berada.
  4. Untuk lokasi Singapura: apakah koneksi dari Indonesia bergantung pada satu sistem kabel, atau punya jalur alternatif selain lewat Batam.
  5. Apakah ada cara restore yang tidak bergantung penuh pada transfer lewat internet publik, dan berapa lama prosesnya biasanya.
  6. Apakah akses ke storage backup bisa memakai kredensial dan akun yang terpisah dari server produksi.
Jawaban provider tetap perlu kamu cocokkan dengan hasil mtr sendiri dari server utama. Yang menentukan adalah jalur yang benar-benar dilalui trafikmu, bukan yang tertulis di dokumen. Intinya, memilih Singapura atau tetap di Indonesia bukan soal mana yang lebih aman secara umum. Keduanya melindungi dari risiko yang berbeda. Jalankan mtr dari server utama ke setiap kandidat lokasi backup, catat di mana nomor AS dan latency berubah, lalu putuskan berdasarkan berapa lama kamu sanggup menunggu restore saat jalur internasional sedang bermasalah. Kalau jawabannya tidak bisa lama, simpan satu salinan di lokasi yang jalurnya memang terpisah, bukan hanya beda alamat.