Membaca Log Transfer Tool WHM Saat Migrasi Akun Berhenti di Tengah Jalan

Transfer Tool WHM sering berjalan normal di awal, lalu progresnya berhenti atau selesai dengan tanda gagal tanpa keterangan berguna. Pesan seperti 'restore failed' di antrean tidak memberi tahu langkah mana yang bermasalah: apakah database, ruang disk, atau nama akun yang bentrok. Penyebabnya hampir selalu tercatat di log sesi transfer di server tujuan, hanya saja jarang ada yang membukanya. Tulisan ini disusun seperti post-mortem, tapi bukan catatan satu insiden tertentu. Isinya pola umum yang sering muncul saat migrasi akun cPanel macet di tengah jalan.

Dampak yang terlihat dari sisi pengguna

Transfer Tool bekerja dari server tujuan. Server tujuan login ke server sumber, menyuruh sumber membuat arsip akun, menarik arsip itu, lalu me-restore-nya. Di halaman progres biasanya terlihat dua antrean terpisah, yaitu antrean transfer dan antrean restore. Ini detail penting, karena kegagalan di fase transfer dan kegagalan di fase restore punya penyebab yang sangat berbeda. Dampak yang paling membingungkan adalah akun yang setengah jadi. Username sudah dibuat di server tujuan, file di public_html sudah ada, tapi database kosong atau email belum ikut. Kalau ada yang buru-buru mengganti DNS, situs langsung tampil error koneksi database. Kalau DNS belum dipindah, situs di server lama masih jalan dan dampaknya hanya waktu yang terbuang. Karena itu, aturan pertama saat migrasi macet: jangan sentuh DNS dulu sampai jelas apa yang gagal. Di meja support, pertanyaan yang biasa datang cuma 'migrasinya gagal, kenapa ya?' tanpa detail lain. Jawaban yang bisa dipertanggungjawabkan hanya bisa didapat dari log, bukan dari tebakan berdasarkan tampilan layar.

Urutan penelusuran dari sesi sampai item

Setiap kali Transfer Tool dijalankan, WHM membuat satu sesi dengan ID tersendiri. ID ini biasanya terlihat di halaman progres atau di URL-nya. Catat ID tersebut, karena semua log terkait tersimpan per sesi. Urutan yang biasanya paling cepat:

Cari direktori sesi di server tujuan.
Baca log utama sesi untuk melihat item mana yang gagal, akun A di fase transfer atau akun B di fase restore.
Buka log per item untuk akun yang gagal.
Cocokkan waktunya dengan error log cPanel di /usr/local/cpanel/logs/error_log.
Kalau gagalnya di fase transfer, periksa juga sisi server sumber, karena arsip dibuat di sana.

BASH

# Daftar sesi transfer, urut dari yang paling lama ke terbaru
ls -ltr /var/cpanel/transfer_session/

# Isi satu sesi (ganti SESSION_ID dengan ID dari halaman progres)
ls -l /var/cpanel/transfer_session/SESSION_ID/

