Migrasi ke Hosting Offshore Tanpa Downtime

Tidak ada yang memindahkan situs yang sedang live demi hiburan. Ini terjadi karena host yang sekarang tiba-tiba meminta foto paspor Anda, atau meneruskan komplain dengan tenggat dua puluh empat jam, atau karena negara tempat datacenter-nya berada sudah tidak lagi terlihat sebagai tempat yang masuk akal untuk menyimpan data Anda. Apa pun yang mendorong Anda, proses pindahnya sendiri adalah bagian yang berbahaya — inilah satu-satunya momen situs bisa padam, dan satu-satunya momen langkah ceroboh bisa menempelkan server baru pada identitas yang sedang Anda coba tinggalkan.

Kedua risiko itu punya obat yang sama, dan itu bukan sebuah tool. Itu adalah urutan. Migrasi yang dijalankan dalam urutan yang tepat tidak punya jendela waktu di mana situs tidak bisa diakses, karena kedua server hidup pada saat bersamaan dan DNS adalah hal terakhir yang dipindahkan. Migrasi yang dijalankan dalam urutan yang salah menghasilkan outage sekaligus jejak. Berikut ini adalah urutan tersebut, ditulis untuk orang yang pindah ke host offshore, no-KYC, bukan sekadar berpindah-pindah di antara dua provider mainstream — mekanismenya sama, tapi pembersihan setelahnya tidak.

Apa yang sebenarnya dimaksud dengan "zero downtime"

Istilah ini sering dipakai secara longgar, dan kelonggaran itulah yang membuat orang celaka. Menyajikan HTTP dari dua mesin sekaligus itu mudah. Yang sulit adalah menjaga state tetap konsisten selagi dua mesin sama-sama melayani traffic, dan hanya bagian inilah yang bisa kehilangan data. Jadi sebelum merencanakan apa pun, tentukan dulu jenis situs mana yang sebenarnya sedang Anda jalankan, karena jawabannya menentukan bentuk keseluruhan malam itu.

Perhatikan bahwa hanya baris pertama yang benar-benar gratis. Di semua baris lainnya, "zero downtime" berarti "freeze penulisan yang begitu singkat sampai tidak ada yang sempat membuka tiket soal itu". Dua menit read-only pukul 04:00 hampir tidak terasa; dua jam penulisan yang terpecah di dua database berarti akhir pekan penuh rekonsiliasi. Pilih freeze-nya.

Turunkan DNS TTL beberapa hari sebelum rencana pindah

Ini satu-satunya langkah yang butuh waktu tunggu, itulah sebabnya ia ditaruh pertama, dan itulah sebabnya langkah ini yang paling sering dilewatkan orang. TTL Anda — time to live — memberi tahu setiap resolver di internet berapa lama ia boleh meng-cache record Anda sebelum bertanya lagi. Jika record A Anda punya TTL 86400, resolver yang mencarinya sejam lalu akan terus memberikan IP lama selama dua puluh tiga jam berikutnya, apa pun yang Anda ubah di registrar.

Detail krusialnya adalah menurunkan TTL itu sendiri tetap tunduk pada TTL lama. Resolver baru mengetahui nilai baru yang lebih singkat itu setelah salinan cache lama kedaluwarsa. Jadi turunkan TTL ke 300 detik setidaknya satu periode penuh TTL lama sebelum cutover — dengan TTL seharian penuh, itu berarti melakukannya 24 sampai 48 jam sebelumnya. Setelah itu, seluruh dunia akan mengikuti record baru Anda dalam lima menit sejak perubahan, dan cutover berhenti menjadi momen yang menegangkan.

Naikkan lagi TTL ke angka yang wajar beberapa hari setelah proses pindah selesai. TTL 300 detik adalah tool yang bagus tapi setelan permanen yang buruk: ia melipatgandakan volume query Anda dan membuat provider DNS Anda menjadi single point of failure yang jauh lebih tajam.

Buat inventaris apa yang Anda pindahkan, bukan apa yang Anda ingat

Setiap migrasi yang gagal punya post-mortem yang sama: ada sesuatu yang tidak masuk daftar sehingga tidak ikut disalin. Web root dan database adalah dua hal yang selalu diingat semua orang; daftar di bawah ini adalah sisanya, dan lebih baik ditelusuri secara harfiah daripada mengandalkan ingatan.

