Cara Migrasi VPS ke Host Baru Tanpa Downtime

Kebanyakan migrasi tidak gagal saat proses penyalinan. Migrasi gagal pada dua puluh menit setelah perubahan DNS, ketika separuh internet masih berbicara dengan server lama dan separuh lainnya sudah berpindah — dan kedua mesin sama-sama menerima penulisan. File-nya tiba dengan utuh, situsnya termuat, dan tetap saja order-order mendarat di dua database yang tidak akan pernah bisa direkonsiliasi. Menghindari itu nyaris tidak ada hubungannya dengan kecepatan transfer dan nyaris seluruhnya soal urutan: apa yang Anda ubah lebih dulu, apa yang Anda freeze, dan apa yang tetap Anda jalankan sampai Anda yakin.

Apa arti tanpa downtime yang sebenarnya

Penting untuk presisi di sini, karena frasa ini mencakup dua janji yang sangat berbeda dan menuntut usaha yang sangat berbeda pula. Menentukan yang mana yang sebenarnya Anda beli adalah keputusan nyata pertama dari migrasi ini.

Kalau Anda harus mengorbankan salah satunya, korbankan availability. Halaman maintenance selama empat menit adalah sesuatu yang bisa Anda jelaskan. Data yang divergen adalah sesuatu yang tidak bisa Anda perbaiki, karena tidak ada lagi otoritas yang bisa mengatakan salinan mana yang benar.

Ambil inventarisasinya sebelum Anda mengambil salinannya

Sebuah server mengumpulkan hal-hal yang tidak pernah didokumentasikan siapa pun: cron job yang ditambahkan saat sebuah insiden, aturan firewall untuk alamat seorang partner, API key yang ditempel ke sebuah service file. Salinannya tidak akan membawa semua itu, dan Anda akan menemukannya satu per satu selama dua minggu berikutnya. Setengah jam inventarisasi sekarang menghilangkan hampir semuanya.

Tuliskan ke dalam sebuah file yang Anda simpan di version control, bukan ke terminal scrollback. Anda akan membacanya tiga kali selama cutover, salah satunya persis pada momen ketika pikiran Anda sedang tidak jernih.

Pilih tujuan berdasarkan hal-hal yang tidak bisa Anda ubah nanti

Spesifikasi bisa disesuaikan; beberapa properti tidak bisa, dan itulah yang layak diputuskan secara sadar selagi Anda masih punya pilihan bebas. Karena Anda toh sudah akan pindah, inilah momen paling murah yang akan pernah Anda dapatkan untuk memperbaiki batasan yang selama ini Anda akali.

• Lokasi, karena latensi ke pengguna Anda dan hukum yang berlaku sama-sama ditentukan olehnya. /locations mencantumkan daftar region beserta karakteristik round-trip-nya masing-masing; pilih satu yang gagalnya independen dari server yang sedang Anda tinggalkan.
• Landasan hukum, kalau alasan Anda pindah adalah karena provider Anda saat ini meneruskan komplain lebih cepat daripada meneruskan paket data. /offshore-hosting menjabarkan apa yang sungguh-sungguh dikendalikan oleh yurisdiksi dan apa yang tidak.
• Identitas penagihan, karena host yang mewajibkan dokumen sebelum menerima pembayaran, dengan sendirinya, sudah punya berkas tentang Anda. /no-kyc-vps dan /pay-with menjabarkan alternatifnya — saldo yang diisi ulang dengan crypto, tanpa kartu, tanpa nama yang melekat pada mesinnya.
• Ruang gerak, karena bermigrasi dua kali adalah hasil yang tidak pernah direncanakan siapa pun. /vps mencantumkan daftar tier-nya, dan /guides punya metode penentuan ukurannya kalau mesin yang sekarang belum pernah benar-benar diukur.
• IPv6 dan IPv4 yang bersih, karena alamat daur ulang bisa datang sambil membawa reputasi milik orang lain — periksa dulu sebelum itu menjadi masalah mail.

Turunkan dulu TTL DNS-nya, beberapa hari sebelumnya

Ini satu-satunya langkah persiapan yang tidak bisa diburu-buru di akhir, karena efeknya dibatasi oleh jam yang tidak Anda kendalikan. TTL pada record Anda memberi tahu resolver berapa lama harus meng-cache sebuah jawaban. Kalau diatur ke satu hari, resolver yang bertanya satu jam lalu akan tetap mengirim pengguna ke server lama untuk dua puluh tiga jam berikutnya, apa pun yang Anda publikasikan.

