Migrasikan VPS ke host baru tanpa downtime

Tiga jam itu, dan kenapa “zero downtime” adalah target yang salah#

Apa yang masih dipegang host lama setelah Anda pergi#

Jam TTL mulai berjalan seminggu sebelum proses pindah#

dig +noall +answer example.com A
dig +noall +answer www.example.com A
dig +noall +answer example.com MX
dig +noall +answer example.com NS

Menentukan ukuran server baru, dan apa yang perlu dicek sebelum Anda memutuskannya#

# peak RAM actually in use, not allocated
free -m
# what has been paging, if anything
vmstat -s | grep -i swap
# real disk consumption, biggest first
du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -20
# load relative to core count
uptime; nproc

Langkah demi langkah#

1. Turunkan semua TTL, berhari-hari sebelum Anda berencana pindah

   Ini yang pertama karena ini satu-satunya langkah dengan masa tunggu wajib. Semua yang lain bisa dikerjakan dalam satu sore; yang ini tidak bisa dipercepat, dan melewatkannya adalah yang mengubah cutover lima menit jadi cutover dua hari.

   Login ke tempat zone Anda berada dan atur TTL ke 300 pada setiap record yang akan berubah: A apex-nya, AAAA-nya, www, mail, dan apa pun lain yang menunjuk ke literal IP. Lalu konfirmasi dari luar, karena panel kontrol dan kenyataan kadang tidak sepakat:

   dig +noall +answer example.com A @1.1.1.1
   dig +noall +answer example.com AAAA @1.1.1.1
   dig +noall +answer www.example.com A @8.8.8.8

   Angka sebelum IN adalah TTL yang tersisa. Query lagi semenit kemudian: seharusnya sedang menghitung mundur dari 300, bukan dari angka yang lebih besar. Kalau masih menghitung mundur dari 3600, nilai lamanya masih ter-cache dan Anda tinggal menunggu — dan itulah persisnya kenapa ini dilakukan pada hari minus tujuh, bukan pada pagi hari saat pindah.

   Biarkan TTL tetap di 300 selama migrasi dan selama seminggu setelahnya, supaya rollback Anda juga cepat. Kembalikan ke angka yang masuk akal — 3600 sudah cukup baik — begitu server lama sudah tidak ada lagi.

2. Inventarisasi server lama sebelum menyalin apa pun

   Anda bukan sedang memigrasikan sebuah disk, Anda sedang memigrasikan sebuah sistem yang sedang berjalan, dan bagian-bagian yang sering dilupakan orang tidak pernah ada di /var/www. Itu adalah cron job yang berjalan setiap tanggal empat, aturan firewall yang ditambahkan saat ada insiden, package yang diinstal dari repository pihak ketiga dua tahun lalu. Tangkap state mesin itu sebagai teks, dan salin teks itu bersama semua yang lain:

   mkdir -p /root/mig
   dpkg --get-selections > /root/mig/packages.txt
   systemctl list-units --type=service --state=running --no-pager > /root/mig/services.txt
   systemctl list-timers --all --no-pager > /root/mig/timers.txt
   crontab -l > /root/mig/cron-root.txt 2>/dev/null
   for u in $(cut -d: -f1 /etc/passwd); do crontab -lu "$u" 2>/dev/null | sed "s/^/[$u] /"; done > /root/mig/cron-users.txt
   ss -tlnp > /root/mig/listening.txt
   nft list ruleset > /root/mig/firewall.txt 2>/dev/null || iptables-save > /root/mig/firewall.txt
   cp -a /etc/hosts /etc/fstab /root/mig/
   du -xh --max-depth=2 / 2>/dev/null | sort -rh | head -40 > /root/mig/disk.txt

   Sekarang baca listening.txt baris demi baris dan pastikan setiap port sudah dijelaskan. Berkas itu adalah jawaban definitif untuk “server ini sebenarnya melakukan apa”, dan hasilnya rutin mengejutkan — sebuah metrics exporter, salinan staging yang terlupakan, sebuah database yang listening di interface publik yang seharusnya tidak pernah begitu.

   Tulis daftar exclude Anda di saat yang sama, supaya sync pertama tidak menghabiskan satu jam untuk data yang tidak Anda inginkan:

   cat > /root/mig/excludes <<'EOF'
   /dev
   /proc
   /sys
   /run
   /tmp
   /var/tmp
   /var/cache
   /var/lib/apt/lists
   /swapfile
   /var/lib/docker/overlay2
   /var/lib/mysql
   /var/lib/postgresql
   **/node_modules
   **/.cache
   EOF

   Perhatikan bahwa direktori database memang sengaja dikecualikan. Itu punya langkahnya sendiri, dan menyalinnya di sini adalah kesalahan yang justru dicegah oleh keberadaan langkah enam.