• Pekerjaan terjadwal. crontab -l untuk setiap user, plus systemd timer. Hook renewal dan job malam hari sering bersembunyi di sini.
• Definisi service. Unit systemd kustom, vhost web server, pool PHP-FPM, config supervisor apa pun.
• Secret dan environment. File .env, API key, password database, salt aplikasi — dan perlu dicatat bahwa semua ini seharusnya dirotasi, bukan sekadar disalin.
• Material TLS. Sertifikat, dan yang lebih penting lagi, akun ACME serta konfigurasi renewal-nya.
• Identitas mail. Private key DKIM, record SPF dan DMARC. Ketidakcocokan di sini tidak akan gagal secara mencolok; ia hanya diam-diam mengirim mail Anda ke folder spam.
• Media yang diunggah. Sering berada di luar web root, dan sering menjadi bagian terbesar dari yang Anda miliki.
• Semua pihak eksternal yang mempercayai IP Anda. Allowlist payment gateway, tujuan webhook, firewall database, API pihak ketiga dengan pembatasan IP. Inilah penyebab nomor satu dari "situsnya jalan tapi checkout-nya rusak" pukul 03:00.
• Daftar paket. dpkg --get-selections atau yang setara, supaya mesin baru punya ekstensi dan library yang sama persis, bukan cuma hampir sama.

Tulis daftar ini sebelum Anda mulai menyalin apa pun. Inventaris ini juga menjadi rencana pengujian Anda nanti — setiap baris di dalamnya adalah sesuatu yang harus diverifikasi di server baru sebelum DNS tahu server itu ada.

Bangun server baru lebih dulu, dan harden sebelum ia menyimpan apa pun

Pesan server tujuan lebih awal dan biarkan ia menyala kosong selama sehari atau dua hari. Tidak ada biaya untuk tumpang tindih ini — VPS offshore kecil harganya cuma beberapa dolar sebulan — dan ada banyak nilai dari tidak melakukan build di bawah tekanan waktu sambil database yang sudah di-freeze menunggu.

Samakan environment lama dengan sengaja: distribusi dan major version yang sama, major version PHP, Node, atau Python yang sama, major version database yang sama. Godaan untuk sekalian memodernkan semuanya selagi Anda di sana itu besar sekali dan harus ditahan sepenuhnya. Kalau situs rusak setelah cutover, Anda ingin hanya ada satu variabel yang berubah. Upgrade stack-nya dua minggu kemudian, di sore hari yang membosankan, dengan kemampuan untuk roll back.

Harden server itu selagi masih kosong. SSH keys-only, firewall default-deny, update keamanan otomatis — checklist hardening jam pertama kami persis berisi daftar ini, dan jauh lebih mudah diterapkan pada mesin yang belum ada isinya. Jika datanya cukup sensitif sampai Anda perlu pindah yurisdiksi karenanya, ini juga saat yang tepat untuk memutuskan soal enkripsi at rest, karena menerapkannya belakangan berarti migrasi lagi.

Salin data dua kali: sekali lambat, sekali cepat

Naluri pertama adalah menyalin semuanya selama jendela maintenance. Lakukan sebaliknya. Jalankan salinan penuh beberapa hari sebelumnya selagi situs lama masih melayani traffic dengan tenang, lalu jalankan pass kedua saat cutover yang hanya memindahkan apa yang berubah. Pass pertama bisa memakan waktu enam jam dan tidak ada yang sadar. Pass kedua hanya sembilan puluh detik, dan itulah seluruh anggaran downtime Anda.

Untuk file, rsync -aHAX --numeric-ids mempertahankan permission, ownership, hard link, dan extended attribute; flag --numeric-ids penting karena UID jarang cocok antara dua mesin yang baru saja dibangun. Jalankan sekali di awal, lalu jalankan lagi tepat sebelum cutover dengan argumen yang sama — jalankan kedua ini hanya mentransfer delta-nya.

Database butuh perlakuan dua fase yang sama tapi dengan tool berbeda. mysqldump --single-transaction atau pg_dump memberi Anda snapshot awal yang konsisten untuk dibangun dan diuji. Saat cutover, entah ambil dump kedua selama write freeze singkat Anda, atau — untuk database besar di mana freeze sekejap pun terasa sakit — siapkan server baru sebagai replica dari server lama beberapa hari sebelumnya, biarkan ia mengejar ketertinggalan, lalu promosikan. Replikasi mengubah freeze menjadi hitungan detik. Tapi ia juga mengubah migrasi dua jam menjadi proyek dua hari, jadi gunakan hanya kalau ukurannya benar-benar menuntutnya.

Uji server baru sebelum DNS mengetahui keberadaannya