1. 1

   Baca TTL yang sekarang

   dig +noall +answer yourdomain.com menampilkan sisa waktu cache-nya; melakukan query langsung ke authoritative nameserver Anda dengan dig @ns1.example.net yourdomain.com menampilkan nilai yang dikonfigurasi. Catat angkanya — itulah yang menentukan panjang masa tunggu Anda.

2. 2

   Turunkan ke 300 detik

   Turunkan TTL pada setiap record yang akan berubah: A, AAAA, dan MX atau CNAME mana pun yang mengarah ke host tersebut. Lima menit cukup singkat untuk membuat cutover-nya nyaman dan cukup panjang untuk tidak membebani nameserver Anda.

3. 3

   Tunggu sampai TTL lama habis, lalu tunggu lagi

   TTL pendek yang baru baru akan menjangkau sebuah resolver setelah TTL lama yang panjang itu habis masa berlakunya. Tunggu setidaknya satu periode penuh TTL lama — satu hari kalau memang satu hari — sebelum menganggap TTL rendah itu sudah berlaku nyata. Memulai ini lebih awal tidak berbiaya apa-apa dan memberi seluruh cutover-nya ruang aman.

Bangun server barunya, jangan clone yang lama

Insting pertama biasanya adalah meng-image disk yang sekarang dan me-restore-nya di tempat lain. Ini langkah yang salah, dengan alasan yang sama seperti kenapa itu salah dalam sebuah restore: clone tingkat block akan dengan setia mereproduksi config drift-nya, package yang orphan, service yang setengah terkonfigurasi yang ditinggalkan begitu saja oleh seseorang, dan persistence apa pun yang ditinggalkan penyusup sebelumnya. Ini juga mengunci Anda ke rilis distribusi yang lama.

Bangun mesin barunya dari base image yang terkini, instal service-nya dari sebuah skrip, dan salin hanya datanya saja. Skrip itulah deliverable yang sesungguhnya — itulah yang mengubah migrasi berikutnya menjadi urusan satu sore, bukan dua minggu, dan yang memungkinkan Anda membangun ulang setelah sebuah insiden tanpa harus menggali arkeologi.

• Lakukan provisioning, update, dan harden dulu sebelum apa pun lain menyentuhnya: SSH khusus key, firewall default-deny, update keamanan otomatis. /guides punya versi checklist itu yang berdurasi satu jam.
• Instal versi mayor yang sama untuk runtime dan database seperti di production. Migrasi adalah momen yang buruk untuk sekalian meng-upgrade PostgreSQL 14 ke 17 — buat satu perubahan dalam satu waktu supaya setiap kegagalan punya tepat satu penjelasan.
• Buat ulang user dan group dengan numeric ID yang sama sebelum menyalin file, atau perbaiki ownership secara manual sesudahnya. Transfer dengan --numeric-ids menjaga angkanya tetap utuh; memetakannya kembali ke nama yang benar adalah tugas Anda.
• Masukkan alamat baru ke setiap allowlist yang saat ini masih menyebut alamat lama — API partner, firewall database managed, gateway pembayaran, monitoring Anda sendiri — selagi keduanya masih valid.

Salin file-nya dalam dua tahap

Satu kali transfer dari filesystem yang live hanyalah snapshot dari target yang terus bergerak. Dua tahap menyelesaikan ini dengan bersih: tahap pertama panjang dan berjalan terhadap sistem yang live, tahap kedua singkat dan berjalan selama freeze, dan hanya tahap kedua yang harus cepat.

Jalankan tahap pertama kapan pun Anda mau — beberapa hari lebih awal pun tidak masalah. Tahap ini membawa sebagian besar isinya: direktori upload, mail spool, container volume, bertahun-tahun media yang menumpuk. Isinya akan sudah usang pada saat Anda cutover, dan itulah persis tujuan tahap kedua.

• Gunakan rsync -aAXH --numeric-ids --info=progress2 lewat SSH: -a untuk atribut biasa, -A untuk ACL, -X untuk extended attribute, -H untuk hard link, yang penting kalau ada apa pun di mesin itu yang melakukan deduplikasi.
• Kecualikan apa yang tidak seharusnya ikut berpindah: /proc, /sys, /dev, /run, direktori temporary, package cache, dan log yang tidak Anda butuhkan. Menyalin kernel interface paling ringan hanya membuang waktu, paling parah membuat transfernya hang.
• Tambahkan --delete hanya pada tahap kedua. Pada tahap pertama flag ini tidak berbahaya; pada tahap kedua flag ini menghapus file yang sudah dihapus di source sejak itu, yang persis merupakan drift yang sedang Anda coba hilangkan.
• Salin konfigurasi sistemnya secara selektif, bukan borongan. Yang Anda inginkan adalah vhost web server Anda, service unit Anda, dan config aplikasi Anda — bukan filesystem table, konfigurasi jaringan, atau machine ID milik mesin lama.
• Generate sebuah SSH key sekali pakai untuk proses transfer, otorisasi di tujuan, dan hapus begitu migrasinya selesai. Migration key yang masih nongkrong dua tahun kemudian adalah kredensial yang tidak diingat lagi oleh siapa pun kapan diterbitkannya.