3. Deploy server baru dan harden dulu sebelum menyimpan apa pun

   Pesan server-nya, pilih lokasinya, dan pakai versi mayor OS yang sama dengan yang lama kalau bisa. Memigrasikan host sekaligus berpindah dari Debian 12 ke Debian 13 dalam satu operasi berarti kalau ada yang rusak Anda tidak akan tahu perubahan mana yang menyebabkannya. Pindah dulu, upgrade belakangan.

   Sebelum ada apa pun yang sensitif mendarat di situ, berikan mesin itu hardening sepuluh menit: SSH cuma dengan key, login root dimatikan, firewall default-deny, unattended security upgrades. Butuh sepuluh menit sekarang dan benar-benar merepotkan kalau harus diterapkan belakangan di sekitar layanan yang sudah live.

   Lalu buat sebuah key yang cuma ada untuk migrasi ini, di server lama, supaya mencabut akses migrasi belakangan tidak pernah berarti menyentuh login Anda sendiri:

   # on the OLD server
   ssh-keygen -t ed25519 -f /root/.ssh/id_migrate -C 'migration' -N ''
   cat /root/.ssh/id_migrate.pub

   Masukkan public key itu ke /root/.ssh/authorized_keys di server baru, lalu pastikan arah pergerakannya — lama push ke baru, jadi kredensialnya tetap tinggal di mesin yang akan Anda tinggalkan dan mati bersamanya:

   ssh -i /root/.ssh/id_migrate root@NEW_IP 'hostname; df -h /; free -m'

   Terakhir, masukkan IP baru ke /etc/hosts server lama dengan nama seperti newbox. Setiap perintah berikutnya jadi lebih singkat dan, yang lebih berguna, lebih sulit diarahkan ke mesin yang salah pada jam satu dini hari.

4. Cek IP baru sebelum mempercayakan apa pun ke situ

   Sekarang Anda punya alamat yang belum pernah dipakai siapa pun untuk layanan Anda sebelumnya, dan ini momen terakhir di mana menemukan masalah dengannya masih gratis. Tiga pengecekan, lima menit:

   Blocklist. Jalankan alamatnya lewat pengecekan multi-RBL — prosedur lengkap dan cara membaca hasilnya ada di sini. Kena hit di policy list seperti Spamhaus PBL itu normal untuk IP datacenter dan hampir tidak berarti apa-apa untuk traffic web. Kena hit di SBL atau XBL itu baru serius, dan waktu untuk mengangkatnya adalah sekarang, bukan setelah pengguna Anda sudah ada di situ.

   Reverse DNS. Cek alamat itu menjawab dengan apa hari ini:

   dig +short -x NEW_IP

   Kalau server ini akan mengirim mail, minta PTR record yang Anda inginkan dan pastikan itu cocok dengan hostname yang A record-nya menunjuk balik ke IP yang sama. Forward dan reverse harus sepakat; ketidakcocokan lebih buruk daripada nama generik.

   Keterjangkauan dan rute. Pastikan port yang Anda butuhkan benar-benar terbuka ujung ke ujung, dari luar, alih-alih mengasumsikan firewall Anda adalah satu-satunya hal di jalurnya:

   # from a third machine, or your laptop
   nc -vz NEW_IP 22
   mtr -rwc 20 NEW_IP

   Output mtr adalah yang layak disimpan. Loss di hop terakhir itu penting; loss di hop perantara biasanya cuma router yang menurunkan prioritas ICMP dan tidak berarti apa-apa. Kalau latency dari wilayah pengguna Anda jauh lebih buruk daripada host lama, lebih baik ketahui itu sekarang, selagi berubah pikiran masih cuma berbiaya satu pesanan dan tanpa kehilangan data.