Anda bisa menyajikan hostname asli dari IP baru tanpa mengubah satu pun record publik, dan sebaiknya memang begitu — inilah yang membuat cutover berjalan tanpa drama. Tambahkan satu baris ke /etc/hosts lokal Anda yang mengarahkan domain ke IP baru, atau lewati itu dan biarkan curl yang melakukannya untuk satu request:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Sekarang telusuri inventaris tadi. Muat halaman depan dan tiga halaman yang lebih dalam. Login. Kirim sebuah form. Unggah sebuah file. Periksa bahwa koneksi database sudah mengarah ke yang lokal dan baru, bukan masih menunjuk ke host lama lewat internet — kesalahan yang bekerja sempurna sampai tepat pada saat Anda membatalkan server lama. Jalankan cron job secara manual dan baca outputnya. Verifikasi redirect, dan pastikan URL yang tidak ada tetap mengembalikan 404, bukan 200.

Terbitkan sertifikat TLS sekarang, sebelum cutover, bukan sesudahnya. Gunakan challenge DNS-01, yang membuktikan kendali atas domain lewat record TXT dan karena itu tetap berhasil selagi record A masih menunjuk ke server lama. Jika Anda menunggu validasi HTTP-01 setelah perubahan DNS, setiap pengunjung awal akan mendapat peringatan sertifikat selama jeda itu — outage yang Anda ciptakan sendiri, justru di jendela waktu yang sedang Anda coba lindungi.

Cutover, langkah demi langkah

Pada titik ini server baru sudah dibangun, di-harden, diisi data, diuji di bawah hostname asli, dan sudah memegang sertifikat yang valid. Cutover itu sendiri sekarang tinggal daftar singkat yang membosankan — dan memang itulah tujuannya.

1. Umumkan jendela waktunya kalau ada pihak lain yang bergantung pada situs ini, lalu masukkan situs lama ke mode read-only atau maintenance.
2. Matikan cron dan background worker di host lama. Lakukan ini sebelum menyalakannya di host baru, jangan pernah sesudahnya.
3. Jalankan pass delta rsync terakhir dan dump database terakhir, lalu impor.
4. Jalankan aplikasi di server baru dan ulangi smoke test Anda lewat --resolve, terhadap data final.
5. Ubah record A dan AAAA ke IP baru. Dengan TTL 300 detik, seluruh dunia akan mengikuti dalam lima menit.
6. Aktifkan cron dan worker di host baru.
7. Amati kedua access log berdampingan. Traffic akan mengalir keluar dari server lama dan muncul di server baru; ketika yang lama sudah sepi, cutover selesai.
8. Biarkan server lama tetap menyala, tetap melayani, dan tidak disentuh selama seminggu. Itulah rollback Anda.

Langkah delapan adalah langkah yang paling sering dipotong orang, padahal itulah asuransi termurah dalam daftar ini. Dengan harga beberapa dolar saja, Anda tetap punya kemampuan untuk mengarahkan DNS kembali — pemulihan lima menit — selama waktu yang dibutuhkan untuk benar-benar yakin.

Apa yang ditinggalkan oleh proses migrasi

Inilah bagian yang dilewatkan panduan migrasi generik, dan bagian yang paling penting kalau Anda pindah demi privasi, bukan sekadar demi harga. Memindahkan situs tidak menghapus sejarahnya. Beberapa record publik dan semi-publik dari pengaturan lama tetap bertahan secara permanen meski situsnya sudah pindah, dan mengetahui yang mana saja adalah pembeda antara benar-benar putus bersih dan sekadar merasa sudah putus bersih.

Ringkasan jujurnya adalah migrasi tidak bisa menulis ulang masa lalu — ia hanya bisa berhenti menambah catatan baru padanya. Itu tetap sangat berharga, tapi itu mengubah keputusannya: jika threat model Anda menuntut agar tidak ada pengamat yang bisa menghubungkan situs baru dengan situs lama, memindahkan domain yang sama ke host baru tidak akan mencapai itu, dan sebanyak apa pun kehati-hatian selama cutover tidak akan mengubahnya. Kasus itu butuh nama baru dan awal yang bersih, yang akan dibahas berikutnya. Jika tujuan Anda justru untuk berhenti menghasilkan record yang mengidentifikasi Anda mulai hari ini, dan memindahkan pusat gravitasi hukum ke yurisdiksi pilihan Anda, maka proses pindah ini sudah tepat mencapai itu. Panduan OpSec server kami membahas kebiasaan yang menjaganya tetap bersih setelahnya.

Soal domain: dibawa serta, atau mulai dari nol?

Situs dan domain adalah dua keputusan yang independen, dan orang sering mencampuradukkan keduanya. Anda bisa memindahkan hosting hari ini dan membiarkan registrar tidak tersentuh selamanya; tidak ada apa pun dalam perubahan server yang mengharuskan Anda menyentuh domain. Apakah Anda sebaiknya melakukannya, itu sepenuhnya tergantung pada apa yang sudah diketahui oleh domain itu tentang Anda.