Di antara kedua tahap, verifikasi, jangan cuma berasumsi. Menjalankan tahap kedua dengan --dry-run mencetak persis apa yang akan diubahnya: daftar beberapa ratus file terbaru itu sehat, dan daftar empat puluh ribu file berarti ada exclude yang salah atau ada sesuatu yang menulis ulang timestamp tanpa alasan jelas.

Pindahkan database-nya tanpa kehilangan penulisan

Di sinilah freeze budget-nya terpakai, dan teknik yang tepat sepenuhnya ditentukan oleh angka yang Anda tuliskan di awal tadi. Ketiga opsi di bawah ini sama-sama benar — untuk angka yang berbeda-beda.

Dump schema dan data secara terpisah kalau dataset-nya besar. Me-restore schema-nya lebih dulu memungkinkan Anda memverifikasi struktur, index, dan permission di host baru sejak awal, yang mengubah proses pemuatan datanya menjadi satu operasi panjang yang bisa Anda mulai selama freeze dengan keyakinan sudah lebih dulu bahwa hasilnya akan mendarat dengan baik.

Terbitkan sertifikat TLS-nya sebelum switch, bukan sesudahnya

Sertifikat di server baru harus sudah valid pada saat pengguna pertama tiba. Kalau ternyata belum, setiap pengunjung akan disambut peringatan browser, dan kalau Anda mengirim header HSTS — yang seharusnya memang Anda lakukan — mereka bahkan tidak bisa mengklik untuk melewatinya. Ada dua cara untuk sudah memegang sertifikat yang berfungsi sebelum DNS mengarah ke mana pun yang baru.

• Salin yang sudah ada. Seluruh direktori state ACME, atau cukup sertifikat dan key-nya saja dari mana pun client Anda menyimpannya. Ini langsung valid, karena validitasnya tidak ada hubungannya dengan server mana yang memegang file-nya, dan renewal berlanjut normal begitu DNS sudah berpindah.
• Terbitkan yang baru dengan challenge DNS-01, yang membuktikan kepemilikan domain lewat sebuah TXT record, bukan lewat HTTP request ke alamat yang sekarang. Ini berfungsi sebelum migrasi, sebelum cutover, dan untuk wildcard, yang sama sekali tidak bisa dilakukan oleh HTTP-01.
• Jangan mencoba validasi HTTP-01 di server baru sebelum switch. Challenge-nya diambil lewat port 80 di nama domain itu, domainnya masih resolve ke mesin lama, dan validasinya akan gagal setiap saat.

Verifikasi tanpa menyentuh DNS dengan me-resolve hostname-nya ke alamat baru untuk satu perintah saja: curl -sI --resolve yourdomain.com:443:198.51.100.10 https://yourdomain.com/ — ganti dengan alamat sungguhannya. Satu baris itu adalah pengecekan bernilai paling tinggi di seluruh migrasi ini. Ini menguji vhost yang sungguhan, sertifikat yang sungguhan, dan application stack yang sungguhan di mesin baru, dan begitulah caranya Anda menemukan misconfiguration selagi menemukannya masih tidak berbiaya apa-apa.

Kalau server-nya mengirim mail, mulailah lebih awal

Mail adalah bagian dari migrasi yang gagalnya baru terasa berhari-hari kemudian, diam-diam, dan disalahkan ke hal lain. Alamat baru belum punya reputasi pengiriman dan bisa jadi malah mewarisi reputasi milik orang lain, dan setiap authentication record yang Anda publikasikan terikat ke alamat yang sedang Anda tinggalkan.