5. Salin filesystem dengan rsync — dan dry-run dulu

   Sekarang transfer massalnya. Lakukan dalam dua pass: salinan penuh pertama berhari-hari sebelumnya, sebutuh apa pun waktu yang diperlukan, lalu pass delta singkat belakangan yang cuma memindahkan apa yang berubah. Selalu dry-run dulu — output-nya adalah daftar persis apa yang akan terjadi, dan membacanya sekali sudah menyelamatkan lebih banyak migrasi daripada kebiasaan lain mana pun di sini.

   # on the OLD server, dry run
   rsync -aHAXx --numeric-ids --info=progress2 --dry-run \
     --exclude-from=/root/mig/excludes \
     -e 'ssh -i /root/.ssh/id_migrate' \
     /var/www/ root@newbox:/var/www/

   Lalu perintah yang sama tanpa --dry-run. Ulangi untuk setiap direktori yang penting: /etc secara selektif, bukan seluruhnya, /home, /srv, /opt, dan di mana pun aplikasi Anda sebenarnya menyimpan uploads-nya.

   Flag-flag itu pantas dipakai. -a mempertahankan permission, ownership, timestamp, dan symlink; -H menjaga hard link; -A dan -X membawa ACL dan extended attribute, yang dibutuhkan direktori uploads Anda kalau pernah ada yang mengatur itu; -x mencegah rsync mengembara ke filesystem lain yang ter-mount. --numeric-ids adalah yang sering dilewatkan orang dan disesali: tanpa itu, rsync memetakan ownership berdasarkan nama, dan kalau www-data punya UID berbeda di kedua server, setiap berkas tiba dengan pemilik yang salah dengan cara yang merepotkan untuk diurai.

   Dua peringatan. Menyalin /etc secara utuh ke sistem yang sedang berjalan akan menimpa konfigurasi jaringan mesin baru, fstab-nya, dan SSH host key-nya — salin konfigurasi spesifik yang Anda butuhkan, bukan direktorinya. Dan simpan --delete hanya untuk pass terakhir: itu tepat untuk membuat server baru cocok persis dengan yang lama, dan destruktif kalau Anda sudah membuat sesuatu di tujuan.

   Begitu pass penuh pertama selesai, bandingkan kedua sisi supaya Anda tahu itu sudah melakukan apa yang Anda kira:

   du -sh /var/www
   ssh -i /root/.ssh/id_migrate root@newbox 'du -sh /var/www'

6. Pindahkan database dengan dump, jangan pernah dengan salinan berkas

   Ini langkah yang menentukan apakah migrasi Anda membosankan atau tak terlupakan. Direktori data sebuah database cuma konsisten kalau server-nya berhenti. Salin itu secara live dan Anda dapat sekumpulan berkas yang terlihat baik, ter-transfer dengan baik, dan kalau di-restore jadi database yang korup secara halus dan permanen — sering kali tanpa error sampai berminggu-minggu kemudian.

   Dump dengan benar. Untuk MySQL atau MariaDB, --single-transaction adalah yang memberi Anda snapshot konsisten tanpa mengunci semuanya:

   mysqldump --single-transaction --quick --routines --triggers --events \
     --default-character-set=utf8mb4 --databases appdb \
     | zstd -T0 > /root/mig/appdb.sql.zst

   Untuk PostgreSQL, custom format-nya sepadan — itu terkompresi, dan memungkinkan Anda restore secara selektif kalau perlu:

   pg_dump -Fc -Z6 appdb > /root/mig/appdb.dump

   Kirim ke server baru dan restore:

   scp -i /root/.ssh/id_migrate /root/mig/appdb.sql.zst root@newbox:/root/
   # on the NEW server
   zstd -dc /root/appdb.sql.zst | mysql
   # postgres equivalent
   pg_restore -d appdb -j4 /root/appdb.dump

   Lalu verifikasi, karena “restore-nya selesai” dan “datanya memang ada di situ” adalah dua klaim yang berbeda. Bandingkan row count pada tabel-tabel yang penting, di kedua sisi:

   mysql -N -e "SELECT COUNT(*) FROM appdb.orders; SELECT COUNT(*) FROM appdb.users;"

   Dua hal yang bersembunyi di dalam dump: character set dan collation, yang jadi sumber karakter beraksen yang berantakan — kalau database lama memakai utf8, bukan utf8mb4, putuskan secara sadar apakah proses pindah ini juga jadi momen untuk memperbaikinya; dan user database beserta grant-nya, yang tidak disertakan oleh mysqldump --databases. Buat ulang user dan password aplikasinya secara eksplisit di server baru, lalu ingat bahwa connection string di konfigurasi Anda harus disesuaikan.

   Kalau aplikasi Anda memakai SQLite, berkasnya adalah database-nya dan aturan yang sama berlaku — jangan salin itu secara live. Pakai sqlite3 app.db ".backup /root/mig/app.db", yang mengambil salinan konsisten dengan aman.