# Cari baris error, fail, atau warning di semua log sesi (read-only)
grep -inE 'error|fail|warn' /var/cpanel/transfer_session/SESSION_ID/*.log

Nama file di dalam direktori sesi bisa sedikit berbeda antar versi cPanel. Umumnya ada satu log utama dan beberapa log per item, dan nama filenya biasanya cukup jelas menunjukkan fase transfer atau restore beserta akunnya. Kalau direktori sesi tidak ada, kemungkinan sesi sudah dibersihkan atau versi yang dipakai menyimpan log di tempat lain. Dalam kasus itu, error log cPanel tetap jadi pegangan. Cara berpikirnya mirip membaca log task backup di Proxmox: cari langkah terakhir yang berhasil, lalu baris pertama yang gagal. Polanya pernah dibahas di Membaca Log Task vzdump Proxmox Saat Backup VM Gagal di Tengah Jalan.

Titik yang biasanya membuka masalah

Momen penemuannya hampir selalu sama: baris error pertama di log per item. Error yang muncul setelahnya sering cuma efek berantai. Misalnya, import database gagal, lalu langkah berikutnya yang memberi privilege ke user database ikut gagal karena database-nya tidak ada. Kalau kita fokus ke error terakhir, kita akan mengejar masalah yang salah.

TEXT

# contoh format output, bukan log asli
[restore] Restoring account files ... done
[restore] Restoring databases ...
[restore] Error: failed to import database namauser_wp
[restore] Warning: unable to grant privileges for namauser_wpuser
[restore] Restore completed with errors

Dari contoh di atas, yang perlu dikejar adalah baris import database, bukan warning soal privilege. Secara umum, error pertama biasanya jatuh ke salah satu kategori ini. Konflik nama akun atau domain. Restore akan menolak kalau username yang sama sudah ada di server tujuan, atau kalau domain akun itu sudah dimiliki akun lain. Ini sering terjadi saat migrasi diulang setelah percobaan pertama gagal, atau saat ada akun uji coba dengan domain yang sama. Cek dengan grep '^namauser:' /etc/passwd dan grep 'domainnya.com' /etc/userdomains di server tujuan. Database. Import bisa gagal karena dump terlalu besar untuk batas yang berlaku, ada objek dengan DEFINER yang merujuk ke user yang tidak ada, atau versi MySQL/MariaDB di kedua server terlalu berbeda. Bandingkan hasil mysql -V di sumber dan tujuan. Kalau versinya jauh berbeda, anggap itu tersangka utama sampai terbukti sebaliknya. Ruang disk dan quota. Arsip akun perlu tempat untuk disalin lalu diekstrak, jadi kebutuhan ruang sementara bisa lebih besar dari ukuran akun itu sendiri. Cek df -h /home dan df -i /home. Inode yang habis juga bisa bikin restore gagal walaupun ruang dalam GB masih terlihat longgar. Soal quota paket yang lebih kecil dari pemakaian akun, perilakunya tergantung versi dan pengaturan quota filesystem. Ada yang berupa warning, ada yang membuat sebagian data gagal ditulis. Koneksi dan timeout. Kalau gagalnya di fase transfer, biasanya penyebabnya autentikasi SSH ke server sumber, firewall, atau pembuatan arsip di sumber yang terlalu lama untuk akun besar. Di sini log di server sumber dan pemakaian disk sumber juga perlu dilihat.

Mitigasi sementara saat Transfer Tool tetap gagal

Setelah penyebabnya ketemu, langkah paling bersih biasanya memperbaiki penyebab itu dulu, lalu menjalankan ulang transfer khusus untuk akun yang gagal. Misalnya dengan mengosongkan ruang disk, menyamakan konfigurasi database, atau menyelesaikan konflik domain. Perhatian sebelum menjalankan ulang: kalau akun setengah jadi masih ada di server tujuan, restore berikutnya bisa bentrok dengan nama yang sama. Menghapus akun itu, baik lewat WHM maupun /scripts/removeacct, akan menghapus semua file, database, dan email akun tersebut di server tujuan. Proses ini tidak bisa dibatalkan. Pastikan itu benar-benar salinan yang gagal, bukan akun yang sudah dipakai pelanggan, dan pastikan data aslinya masih utuh di server sumber. Kalau Transfer Tool terus macet di fase transfer, misalnya karena koneksi antarserver tidak stabil, cara manual sering lebih mudah dikendalikan:

BASH

# Di server sumber: buat arsip akun
/scripts/pkgacct namauser

# Salin arsip ke server tujuan (sesuaikan host, port, dan path)
rsync -avP /home/cpmove-namauser.tar.gz root@SERVER_TUJUAN:/home/

# Di server tujuan: restore arsip
/scripts/restorepkg /home/cpmove-namauser.tar.gz

Cara ini memisahkan tiga langkah yang biasanya digabung Transfer Tool. Kalau ada yang gagal, kita langsung tahu di langkah mana. Lokasi output pkgacct bisa berbeda tergantung konfigurasi, jadi lihat baris terakhir outputnya. Opsi untuk menimpa akun yang sudah ada juga berbeda antar versi, cek dengan /scripts/restorepkg --help sebelum memakainya. Setelah restore, buka situs lewat file hosts lokal atau URL sementara, dan pastikan database serta email benar-benar ada sebelum DNS dipindah.

Perbaikan proses supaya migrasi berikutnya tidak macet di tempat yang sama

Mitigasi di atas menyelesaikan satu akun. Perbaikan yang sebenarnya ada di proses sebelum migrasi dimulai, karena sebagian besar penyebab di atas bisa terdeteksi lebih awal. Pertama, lakukan pengecekan awal di server tujuan. Cek ruang disk dan inode, versi MySQL/MariaDB dan PHP dibandingkan dengan server sumber, serta daftar username dan domain yang mungkin bentrok. Sebagai aturan praktis yang kasar, siapkan ruang kosong sekitar dua kali ukuran akun terbesar supaya proses salin dan ekstrak tidak kehabisan tempat. Ini perkiraan, bukan angka resmi. Kedua, pindahkan akun dalam kelompok kecil, dan dahulukan akun besar secara terpisah. Kalau satu sesi berisi puluhan akun lalu gagal, log-nya lebih panjang dan sulit dibaca. Akun besar dengan database besar juga lebih rawan timeout. Ketiga, simpan log sesi sebelum dibersihkan. Salin direktori sesi yang gagal ke lokasi lain. Kalau masalahnya perlu dieskalasi, log itu bukti paling berguna untuk tim berikutnya. Keempat, pisahkan migrasi dari cutover. Turunkan TTL DNS beberapa waktu sebelum migrasi, verifikasi hasil restore lewat file hosts, baru ganti record. Dengan begitu, migrasi yang macet tidak pernah berubah jadi website down. Intinya, saat Transfer Tool berhenti di tengah jalan, jangan langsung mengulang dari awal. Ambil session ID, buka log per item di server tujuan, cari error pertama, lalu masukkan ke salah satu kategori: konflik akun atau domain, database, disk atau quota, atau koneksi. Setelah penyebabnya jelas, perbaikannya biasanya hanya satu langkah. Bagian yang sering terlewat justru membaca log-nya.