• Periksa alamat barunya terhadap blocklist-blocklist utama sebelum Anda benar-benar berkomitmen memakainya. IP daur ulang yang punya riwayat layak ditukar selagi menukarnya masih gratis.
• Atur reverse DNS record di alamat baru ke hostname mail Anda. Server penerima memeriksa apakah resolusi forward dan reverse-nya sepakat, dan PTR yang hilang saja sudah cukup untuk ditandai sebagai spam.
• Tambahkan alamat baru ke SPF sebelum cutover dan hapus yang lama sesudahnya — keduanya tercantum selama masa tumpang tindih, supaya mail tetap terautentikasi dari server mana pun yang sebenarnya mengirimkannya.
• Salin private key DKIM yang sudah ada alih-alih men-generate yang baru, supaya selector yang sudah dipublikasikan di DNS tetap tervalidasi. Meng-generate ulang berarti harus mempublikasikan ulang, dan mempublikasikan ulang punya delay propagasinya sendiri.
• Panaskan alamat baru itu secara bertahap kalau Anda mengirim dalam volume berapa pun. Server yang sepanjang hidupnya belum pernah mengirim apa-apa lalu tiba-tiba memuntahkan sepuluh ribu pesan, di mata penerima, tidak bisa dibedakan dari host yang sudah dikompromikan.

Cutover

Semua yang di atas adalah persiapan supaya bagian ini singkat, berurutan, dan reversibel. Lakukan pada titik traffic paling rendah Anda yang sungguhan, bukan jam 3 pagi karena sekadar kepercayaan — cek analytics Anda sendiri. Tuliskan dulu rollback-nya sebelum Anda mulai, karena momen Anda membutuhkannya adalah momen ketika Anda paling tidak ingin harus menyusunnya.

1. 1

   Freeze penulisan di server lama

   Maintenance mode, database user read-only, atau error pada write path di reverse proxy-nya. Pembacaan tetap dilayani dari mesin lama sepanjang proses ini — itulah yang menjaga situsnya tetap up selagi datanya berpindah.

2. 2

   Disable semua timer di server lama

   Comment out crontab-crontabnya, stop timer-nya, stop queue worker-nya. Mulai dari titik ini mesin lama tidak boleh memproses apa pun lagi, kalau tidak job-nya akan berjalan dua kali: dua invoice, dua email, dua pengiriman webhook.

3. 3

   Jalankan delta terakhirnya

   Tahap file kedua dengan --delete, lalu dump database terakhir atau replica-nya menuntaskan ketertinggalan. Ini yang singkat, paling lama beberapa menit, karena tahap pertama sudah memindahkan sebagian besar volumenya.

4. 4

   Verifikasi server baru terhadap hostname sungguhannya

   Dengan trik --resolve di atas tadi, uji sebuah halaman yang membaca dari database, sebuah login, dan satu write path. Pastikan row count-nya cocok dengan source-nya. Lakukan semua ini sebelum DNS berubah, selagi rollback masih sama sekali tidak berbiaya apa-apa.

5. 5

   Switch DNS dan start service-nya

   Update A dan AAAA ke alamat baru, lalu enable dan start aplikasinya beserta timer-timernya di server baru. Traffic mulai berdatangan dalam satu periode TTL dan terus bergeser selama satu jam berikutnya.

6. 6

   Biarkan server lama tetap melayani pembacaan

   Biarkan tetap up, read-only, selama setidaknya dua puluh empat jam. Client dengan cache yang sudah basi akan tetap mendarat di situ, dan server lama yang read-only mengembalikan halaman yang sedikit basi alih-alih koneksi yang ditolak — itulah bedanya antara migrasi yang tidak terlihat dan yang terlihat.

48 jam pertama

Migrasinya belum selesai begitu situsnya termuat. Ini selesai ketika tidak ada apa pun lagi yang masih bergantung pada mesin lama, dan menemukan dependency-dependency itu adalah usaha aktif, bukan sekadar permainan menunggu.

• Awasi access log server lama. Setiap request yang masih sampai di situ adalah dependency yang belum termigrasi — alamat hard-coded di sebuah integrasi partner, mobile client dengan cache yang basi, probe monitoring yang tidak dimiliki siapa pun. Log itu sendiri adalah to-do list-nya.
• Pastikan timer-timernya benar-benar berjalan di host baru. Bukan sekadar sudah enabled — tapi benar-benar berjalan, pada waktu yang diharapkan, dengan output yang diharapkan. cron job yang diam-diam tidak melakukan apa-apa terlihat persis sama seperti cron job yang berfungsi.
• Uji renewal sertifikatnya secara sungguhan dengan sebuah dry run, alih-alih baru menemukan enam puluh hari kemudian bahwa ACME client Anda selama ini melakukan renewal terhadap server yang sudah tidak lagi menerima challenge-nya.
• Periksa alur mail end to end di kedua arah, termasuk apa pun yang dikirim aplikasinya secara otomatis. Password reset adalah korban klasiknya, karena tidak ada yang mengetesnya sampai seorang pengguna benar-benar membutuhkannya.
• Ambil backup dari server baru dan restore di suatu tempat. Mesin baru tanpa backup yang terverifikasi adalah posisi yang lebih buruk daripada yang Anda tinggalkan; /guides punya versi lengkap dari argumen itu.
• Kembalikan TTL DNS-nya ke nilai normal begitu Anda sudah yakin. Membiarkannya di 300 detik selamanya adalah biaya permanen kecil dalam bentuk query dan latensi, tanpa manfaat yang tersisa.