7. Nyalakan stack-nya dan gladi bersih di balik hosts-file override

   Server baru sekarang sudah punya berkas-berkas dan data-nya. Nyalakan semuanya dan uji di bawah hostname aslinya — selagi seluruh dunia lain masih dengan senang hati memakai server lama. Ini trik paling berharga dalam seluruh prosedur ini dan cuma berbiaya satu baris.

   Di laptop Anda sendiri, tambahkan IP server baru ke /etc/hosts (atau C:\Windows\System32\drivers\etc\hosts):

   203.0.113.10   example.com www.example.com

   Browser Anda sekarang me-resolve domain aslinya ke server baru, dan tidak ada browser lain yang begitu. Setiap URL benar, setiap cookie domain cocok, setiap redirect dan callback path berperilaku persis seperti yang akan terjadi setelah cutover — yang justru tidak akan terungkap kalau Anda menguji lewat subdomain sementara seperti new.example.com, karena separuh dari yang bisa rusak dalam migrasi bergantung pada hostname.

   Untuk satu pengecekan cepat tanpa mengubah apa pun, curl bisa melakukan hal yang sama secara inline:

   curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/
   curl -sS --resolve example.com:80:203.0.113.10 http://example.com/ -o /dev/null -w '%{http_code}\n'

   Jelajahi seluruh aplikasinya, bukan cuma halaman depan: login, kirim formulir, unggah berkas, picu mail reset password, muat halaman admin, panggil endpoint yang dipanggil payment processor. Lalu baca error log meskipun semuanya terlihat baik-baik saja — PHP extension yang hilang, file mode yang salah di direktori cache, dan user database yang belum ada semuanya muncul di situ sebelum muncul di layar.

   Ingat untuk menghapus baris hosts-nya setelahnya. Semua orang pernah lupa sekali, lalu menghabiskan dua puluh menit bertanya-tanya kenapa rollback-nya kelihatan tidak berhasil.

8. Buat TLS berfungsi di server baru sebelum Anda mengalihkan apa pun

   Sertifikat terikat pada nama, bukan pada alamat IP, jadi tidak ada apa pun dari sebuah migrasi yang membatalkan sertifikat yang sudah Anda punya. Yang bermasalah adalah penerbitannya: HTTP-01 challenge yang biasa dipakai meminta Let's Encrypt mengambil sebuah berkas lewat port 80 di nama yang sedang disertifikasi, dan nama itu masih menunjuk ke server lama. Ayam dan telur ini adalah keseluruhan kesulitannya, dan ada tiga cara bersih untuk keluar darinya.

   Salin sertifikat yang sudah ada. Paling sederhana dan biasanya paling tepat. Private key dan chain-nya berpindah seperti berkas lain mana pun:

   rsync -aHAX -e 'ssh -i /root/.ssh/id_migrate' \
     /etc/letsencrypt/ root@newbox:/etc/letsencrypt/

   Server baru bisa langsung melayani TLS yang valid, dan renewal-nya mulai berfungsi sendiri begitu DNS menunjuk ke situ. Pastikan timer-nya aktif di sana: systemctl list-timers | grep certbot.

   Pakai DNS-01 challenge. Membuktikan kendali atas domain lewat sebuah TXT record, bukan lewat request HTTP, jadi ini berfungsi dari server yang belum ditunjuk apa pun. Ideal kalau Anda ingin sertifikat yang benar-benar independen di server baru sebelum cutover, dan satu-satunya opsi untuk wildcard.

   Terbitkan setelah beralih. Valid, tapi ini meninggalkan celah di mana situsnya sudah live di IP baru tanpa sertifikat, yang untuk apa pun yang memakai HSTS bukan sekadar peringatan yang bisa diklik lewat oleh pengunjung Anda. Cuma masuk akal untuk domain yang benar-benar baru yang belum pernah dikunjungi siapa pun.

   Apa pun yang Anda pilih, verifikasi langsung terhadap IP baru sebelum cutover, memakai trik --resolve yang sama:

   curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/ | head -1
   echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null \
     | openssl x509 -noout -subject -dates

   Cek tanggalnya dan pastikan subject-nya mencakup setiap nama yang Anda layani, termasuk www. Dan kalau Anda memakai HSTS dengan max-age yang panjang, perlakukan sertifikatnya sebagai satu hal yang harus benar sebelum beralih, bukan sesudahnya — header itu adalah janji yang sudah Anda buat ke setiap pengunjung yang kembali.