• Pertahankan domain, ganti registrar. Masuk akal kalau domainnya punya nilai — link, ranking, nama yang diketik orang. Ini memperbaiki masa depan record WHOIS, bukan riwayatnya, dan menjaga semua sinyal ranking tetap utuh. Ini jawaban yang tepat untuk kebanyakan situs komersial.
• Pertahankan domain, jangan ubah apa pun selain host-nya. Sangat masuk akal kalau Anda pindah demi yurisdiksi, uptime, atau posisi DMCA, bukan demi anonimitas. Ini pindahan paling sederhana yang mungkin dilakukan, tanpa risiko SEO sama sekali.
• Domain baru, redirect dari yang lama. Mempertahankan ranking, tapi menghubungkan kedua nama itu secara publik dan permanen. Pilih ini demi kontinuitas, jangan pernah demi privasi — redirect itu sendirilah link-nya.
• Domain baru, putus bersih. Satu-satunya opsi yang benar-benar memutus keterkaitan itu, dan Anda akan kehilangan semua ranking serta inbound link yang pernah Anda punya. Daftarkan secara privat sejak awal, karena sebuah domain hanya seanonim pendaftaran pertamanya. Panduan kami tentang pendaftaran domain anonim dengan crypto membahas cara melakukannya dengan benar.

Pilih dengan sengaja, dan pilih sebelum cutover, bukan di tengah-tengahnya. Berubah pikiran soal domain setelah DNS berpindah berarti Anda harus mengulang bagian yang rawan itu dua kali.

Nonaktifkan host lama dengan benar

Seminggu atau dua minggu setelah cutover, ketika log server baru sudah membosankan dan log server lama sudah kosong, itulah saatnya menutup akun lama. Lakukan dalam urutan berikut, karena jalan pintas yang menggoda — langsung menekan cancel — justru yang meninggalkan data Anda di disk milik orang lain.

1. Pastikan tidak ada lagi yang menunjuk ke IP lama: periksa alamat hardcoded di webhook pihak ketiga, allowlist, monitoring, dan record DNS mana pun yang terlupakan, seperti subdomain nyasar mail atau cpanel.
2. Rotasi setiap secret yang pernah ada di mesin itu — password database, API key, salt aplikasi, key DKIM, SSH key. Jangan bawa itu semua ke server baru.
3. Hapus SSH public key Anda dan akses support apa pun dari server lama.
4. Hapus aplikasinya, dump-nya, dan backup-nya, lalu overwrite ruang kosongnya supaya pembacaan sekilas terhadap volume yang didaur ulang tidak menghasilkan apa-apa.
5. Baru setelah itu terminasi layanannya, dan hapus metode pembayaran apa pun yang tersimpan di akun lama.

Seluruh urutannya dalam satu halaman

Kalau semua penjelasannya dibuang, migrasi host tinggal sembilan langkah, dan hanya dua di antaranya yang benar-benar mendesak:

1. Dua hari sebelumnya: turunkan DNS TTL ke 300 detik.
2. Dua hari sebelumnya: pesan dan harden server tujuan, samakan stack lamanya versi demi versi.
3. Beberapa hari sebelumnya: tulis inventarisnya — cron, secret, TLS, key mail, media, allowlist IP, paket.
4. Beberapa hari sebelumnya: jalankan salinan data penuh yang pertama, host ke host.
5. Sebelum jendela waktunya: terbitkan sertifikat lewat DNS-01 dan uji semuanya lewat --resolve.
6. Jendela waktu (dalam menit): freeze penulisan, matikan cron lama, jalankan salinan delta dan dump final, jalankan aplikasi baru.
7. Jendela waktu (dalam detik): ubah record A, lalu aktifkan cron di host baru.
8. Minggu berikutnya: biarkan server lama tetap hidup sebagai rollback, amati kedua file log, lalu naikkan lagi TTL-nya.
9. Setelahnya: rotasi secret, wipe, cancel — dan ingat apa yang tidak bisa dihapus oleh proses pindah ini.

Tidak ada satu pun dari daftar itu yang sulit. Setiap langkah yang menyakitkan adalah langkah yang dilakukan di luar urutan — TTL yang diturunkan pada malam itu juga, sertifikat yang diterbitkan setelah perubahan DNS, cron job yang masih aktif di mesin yang sudah tidak lagi otoritatif. Kalau urutannya benar, bagian menarik dari sebuah migrasi adalah memilih di mana menaruh server, bukan proses pindahnya itu sendiri. Jika Anda belum memutuskan soal itu, panduan yurisdiksi kami adalah tempat yang tepat untuk mulai.