Mempensiunkan server lama

Langkah terakhir ini yang paling sering dilewatkan, dan ini satu-satunya langkah yang punya konsekuensi privasi. Disk lama menyimpan key Anda, database Anda, data pelanggan Anda, dan log Anda, dan membatalkan layanannya tidak menghapus satu pun dari itu — itu hanya melepaskan volume-nya kembali ke sebuah pool, di mana tenant berikutnya menerima apa pun sisa yang ditinggalkan oleh kebijakan wipe milik provider tersebut.

• Tunggu sampai access log lama benar-benar sepi sebelum Anda menyentuh apa pun. Membatalkan selagi sebuah payment provider masih mengirim webhook ke alamat lama adalah cara migrasi berubah menjadi insiden seminggu kemudian.
• Rotate, jangan sekadar dihapus: setiap kredensial yang dipegang server lama — API key, password database, deploy key, migration key yang sementara tadi. Anggap saja apa pun yang pernah ada di mesin yang sudah tidak Anda kendalikan lagi sudah dikompromikan, karena cepat atau lambat memang begitu.
• Timpa datanya sebelum melepaskan volume-nya. Hancurkan direktori yang sensitif, atau penuhi ruang kosongnya dengan satu file acak berukuran besar lalu hapus. Tidak sempurna pada disk yang divirtualisasi, tapi jauh lebih baik daripada tidak sama sekali.
• Ambil satu arsip terakhir dari apa pun yang mungkin masih Anda butuhkan sebagai referensi — log, konfigurasi, shell history yang mendokumentasikan apa yang sebenarnya sudah dilakukan — dan simpan dalam keadaan terenkripsi di tempat yang bukan salah satu dari kedua server itu.
• Batalkan layanannya hanya setelah yang baru sudah bertahan satu siklus penagihan penuh dan lulus satu tes backup-and-restore penuh. Bulan tumpang tindih itu adalah asuransi termurah di seluruh proses ini.

Timeline yang tinggal Anda salin

Tidak ada satu pun di sini yang sulit kalau berdiri sendiri. Alasan migrasi berjalan buruk adalah karena semua langkahnya dipadatkan ke dalam satu malam saja, di mana TTL-nya belum habis masa berlakunya, sertifikatnya belum diuji, dan rollback-nya belum ditulis. Disebar sepanjang satu minggu, setiap harinya cuma dua puluh menit kerja.

Bagaimana migrasi benar-benar berjalan salah

Bukan lewat proses penyalinan. Lewat hal-hal yang tidak pernah ada di disk, dan hal-hal yang berjalan dua kali.

• Kedua server menulis pada saat bersamaan — jendela split-brain, dan satu-satunya kegagalan di sini yang tidak punya perbaikan yang bersih. Ini dicegah lewat urutan, bukan lewat tooling: hentikan yang lama, baru start yang baru.
• Timer yang berjalan di kedua mesin, itulah cara pelanggan menerima dua kali dari segalanya. Disable yang lama sebelum sync terakhir, bukan sesudahnya.
• TTL yang tidak pernah diturunkan, yang mengubah cutover lima menit menjadi ekor sepanjang satu hari yang tidak pernah direncanakan siapa pun untuk dijaga.
• Ownership file yang salah mendarat karena numeric ID berbeda antara kedua mesin, sehingga aplikasinya start tapi lalu tidak bisa menulis ke direktori upload-nya sendiri.
• Sertifikat yang rencananya baru akan diurus setelah switch, bertemu dengan header HSTS yang membuat pengunjung tidak punya cara untuk melanjutkan.
• Alamat yang hard-coded di suatu tempat yang tidak Anda kendalikan — sebuah integrasi partner, sebuah aturan firewall, sebuah DNS record untuk subdomain yang bahkan sudah Anda lupa keberadaannya.
• Membatalkan server lama tepat pada hari kepindahan, yang menghilangkan jalur rollback persis pada momen ketika statistik mengatakan Anda paling mungkin membutuhkannya.