[Beranda](https://servhidden.com/id) / [Privasi Hosting Guides](https://servhidden.com/id/guides) / Cara Migrasi Website ke Hosting Offshore Tanpa Downtime Operasional # Migrasi ke Hosting Offshore Tanpa Downtime Hampir semua migrasi yang menyakitkan adalah kegagalan urutan, bukan kegagalan teknis — TTL yang diturunkan pada malam itu juga alih-alih dua hari sebelumnya, sertifikat yang diterbitkan setelah perubahan DNS alih-alih sebelumnya, cron job yang masih aktif di server yang sudah tidak lagi otoritatif. Inilah urutan yang menghilangkan jendela downtime sepenuhnya, plus bagian yang dilewatkan panduan generik: apa yang secara permanen dicatat oleh proses pindah ini tentang Anda, dan apa yang masih bisa Anda lakukan soal itu. [Baca panduan](#guide-body) [FAQ](#guide-faq) ## Di halaman ini - [Panduan](#guide-body) - [FAQ](#guide-faq) - [Panduan terkait](#guide-related) - [Halaman yang direkomendasikan](#guide-cta) Tanpa KYC Hanya Kripto Tanpa Log DMCA Diabaikan Root penuh NVMe SSD 19 mnt baca Diperbarui Aug 2026 Di halaman ini [01Apa yang sebenarnya dimaksud dengan "zero downtime"](#apa-yang-sebenarnya-dimaksud-dengan-zero-downtime) [02Turunkan DNS TTL beberapa hari sebelum rencana pindah](#turunkan-dns-ttl-beberapa-hari-sebelum-rencana-pindah) [03Buat inventaris apa yang Anda pindahkan, bukan apa yang Anda ingat](#buat-inventaris-apa-yang-anda-pindahkan-bukan-apa-yang-anda-) [04Bangun server baru lebih dulu, dan harden sebelum ia menyimpan apa pun](#bangun-server-baru-lebih-dulu-dan-harden-sebelum-ia-menyimpa) [05Salin data dua kali: sekali lambat, sekali cepat](#salin-data-dua-kali-sekali-lambat-sekali-cepat) [06Uji server baru sebelum DNS mengetahui keberadaannya](#uji-server-baru-sebelum-dns-mengetahui-keberadaannya) [07Cutover, langkah demi langkah](#cutover-langkah-demi-langkah) [08Apa yang ditinggalkan oleh proses migrasi](#apa-yang-ditinggalkan-oleh-proses-migrasi) [09Soal domain: dibawa serta, atau mulai dari nol?](#soal-domain-dibawa-serta-atau-mulai-dari-nol) [10Nonaktifkan host lama dengan benar](#nonaktifkan-host-lama-dengan-benar) [11Seluruh urutannya dalam satu halaman](#seluruh-urutannya-dalam-satu-halaman) [FAQPertanyaan umum](#guide-faq) [→Halaman yang direkomendasikan](#guide-cta) 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. | Apa yang Anda pindahkan | Bagian yang benar-benar bermasalah | Rencana yang seharusnya | | --- | --- | --- | | Situs statis, situs brosur, output hasil generate | Tidak ada. Tidak ada state yang perlu dipecah | Salin, verifikasi, cutover. Benar-benar zero downtime | | CMS dengan database — WordPress, Ghost, forum | Komentar, login, dan postingan yang masuk ke dua database sekaligus | Freeze read-only yang diukur dalam **menit**, pada jam paling sepi Anda | | Toko online, atau apa pun yang menerima pesanan | Split brain diam-diam menghilangkan pesanan yang sudah dibayar | Ambil jendela maintenance singkat. Ini lebih murah daripada rekonsiliasi | | Apa pun yang punya cron job atau background worker | Job yang sama berjalan di kedua server — email dobel, penagihan dobel | Matikan jadwalnya di host lama *sebelum* host baru mulai berjalan | | Mail di domain yang sama | Record MX kedaluwarsa dari cache menurut jamnya sendiri, tidak terkait dengan record A Anda | Pindahkan mail di malam terpisah, dan biarkan MX lama tetap menerima selama seminggu | 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. Kedua server berjalan bersamaan dan DNS dipindahkan paling akhir — itulah sebabnya cutover yang urutannya benar tidak punya jendela waktu sama sekali. ## 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](https://servhidden.com/id/guides/first-hour-vps-hardening-checklist) 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](https://servhidden.com/id/guides/full-disk-encryption-on-a-vps), 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. **Tarik (pull), jangan dorong (push), dan jangan pernah lewat laptop Anda.** Mulai proses penyalinan dari server baru supaya transfer berjalan host-ke-host dengan kecepatan datacenter. Merutekan gigabyte data lewat koneksi rumah Anda itu lambat, dan itu menaruh IP residensial Anda di access log kedua mesin — yang justru merupakan link yang ingin dihindari oleh migrasi bermotif privasi. Jika bahkan host lama mengetahui IP baru Anda saja sudah tidak bisa diterima, jangan menyalin secara langsung sama sekali: pulihkan server baru dari [backup terenkripsi off-site](https://servhidden.com/id/guides/vps-backup-strategy) milik Anda sendiri, sehingga kedua mesin tidak pernah saling berkomunikasi. ## 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. - Umumkan jendela waktunya kalau ada pihak lain yang bergantung pada situs ini, lalu masukkan situs lama ke mode read-only atau maintenance. - **Matikan cron dan background worker di host lama.** Lakukan ini sebelum menyalakannya di host baru, jangan pernah sesudahnya. - Jalankan pass delta rsync terakhir dan dump database terakhir, lalu impor. - Jalankan aplikasi di server baru dan ulangi smoke test Anda lewat --resolve, terhadap data final. - Ubah record A dan AAAA ke IP baru. Dengan TTL 300 detik, seluruh dunia akan mengikuti dalam lima menit. - Aktifkan cron dan worker di host baru. - Amati kedua access log berdampingan. Traffic akan mengalir keluar dari server lama dan muncul di server baru; ketika yang lama sudah sepi, cutover selesai. - 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. | Apa yang mencatat proses pindah ini | Siapa yang bisa membacanya | Apa yang sebenarnya bisa Anda lakukan | | --- | --- | --- | | Passive DNS — record A historis | Siapa saja, lewat layanan riwayat komersial | **Tidak ada.** IP lama akan terasosiasi secara permanen dengan nama domainnya. Rencanakan seolah-olah ini bersifat publik, karena memang begitu | | Log Certificate Transparency | Siapa saja, secara permanen, bisa dicari berdasarkan domain | Setiap sertifikat yang pernah diterbitkan tercatat di sana — termasuk subdomain yang terdengar internal yang sudah Anda lupakan. Lebih baik pakai wildcard daripada nama yang deskriptif | | Record akun di host lama | Host lama, dan siapa pun yang bisa memaksa mereka membuka data | Detail kartu, email pendaftaran, IP login. Tujuan no-KYC melindungi masa depan, bukan masa lalu | | Riwayat WHOIS | Arsip riwayat WHOIS komersial | Jika domain itu pernah didaftarkan dengan data asli, snapshot itu sudah terekam. Privasi yang diterapkan belakangan tidak bisa menariknya kembali | | Identifier analytics dan iklan | Vendor-nya, dan siapa pun yang membaca page source Anda | Membawa tracking ID yang sama ke situs baru menghubungkan kedua situs itu secara meyakinkan. Terbitkan yang baru, atau buang saja | | Dump dan backup yang tertinggal di disk lama | Siapa pun yang mendapat alokasi storage itu berikutnya | Hapus dan overwrite sebelum membatalkan langganan. Di storage bersama, anggap penghapusan hanya sebagai petunjuk, bukan jaminan | | Header Received: di mail yang sudah terkirim | Setiap penerima, selamanya | Tidak ada yang berlaku surut. Hanya mail yang Anda kirim setelah pindah yang membawa jalur baru | | Koneksi Anda sendiri selama proses penyalinan | ISP Anda, dan access log kedua host | Yang satu ini sepenuhnya ada di bawah kendali Anda. Jangan pernah menyentuh salah satu mesin dari IP yang mengidentifikasi Anda | 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](https://servhidden.com/id/guides/server-opsec-staying-anonymous) 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](https://servhidden.com/id/guides/anonymous-domain-registration-with-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. - 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. - 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. - Hapus SSH public key Anda dan akses support apa pun dari server lama. - Hapus aplikasinya, dump-nya, dan backup-nya, lalu overwrite ruang kosongnya supaya pembacaan sekilas terhadap volume yang didaur ulang tidak menghasilkan apa-apa. - Baru setelah itu terminasi layanannya, dan hapus metode pembayaran apa pun yang tersimpan di akun lama. **Apa pun yang pernah berada di hardware yang tidak lagi Anda kendalikan, secara definisi sudah compromised.** Bukan karena host lama Anda jahat, tapi karena disk itu akan kembali masuk ke pool, dan Anda tidak akan pernah tahu apa yang selamat dari proses wipe-nya. Merotasi password database hanya butuh dua menit. Menemukan berbulan-bulan kemudian bahwa sebuah key dari server yang sudah dinonaktifkan ternyata masih bisa membuka sesuatu, itu butuh waktu jauh lebih lama. ## Seluruh urutannya dalam satu halaman Kalau semua penjelasannya dibuang, migrasi host tinggal sembilan langkah, dan hanya dua di antaranya yang benar-benar mendesak: - **Dua hari sebelumnya:** turunkan DNS TTL ke 300 detik. - **Dua hari sebelumnya:** pesan dan harden server tujuan, samakan stack lamanya versi demi versi. - **Beberapa hari sebelumnya:** tulis inventarisnya — cron, secret, TLS, key mail, media, allowlist IP, paket. - **Beberapa hari sebelumnya:** jalankan salinan data penuh yang pertama, host ke host. - **Sebelum jendela waktunya:** terbitkan sertifikat lewat DNS-01 dan uji semuanya lewat --resolve. - **Jendela waktu (dalam menit):** freeze penulisan, matikan cron lama, jalankan salinan delta dan dump final, jalankan aplikasi baru. - **Jendela waktu (dalam detik):** ubah record A, lalu aktifkan cron di host baru. - **Minggu berikutnya:** biarkan server lama tetap hidup sebagai rollback, amati kedua file log, lalu naikkan lagi TTL-nya. - **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](https://servhidden.com/id/guides/choosing-an-offshore-jurisdiction) kami adalah tempat yang tepat untuk mulai. FAQ ## Migrasi host — pertanyaan yang sering diajukan ### 01 Sebenarnya, berapa lama downtime yang harus saya perkirakan? Untuk situs statis, sama sekali tidak ada — kedua server bisa menyajikan konten yang sama secara bersamaan, sehingga perubahan DNS tidak terasa sama sekali. Untuk apa pun yang punya database, downtime Anda persis sepanjang write freeze Anda, yang biasanya dua sampai sepuluh menit kalau Anda sudah menjalankan salinan data penuh sebelumnya. Angka yang penting bukan seberapa cepat DNS berpindah; melainkan seberapa banyak yang Anda salin selama jendela waktu itu. Salin hampir semuanya beberapa hari sebelumnya, dan jendela waktunya menyusut menjadi seukuran delta saja. ### 02 Berapa lama waktu propagasi DNS? Sebenarnya tidak ada propagasi — istilah itu menggambarkan sesuatu yang tidak benar-benar terjadi. Resolver hanya meng-cache record Anda selama TTL-nya menyatakan demikian, lalu bertanya lagi setelah masa itu habis. Jika TTL yang berlaku adalah 86400, sebagian resolver akan tetap menyajikan IP lama selama 24 jam berikutnya. Turunkan TTL ke 300 detik setidaknya satu periode penuh TTL lama sebelum cutover, dan seluruh internet akan mengikuti perubahan Anda dalam lima menit. ### 03 Apakah saya juga harus memindahkan domain saya? Tidak. Registrar dan host sepenuhnya independen, dan memindahkan situs sambil membiarkan domain persis di tempatnya bekerja dengan sempurna. Apakah Anda perlu memindahkannya juga tergantung alasan Anda bermigrasi: kalau alasannya yurisdiksi, harga, atau posisi DMCA, biarkan saja domainnya. Kalau alasannya anonimitas, perlu dicatat bahwa domain punya riwayatnya sendiri yang terpisah — arsip WHOIS menyimpan detail apa pun yang dipakai saat pendaftaran pertamanya, dan perubahan hosting tidak menyentuh itu sama sekali. ### 04 Bisakah saya bermigrasi tanpa host lama mengetahui ke mana saya pindah? Tidak, kalau Anda menyalin langsung antara kedua mesin — satu sisi terhubung ke sisi lain, dan kedua access log akan mencatatnya. Jika link ini benar-benar penting bagi threat model Anda, jangan menyalin host ke host sama sekali: pulihkan server baru dari backup terenkripsi off-site milik Anda sendiri, sehingga kedua provider tidak pernah bertukar satu paket data pun. Bagaimanapun caranya, jangan pernah memulai transfer dari koneksi yang mengidentifikasi Anda, dan jangan sebutkan tujuannya di tiket support apa pun yang Anda buka dengan provider lama. ### 05 Haruskah saya sekalian upgrade OS atau stack-nya? Tidak, dan ini adalah kegagalan migrasi akibat ulah sendiri yang paling umum terjadi. Ubah satu hal saja dulu. Kalau situs berperilaku aneh setelah cutover, Anda ingin hanya ada satu kandidat penjelasan, bukan harus memilih di antara mesin baru, versi PHP baru, dan major version database baru. Samakan environment lama versi demi versi, selesaikan proses pindahnya, pastikan seminggu log yang bersih, baru kemudian upgrade secara terpisah dengan kemampuan untuk roll back. ### 06 Apakah bermigrasi akan merusak ranking pencarian saya? Tidak secara berarti, selama domain, URL, dan kontennya tetap sama — Google mengindeks URL, bukan alamat IP, dan perubahan host dengan sendirinya bukan sinyal ranking. Pertahankan struktur URL tetap identik, kembalikan status code yang sama, dan jangan menggabungkan proses pindah ini dengan redesign atau perubahan skema URL. Jika Anda malah pindah ke domain baru, perkirakan akan ada penurunan sementara meski redirect 301-nya sudah benar, dan pahami bahwa redirect itu juga menghubungkan kedua nama itu secara publik. ### 07 Apakah saya perlu menerbitkan ulang sertifikat TLS? Ya — server baru butuh sertifikat dan private key-nya sendiri, dan membawa key lama ke server baru adalah kebiasaan buruk meski secara teknis itu tetap berfungsi. Terbitkan sertifikatnya sebelum cutover menggunakan challenge DNS-01, yang tervalidasi lewat record TXT dan karena itu tetap berhasil selagi record A masih menunjuk ke host lama. Menunggu HTTP-01 setelah perubahan DNS dijamin akan menghasilkan periode peringatan sertifikat, justru di jendela waktu yang sedang Anda coba lindungi. ### 08 Kapan waktu yang aman untuk membatalkan server lama? Setelah seminggu atau dua minggu log yang sepi di mesin lama dan log yang bersih di mesin baru — jeda waktu ini adalah rollback Anda, dan harganya cuma beberapa dolar. Sebelum membatalkan, periksa apakah masih ada pihak eksternal yang menunjuk ke IP lama, rotasi setiap secret yang pernah ada di sana, lalu hapus data Anda dan overwrite ruang kosongnya. Batalkan langganannya paling akhir. Menekan terminate lebih dulu akan meninggalkan database Anda di disk yang sudah tidak lagi Anda kendalikan. Panduan terkait ## Terus membaca [### Cara Memilih Yurisdiksi Hosting Offshore pada 2026 Pembelian Kerangka keputusan praktis untuk memilih yurisdiksi offshore: undang-undang retensi data, paparan MLAT, posisi DMCA, kecepatan pengadilan, dan penegakan di dunia nyata — negara demi negara. FAQ 6-pertanyaan](https://servhidden.com/id/guides/choosing-an-offshore-jurisdiction) [### VPS vs Server Dedicated for Privasi-Critical Workloads Pembelian Kapan VPS sudah cukup, kapan shared tenancy menjadi liabilitas, dan kapan bare metal adalah satu-satunya jawaban yang jujur. Isolasi hardware, risiko hypervisor, serta biaya dibanding model ancaman. FAQ 6-pertanyaan](https://servhidden.com/id/guides/vps-vs-dedicated-for-privacy) [### VPN Self-Hosted di VPS Tanpa-KYC: WireGuard vs OpenVPN Operasional Mengapa VPN self-hosted mengalahkan provider komersial, dan bagaimana WireGuard serta OpenVPN benar-benar dibandingkan dari sisi privasi, performa, dan risiko operasional pada 2026. FAQ 6-pertanyaan](https://servhidden.com/id/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 untuk Inferensi AI (dan Di Mana RTX 5090 Cocok) Pembelian Buying-decision guide: NVIDIA GPU mana untuk self-hosted LLM, image, video, voice, dan finetuning workloads pada 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token, dan kapan masing-masing menang. FAQ 6-pertanyaan](https://servhidden.com/id/guides/rtx-4090-vs-h100-for-ai-inference) [### Windows RDP Offshore untuk Trading Forex MT4 / MT5 / cTrader Operasional Panduan lengkap: mengapa Windows RDP untuk trading forex, cara memilih yurisdiksi offshore berlatensi rendah, pengaturan MT4 / MT5 / cTrader / Expert Advisor, latensi ke server broker, dan jalur checkout no-KYC. FAQ 6-pertanyaan](https://servhidden.com/id/guides/offshore-windows-rdp-for-forex-trading) [### Hosting DMCA-Ignored Dijelaskan: Apa Artinya Sebenarnya di 2026 Pembelian Apa yang benar-benar didapat dari hosting "DMCA ignored", yurisdiksi mana yang sungguh-sungguh mendukungnya, beban kerja yang membutuhkannya, dan jebakan hak cipta yang tidak dicakup oleh istilah tersebut. FAQ 6-pertanyaan](https://servhidden.com/id/guides/dmca-ignored-hosting-explained) [### Registrasi Domain Anonim dengan Kripto: Privasi WHOIS di 2026 Privasi Panduan praktis 2026 untuk mendaftarkan domain tanpa mengungkap identitas Anda: rezim WHOIS per TLD, pilihan registrar, opsi pembayaran kripto, dan kesalahan operasional yang tetap membocorkan Anda. FAQ 6-pertanyaan](https://servhidden.com/id/guides/anonymous-domain-registration-with-crypto) [### Kripto Payments for Hosting: Monero vs Bitcoin vs USDT Privasi Bagaimana coin pembayaran memengaruhi apa yang diketahui host tentang Anda. Privasi, biaya, finalitas, dan eksposur chain analysis untuk XMR, BTC, dan USDT, dengan rekomendasi jelas. FAQ 6-pertanyaan](https://servhidden.com/id/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### Apakah Hosting Offshore Benar-Benar Anonim? Jawaban yang Jujur Privasi Hosting offshore tanpa KYC menghilangkan identitas yang biasanya dikumpulkan oleh hosting normal — tetapi status "anonim" bergantung pada metode pembayaran, logging provider, dan opsec Anda sendiri. Berikut ini yang sebenarnya masih bisa dilacak. FAQ 6-pertanyaan](https://servhidden.com/id/guides/is-offshore-hosting-truly-anonymous) [### Jam Pertama Hardening VPS: Sebuah Checklist Operasional Checklist konkret dan berurutan untuk mengamankan VPS baru dalam waktu kurang dari satu jam: kunci SSH, firewall, fail2ban, update otomatis, dan pengurangan attack surface yang menghentikan sebagian besar serangan oportunistik. FAQ 6-pertanyaan](https://servhidden.com/id/guides/first-hour-vps-hardening-checklist) [### Apa Itu Hosting Tanpa KYC? Definisi, Legalitas & Cara Kerjanya Privasi Hosting tanpa KYC memungkinkan Anda menyewa server tanpa verifikasi identitas apa pun — tanpa nama, email, maupun ID. Berikut penjelasan lengkapnya: apa artinya, cara kerjanya secara teknis, apakah legal, dan cara memilih penyedia yang benar-benar tanpa KYC. FAQ 6-pertanyaan](https://servhidden.com/id/guides/what-is-no-kyc-hosting) [### Apakah Hosting Offshore Legal? Jawaban Jujur untuk 2026 Pembelian Hosting offshore itu legal — baik untuk Anda maupun untuk penyedia layanan. Berikut penjelasan sesungguhnya tentang istilah ini, di mana garis hukum yang sebenarnya, mitos yang perlu dibuang, dan cara menggunakannya secara bertanggung jawab. FAQ 6-pertanyaan](https://servhidden.com/id/guides/is-offshore-hosting-legal) [### Cara Membayar Hosting dengan Monero (XMR) — Panduan Langkah demi Langkah Privasi Panduan langkah demi langkah untuk membayar VPS atau server dedicated dengan Monero (XMR): mengapa XMR adalah pilihan paling privat, cara memperolehnya, dan cara kerja proses checkout — dari invoice hingga server yang berjalan dalam hitungan menit. FAQ 6-pertanyaan](https://servhidden.com/id/guides/how-to-pay-for-hosting-with-monero) [### Cara Meng-host Website Secara Anonim — Panduan Praktis 2026 Privasi Panduan berlapis yang praktis untuk meng-host website tanpa identitas yang terlampir: akun, pembayaran, domain, yurisdiksi, koneksi, dan konten — setiap lapisan dijelaskan secara rinci. FAQ 6-pertanyaan](https://servhidden.com/id/guides/how-to-host-a-website-anonymously) [### Cara Menyiapkan WireGuard VPN di VPS — Panduan Langkah demi Langkah Operasional Bangun VPN pribadi di VPS menggunakan WireGuard: mengapa VPN yang di-host sendiri lebih unggul dari layanan komersial, panduan lengkap mulai dari instalasi hingga klien terhubung, dan cara memperkuat keamanannya. FAQ 6-pertanyaan](https://servhidden.com/id/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### Cara Self-Host LLM di Server GPU — Panduan 2026 Operasional Jalankan model bahasa besar milik Anda sendiri di server GPU sewaan: mengapa self-hosting lebih unggul dari API, cara memilih GPU dan model yang tepat, cara setup dengan Ollama atau vLLM, dan berapa biayanya. FAQ 6-pertanyaan](https://servhidden.com/id/guides/self-host-an-llm-on-a-gpu-server) [### Bulletproof Hosting vs Offshore Hosting — Apa Perbedaannya? Pembelian Bulletproof hosting dan offshore hosting kerap tertukar — padahal keduanya tidak sama. Berikut perbedaan sesungguhnya, mengapa hal ini penting, dan mana yang sebenarnya Anda butuhkan. FAQ 6-pertanyaan](https://servhidden.com/id/guides/bulletproof-vs-offshore-hosting) [### Cara Membeli VPS dengan Bitcoin — Panduan Lengkah demi Langkah (2026) Pembelian Panduan ramah pemula untuk membeli VPS dengan Bitcoin: mendapatkan BTC, memilih paket, membayar invoice, dan apa yang Anda peroleh — server yang berjalan tanpa kartu dan tanpa nama terlampir. FAQ 6-pertanyaan](https://servhidden.com/id/guides/how-to-buy-a-vps-with-bitcoin) [### Negara Terbaik untuk Hosting yang Mengabaikan DMCA di 2026 Pembelian Tempat menghosting konten agar jauh dari jangkauan proses penghapusan ala AS: yurisdiksi yang benar-benar efektif, apa arti sebenarnya hosting yang mengabaikan DMCA, dan cara memilihnya. FAQ 6-pertanyaan](https://servhidden.com/id/guides/best-countries-for-dmca-ignored-hosting) [### Cara Meng-host Tor Hidden Service (Situs .onion) — Panduan 2026 Operasional Siapkan onion service Tor di VPS: apa itu hidden service, mengapa ini adalah bentuk hosting anonim yang paling kuat, panduan setup lengkap, dan cara menjaganya tetap benar-benar anonim. FAQ 6-pertanyaan](https://servhidden.com/id/guides/how-to-host-a-tor-hidden-service) [### Panduan Setup Mail Server Offshore — Self-Host Email Privat di 2026 Operasional Jalankan server email privat Anda sendiri di VPS offshore: mengapa self-host email, apa yang dibutuhkan, setup realistis dengan stack mail all-in-one, dan cara memastikan deliverability yang tepat. FAQ 6-pertanyaan](https://servhidden.com/id/guides/offshore-mail-server-setup) [### Panduan Hosting Node Kripto — Jalankan Node Blockchain di VPS Operasional Cara meng-host node blockchain di server: mengapa menjalankan node sendiri, menentukan spesifikasi server untuk Bitcoin, Ethereum, Monero dan lainnya, proses setup, dan cara menjaga privasi. FAQ 6-pertanyaan](https://servhidden.com/id/guides/crypto-node-hosting-guide) [### Hosting GPU untuk Stable Diffusion — Jalankan Server Gambar Sendiri Operasional Jalankan Stable Diffusion di server GPU Anda sendiri: alasan self-hosting pembuatan gambar, cara memilih GPU, pengaturan dengan web UI, serta perbandingan biaya versus layanan hosted. FAQ 6-pertanyaan](https://servhidden.com/id/guides/gpu-hosting-for-stable-diffusion) [### OpSec Server — Tetap Anonim Saat Menjalankan Server Privasi Keamanan operasional bagi siapa saja yang menjalankan server anonim: kesalahan-kesalahan yang membongkar identitas, kebiasaan yang mencegahnya, dan cara menjaga identitas tetap benar-benar terpisah. FAQ 6-pertanyaan](https://servhidden.com/id/guides/server-opsec-staying-anonymous) [### Panduan Penyiapan Seedbox — Bangun Seedbox Privat Anda Sendiri di 2026 Operasional Cara membangun seedbox Anda sendiri di server: apa itu seedbox, cara menentukannya, menginstal klien torrent dengan web UI, dan menjaganya tetap privat dan aman. FAQ 6-pertanyaan](https://servhidden.com/id/guides/seedbox-setup-guide) [### Cara Melewati Sensor DPI dengan VPS Anda Sendiri (Panduan 2026) Privasi VPN Anda berhenti berfungsi? Cara melewati sensor DPI dengan VPS Anda sendiri: apa yang sebenarnya dideteksi oleh deep packet inspection, dari lima protokol 2026 mana yang mengalahkan pemblokiran mana, dan panduan lengkap VLESS+REALITY. FAQ 6-pertanyaan](https://servhidden.com/id/guides/bypass-dpi-censorship-with-your-own-vps) [### Enkripsi Disk Penuh di VPS: Setup LUKS dan Perlindungan Sebenarnya Operasional Cara mengenkripsi VPS dengan LUKS: volume data terenkripsi, full-root dengan remote unlock lewat SSH, pengaturan penting di server kecil, dan penjelasan jujur soal apa yang dicegah enkripsi disk. FAQ 8-pertanyaan](https://servhidden.com/id/guides/full-disk-encryption-on-a-vps) [### Menyembunyikan IP Origin Server: CDN, Reverse Proxy, dan Kebocorannya Privasi Apakah perlu memasang CDN di depan server offshore: apa yang disembunyikannya, meja aduan yang Anda warisi, enam cara IP origin tetap bocor, dan cara mengauditnya sendiri. FAQ 8-pertanyaan](https://servhidden.com/id/guides/hiding-your-origin-server-ip) [### Strategi Backup VPS: Terenkripsi, Off-Site, dan Bisa Dipulihkan Operasional Host Anda tidak menyimpan backup. Apa yang benar-benar merusak server, kenapa backup push ikut mati, restic vs Borg, kunci yang sering dilupakan, dan cara menguji restore. FAQ 8-pertanyaan](https://servhidden.com/id/guides/vps-backup-strategy) [### Self-Hosting Server Matrix Sendiri: Synapse, Federation, E2EE Operasional Yang sungguh Anda dapatkan dari homeserver Matrix: Synapse vs Conduit, server_name yang tak bisa diubah, media pemenuh disk, dan yang tetap terlihat oleh federation. FAQ 8-pertanyaan](https://servhidden.com/id/guides/self-host-a-matrix-server) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Operasional Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. FAQ 8-pertanyaan](https://servhidden.com/id/guides/self-host-a-crypto-payment-gateway) ## Beri tempat mendarat untuk migrasinya Server KVM offshore di tujuh yurisdiksi mulai $7.50/bulan, dengan akses root penuh, storage NVMe, dan bandwidth unmetered, aktif dalam waktu kurang dari lima menit begitu pembayaran crypto terkonfirmasi. Nyalakan server tujuannya lebih awal, salin data sesuai ritme Anda sendiri, dan cutover begitu semuanya siap. [Lihat Paket VPS](https://servhidden.com/id/vps) [Hosting Offshore](https://servhidden.com/id/offshore-hosting) [All Lokasi](https://servhidden.com/id/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "VPS offshore dan server dedicated di 7 yurisdiksi offshore. Tanpa KYC, tanpa log, hanya kripto. Privasi sejak arsitektur.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Cara Migrasi Website ke Hosting Offshore Tanpa Downtime", "description": "Urutan yang membuat migrasi hosting jadi membosankan: turunkan DNS TTL beberapa hari sebelumnya, jalankan kedua server secara paralel, bekukan penulisan data hanya beberapa menit, bukan berjam-jam — lalu bersihkan jejak passive-DNS, Certificate Transparency, dan WHOIS yang ditinggalkan proses pindah ini.", "image": "https://servhidden.com/assets/img/guides/migrate-website-to-offshore-hosting.webp?v=1787969426", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-29T00:00:00+00:00", "dateModified": "2026-08-29T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/migrate-website-to-offshore-hosting", "inLanguage": "id", "keywords": "migrasi website ke hosting offshore, pindah hosting tanpa downtime, cara migrasi VPS ke server baru, migrasi zero downtime, DNS TTL cutover, migrasi ke host no-KYC, checklist migrasi website, rsync migrasi server", "articleSection": "Operasional", "wordCount": 3647 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Sebenarnya, berapa lama downtime yang harus saya perkirakan?", "acceptedAnswer": { "@type": "Answer", "text": "Untuk situs statis, sama sekali tidak ada — kedua server bisa menyajikan konten yang sama secara bersamaan, sehingga perubahan DNS tidak terasa sama sekali. Untuk apa pun yang punya database, downtime Anda persis sepanjang write freeze Anda, yang biasanya dua sampai sepuluh menit kalau Anda sudah menjalankan salinan data penuh sebelumnya. Angka yang penting bukan seberapa cepat DNS berpindah; melainkan seberapa banyak yang Anda salin selama jendela waktu itu. Salin hampir semuanya beberapa hari sebelumnya, dan jendela waktunya menyusut menjadi seukuran delta saja." } }, { "@type": "Question", "name": "Berapa lama waktu propagasi DNS?", "acceptedAnswer": { "@type": "Answer", "text": "Sebenarnya tidak ada propagasi — istilah itu menggambarkan sesuatu yang tidak benar-benar terjadi. Resolver hanya meng-cache record Anda selama TTL-nya menyatakan demikian, lalu bertanya lagi setelah masa itu habis. Jika TTL yang berlaku adalah 86400, sebagian resolver akan tetap menyajikan IP lama selama 24 jam berikutnya. Turunkan TTL ke 300 detik setidaknya satu periode penuh TTL lama sebelum cutover, dan seluruh internet akan mengikuti perubahan Anda dalam lima menit." } }, { "@type": "Question", "name": "Apakah saya juga harus memindahkan domain saya?", "acceptedAnswer": { "@type": "Answer", "text": "Tidak. Registrar dan host sepenuhnya independen, dan memindahkan situs sambil membiarkan domain persis di tempatnya bekerja dengan sempurna. Apakah Anda perlu memindahkannya juga tergantung alasan Anda bermigrasi: kalau alasannya yurisdiksi, harga, atau posisi DMCA, biarkan saja domainnya. Kalau alasannya anonimitas, perlu dicatat bahwa domain punya riwayatnya sendiri yang terpisah — arsip WHOIS menyimpan detail apa pun yang dipakai saat pendaftaran pertamanya, dan perubahan hosting tidak menyentuh itu sama sekali." } }, { "@type": "Question", "name": "Bisakah saya bermigrasi tanpa host lama mengetahui ke mana saya pindah?", "acceptedAnswer": { "@type": "Answer", "text": "Tidak, kalau Anda menyalin langsung antara kedua mesin — satu sisi terhubung ke sisi lain, dan kedua access log akan mencatatnya. Jika link ini benar-benar penting bagi threat model Anda, jangan menyalin host ke host sama sekali: pulihkan server baru dari backup terenkripsi off-site milik Anda sendiri, sehingga kedua provider tidak pernah bertukar satu paket data pun. Bagaimanapun caranya, jangan pernah memulai transfer dari koneksi yang mengidentifikasi Anda, dan jangan sebutkan tujuannya di tiket support apa pun yang Anda buka dengan provider lama." } }, { "@type": "Question", "name": "Haruskah saya sekalian upgrade OS atau stack-nya?", "acceptedAnswer": { "@type": "Answer", "text": "Tidak, dan ini adalah kegagalan migrasi akibat ulah sendiri yang paling umum terjadi. Ubah satu hal saja dulu. Kalau situs berperilaku aneh setelah cutover, Anda ingin hanya ada satu kandidat penjelasan, bukan harus memilih di antara mesin baru, versi PHP baru, dan major version database baru. Samakan environment lama versi demi versi, selesaikan proses pindahnya, pastikan seminggu log yang bersih, baru kemudian upgrade secara terpisah dengan kemampuan untuk roll back." } }, { "@type": "Question", "name": "Apakah bermigrasi akan merusak ranking pencarian saya?", "acceptedAnswer": { "@type": "Answer", "text": "Tidak secara berarti, selama domain, URL, dan kontennya tetap sama — Google mengindeks URL, bukan alamat IP, dan perubahan host dengan sendirinya bukan sinyal ranking. Pertahankan struktur URL tetap identik, kembalikan status code yang sama, dan jangan menggabungkan proses pindah ini dengan redesign atau perubahan skema URL. Jika Anda malah pindah ke domain baru, perkirakan akan ada penurunan sementara meski redirect 301-nya sudah benar, dan pahami bahwa redirect itu juga menghubungkan kedua nama itu secara publik." } }, { "@type": "Question", "name": "Apakah saya perlu menerbitkan ulang sertifikat TLS?", "acceptedAnswer": { "@type": "Answer", "text": "Ya — server baru butuh sertifikat dan private key-nya sendiri, dan membawa key lama ke server baru adalah kebiasaan buruk meski secara teknis itu tetap berfungsi. Terbitkan sertifikatnya sebelum cutover menggunakan challenge DNS-01, yang tervalidasi lewat record TXT dan karena itu tetap berhasil selagi record A masih menunjuk ke host lama. Menunggu HTTP-01 setelah perubahan DNS dijamin akan menghasilkan periode peringatan sertifikat, justru di jendela waktu yang sedang Anda coba lindungi." } }, { "@type": "Question", "name": "Kapan waktu yang aman untuk membatalkan server lama?", "acceptedAnswer": { "@type": "Answer", "text": "Setelah seminggu atau dua minggu log yang sepi di mesin lama dan log yang bersih di mesin baru — jeda waktu ini adalah rollback Anda, dan harganya cuma beberapa dolar. Sebelum membatalkan, periksa apakah masih ada pihak eksternal yang menunjuk ke IP lama, rotasi setiap secret yang pernah ada di sana, lalu hapus data Anda dan overwrite ruang kosongnya. Batalkan langganannya paling akhir. Menekan terminate lebih dulu akan meninggalkan database Anda di disk yang sudah tidak lagi Anda kendalikan." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Beranda", "item": "https://servhidden.com/id/" }, { "@type": "ListItem", "position": 2, "name": "Privasi Hosting Guides", "item": "https://servhidden.com/id/guides" }, { "@type": "ListItem", "position": 3, "name": "Cara Migrasi Website ke Hosting Offshore Tanpa Downtime", "item": "https://servhidden.com/id/guides/migrate-website-to-offshore-hosting" } ] } ```