9. Cutover-nya: bekukan tulisan, delta terakhir, alihkan record-nya

   Sepuluh menit kerja sungguhan, dan satu-satunya bagian yang punya jam berjalan di atasnya. Lakukan di pagi hari, di zona waktu Anda sendiri, pada hari Anda tidak sedang sibuk dengan hal lain. Jangan pernah di hari Jumat.

   Bekukan. Masukkan aplikasi lama ke mode maintenance atau read-only. Hentikan worker, konsumer antrean, dan cron job — apa pun yang menulis tanpa browser yang terhubung. Sejak titik ini, tidak ada yang baru ditulis di server lama, dan itulah yang membuat semua yang terjadi setelahnya aman:

   # on the OLD server
   systemctl stop app-worker.service
   systemctl stop cron
   touch /var/www/maintenance.flag

   Delta terakhir. Satu rsync lagi, sekarang dengan --delete supaya tujuannya cocok persis, dan satu dump lagi. Dengan pass pertama sudah selesai berhari-hari sebelumnya, ini cuma memindahkan sangat sedikit dan cuma butuh beberapa detik:

   rsync -aHAXx --numeric-ids --delete --exclude-from=/root/mig/excludes \
     -e 'ssh -i /root/.ssh/id_migrate' /var/www/ root@newbox:/var/www/
   mysqldump --single-transaction --quick --routines --triggers --events \
     --default-character-set=utf8mb4 --databases appdb | zstd -T0 \
     | ssh -i /root/.ssh/id_migrate root@newbox 'zstd -dc | mysql'

   Cek. Row count di kedua sisi, satu pass lagi lewat aplikasinya lewat hosts-file override, dan lepaskan maintenance flag dari server baru.

   Alihkan. Ubah A record ke IP baru. Ubah AAAA record-nya juga — ini cara paling umum sebuah cutover cuma berhasil separuh. Konfirmasi dari resolver yang tidak Anda kendalikan:

   dig +short example.com A @1.1.1.1
   dig +short example.com AAAA @1.1.1.1

   Lalu pantau kedua mesin. Traffic seharusnya muncul di server baru dalam satu-dua menit dan memudar dari server lama dalam lima menit berikutnya:

   tail -f /var/log/nginx/access.log        # on both, side by side

   Biarkan aplikasi lama tetap dalam mode maintenance, alih-alih mematikannya. Pengunjung yang tersisa dan sampai ke situ akan melihat halaman yang sopan, bukan connection error, dan Anda tetap punya mesin yang siap untuk rollback yang mungkin tidak akan Anda butuhkan.

10. Pantau selama seminggu, baru dekomisioning dengan benar

    Migrasi belum selesai begitu DNS sudah ter-resolve. Itu selesai begitu satu siklus penuh billing dan cron sudah berlalu tanpa kejutan.

    Untuk beberapa jam pertama, pantau error rate, bukan uptime — sebuah server bisa saja sepenuhnya up dan tetap mengembalikan 500 untuk sepertiga request-nya:

    journalctl -u nginx -u php8.4-fpm -f
    awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

    Lalu telusuri daftar singkat ini, karena inilah yang benar-benar rusak setelah pindah dan tidak satu pun dari ini akan mengumumkan dirinya sendiri: cron job dan systemd timer yang berjalan di server baru (systemctl list-timers dicocokkan dengan inventaris yang Anda ambil di langkah dua); mail keluar yang benar-benar sampai dan tidak mendarat di spam; backup terjadwal yang menunjuk ke server baru, bukan masih mengarsipkan server lama; pihak ketiga mana pun yang punya alamat IP Anda di allowlist — payment processor, sebuah API, firewall milik partner; dan job bulanan yang cuma membuktikan dirinya pada tanggal satu.

    Biarkan server lama tetap berjalan, dalam mode maintenance, tidak disentuh, selama setidaknya seminggu. Itu adalah rollback Anda sekaligus salinan referensi Anda, dan itu bernilai lebih daripada beberapa dolar biayanya. Lalu tutup dengan urutan ini: rotasi setiap secret yang bisa dibaca olehnya, ambil satu arsip terenkripsi terakhir ke lokasi ketiga, timpa direktori aplikasi dan database-nya, jalankan rutinitas destroy atau reinstall milik provider, dan baru batalkan — setelah mengecek tanggal perpanjangannya, karena satu bulan ekstra asuransi rollback biasanya trade yang lebih baik.

    Terakhir, kembalikan TTL ke 3600 sekarang karena Anda tidak lagi butuh reversibilitas lima menit, dan perbarui dokumentasi apa pun yang Anda simpan dengan alamat barunya. Anda di masa depan, pada suatu jam 2 dini hari nanti, akan sangat berterima kasih karena runbook-nya cocok dengan server yang sebenarnya.

Mail tidak ikut migrasi bersama yang lain#

Rollback tanpa membuatnya makin buruk#

Dekomisioning: rotasi, hapus, verifikasi, baru batalkan#

Linimasa yang benar-benar berhasil#

Pertanyaan yang sering diajukan#