Panduan lengkap migrasi server Virtualmin: atasi error dan batas

Pendahuluan

Memindahkan dari satu VPS ke VPS lain dengan Virtualmin menjalankan 10+ domain WordPress terdengar sederhana secara teori—backup di server lama, restore di server baru, selesai. Kenyataannya, ini ladang ranjau batas sistem tersembunyi, kendala file descriptor, dan masalah ruang disk yang bisa membuatmu tertahan berjam-jam.

Saya baru saja menyelesaikan migrasi Virtualmin yang menantang dari Debian 12 VPS di Prancis ke VPS Debian 13 yang baru di Belanda, memindahkan lebih dari 4,4GB data backup di 10+ domain. Selama proses ini, saya menemui setiap error besar yang dihadapi administrator Virtualmin—dan menyelesaikannya semua. Artikel ini mendokumentasikan masalah dan solusi persisnya supaya kamu tidak perlu mempelajarinya dengan cara yang sulit.

Baik kamu sedang berganti penyedia VPS, melakukan scaling horizontal, atau memulihkan dari server yang gagal, panduan ini akan menuntunmu melewati error nyata dan cara memperbaikinya.

---

Bagian 1: Perencanaan dan persiapan sebelum migrasi

Memilih spesifikasi VPS tujuan

Sebelum mengubah apa pun di server saat ini, pastikan VPS baru punya sumber daya yang memadai. Kesalahan umum adalah menganggap hanya ruang disk yang penting—padahal bukan.

Spesifikasi minimum untuk Virtualmin dengan 10+ domain:

• Ruang disk: 100GB (bukan 50GB—situs WordPress dengan backup cepat membesar)
• CPU: 6+ core (8+ core disarankan untuk 10+ domain)
• RAM: Minimal 8GB (15GB+ untuk produksi)
• Swap: 4GB (ditambahkan setelah instalasi OS jika belum dikonfigurasi)

Server baru sebaiknya menyamai atau melebihi server lama dalam CPU dan RAM, dengan ruang disk lebih besar. Virtualmin sangat intensif CPU dan I/O saat restore—prosesor lemah akan membuat restore merayap.

Daftar periksa sebelum migrasi

Di server lama (48 jam sebelum migrasi):

1. Turunkan TTL DNS ke 300 detik (5 menit) untuk meminimalkan masalah cache:

virtualmin modify-dns --all-domains --ttl 300

2. Buat backup baru dengan format yang disarankan Virtualmin:

mkdir /backup
virtualmin backup-domain \
  --dest /backup/ \
  --all-domains \
  --all-features \
  --newformat

3. Verifikasi integritas backup sebelum mentransfer:

tar -tzf /backup/backup_*.tar.gz > /dev/null && echo "Backup OK" || echo "Backup corrupted"

4. Catat ukuran database untuk perencanaan:

mysql -e "SELECT table_schema AS 'Database', ROUND(SUM(data_length+index_length)/1024/1024,2) AS 'Size_MB' FROM information_schema.TABLES GROUP BY table_schema;"

5. Periksa konfigurasi khusus yang mungkin tidak ikut berpindah:
   • Versi PHP khusus
   • Konfigurasi NGINX yang diubah
   • Cron job di /etc/cron.d/
   • Sertifikat SSL khusus

---

Bagian 2: Proses migrasi

Langkah 1: Transfer berkas backup

Gunakan SCP dengan checksum untuk memverifikasi integritas berkas:

# On old server, generate checksum
sha256sum /backup/backup_*.tar.gz > /backup/backup.sha256

# Transfer backup and checksum
scp /backup/backup_*.tar.gz [email protected]:/Files/
scp /backup/backup.sha256 [email protected]:/Files/

# On new server, verify
cd /Files/
sha256sum -c backup.sha256

Jika checksum tidak cocok, berhenti segera. Berkas rusak saat transfer. Transfer ulang atau gunakan rsync dengan checksum:

rsync -avz --checksum /backup/backup_*.tar.gz [email protected]:/Files/

Langkah 2: Pasang Virtualmin di server baru

Gunakan installer resmi Virtualmin:

curl https://software.virtualmin.com/gpl/scripts/virtualmin-install.sh | sh

Penting: Pasang versi OS yang sama (atau mendekati)—ini lebih penting daripada yang orang kira. Saya migrasi dari Debian 12 ke Debian 13 (tidak disarankan, tapi bisa dilakukan). Tetap di versi mayor yang sama jika memungkinkan.

Langkah 3: Konfigurasi sistem sebelum restore

Di sinilah sebagian besar migrasi gagal. Sebelum menyentuh restore, perbaiki tiga batas penting ini:

Perbaikan 1: Naikkan open file descriptor

Ini adalah penyebab #1 error “No space left on device” saat restore, bahkan ketika ruang disk berlimpah.

# Check current limit
ulimit -n
# Likely shows: 1024 (too low for Virtualmin)

# Increase for current session
ulimit -n 65536

# Verify
ulimit -n
# Should show: 65536

# Make permanent
cat >> /etc/security/limits.conf << EOF
* soft nofile 65536
* hard nofile 65536
root soft nofile 65536
root hard nofile 65536
EOF

Mengapa 65536? Setiap berkas terbuka, socket, pipe, dan koneksi database memakai satu file descriptor. Dengan 10+ situs WordPress, server mail, worker NGINX, dan koneksi MySQL, kamu mudah melewati 1024. OVH dan penyedia lain memakai default konservatif ini demi keamanan—nilainya memang dimaksudkan untuk dinaikkan per aplikasi.

Perbaikan 2: Perbesar /tmp (tmpfs)

Saat restore, Virtualmin membuat dump MySQL di /tmp/. Secara default, /tmp adalah tmpfs (RAM disk) yang dibatasi ~50% dari total RAM. Dengan RAM 11GB, /tmp maksimalnya ~5,8GB. Tapi Virtualmin bisa dengan mudah membuat 5-6GB berkas sementara saat restore.

# Check current /tmp size
df -h /tmp

# Dynamically resize without unmounting
mount -o remount,size=8G /tmp

# Verify
df -h /tmp

# Make permanent
echo "tmpfs /tmp tmpfs size=8G,mode=1777 0 0" >> /etc/fstab

Perbaikan 3: Tambah ruang swap

Jika restore menghabiskan semua RAM, sistem jadi tidak responsif. Swap 4GB memberi penyangga pengaman:

# Create 4GB swap file
fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# Make permanent
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# Verify
swapon --show

---

Bagian 3: Proses restore dan error umum

Error 1: “Checking contents of the backup ..” macet 20+ menit

Tampilannya seperti ini:

Checking contents of the backup ..

[macet 15-30 menit tanpa kemajuan]

Akar masalah: Ini bukan macet—memang lambat. Virtualmin menjalankan tar -tzf untuk verifikasi yang membaca seluruh arsip terkompresi 4,4GB, memeriksa setiap header berkas, dan mengecek integritas tar. Di CPU lama (seperti Haswell), ini bisa memakan 20+ menit untuk backup 4GB.

Solusi:

1. Jangan panik. Cek apakah tar benar-benar berjalan:

ps aux | grep tar
iostat -x 1  # Check disk activity

2. Gunakan restore CLI, bukan web UI (melewati timeout verifikasi):

screen -S restore
virtualmin restore-domain \
  --source /Files/backup_*.tar.gz \
  --all-domains \
  --all-features \
  --reuid

The --reuid flag ini menyesuaikan ID user/grup secara otomatis—penting saat restore antar sistem berbeda.

Error 2: “/bin/tar: Cannot write: No space left on device”

Tampilannya seperti ini:

/bin/tar: ./seo.grahammiranda.com_mail_users: Cannot write: No space left on device
/bin/tar: ./esim.grahammiranda.com_virtualmin_ssl_key: Cannot write: No space left on device

[puluhan error serupa lainnya]

/bin/tar: Exiting with failure status due to previous errors

Bagian yang membingungkan: Kamu punya 75GB kosong, tapi pesannya “No space left on device.”

Penyebab utama (berdasarkan urutan kemungkinan):

1. Batas file descriptor tercapai (paling umum)
   • Gejala: Error muncul 5-10 menit setelah restore berjalan, bukan di awal
   • Perbaikan: ulimit -n 65536 (sudah dibahas di atas)
2. /tmp penuh (paling umum kedua)
   • Gejala: Error menyebut MySQL atau berkas temp
   • Cek: df -h /tmp saat restore—lihat sampai penuh 100%
   • Perbaikan: mount -o remount,size=8G /tmp (sudah dibahas di atas)
3. Ruang disk benar-benar habis (jarang tapi mungkin)
   • Cek: df -h / menunjukkan <5GB kosong
   • Solusi:

# Clean up failed restore
rm -rf /home/*
rm -rf /var/lib/virtualmin/*
rm -rf /tmp/*
rm -rf /extract_test/

# If backup is still in /Files, consider moving it
mv /Files/backup_*.tar.gz /mnt/  # Move to another partition if available

4. Inode habis (jarang)
   • Cek: df -i / menunjukkan >90% iUsed
   • Penyebab: Filesystem dibuat dengan inode terlalu sedikit
   • Solusi: Format ulang filesystem dengan inode lebih banyak (merusak data)

Pendekatan diagnostik saat restore:

Buka terminal kedua dan pantau secara real-time:

watch -n 2 'df -h / && echo "---" && df -h /tmp && echo "---" && du -sh /tmp/* 2>/dev/null | sort -rh | head -5'

Ini menunjukkan persis kapan dan di mana kamu mencapai batas.

Error 3: NGINX tidak mau start setelah restore

Pesan error:

nginx[34392]: [emerg] 34392#34392: open() "/etc/nginx/snippets/block-manager.conf" failed (2: No such file or directory)
nginx: configuration file /etc/nginx/nginx.conf test failed

Akar masalah: Restore gagal sebagian, atau beberapa berkas tidak berpindah dengan benar. Konfigurasi NGINX merujuk berkas yang tidak ada.

Solusi:

1. Buat berkas yang hilang:

mkdir -p /etc/nginx/snippets
touch /etc/nginx/snippets/block-manager.conf

2. Uji konfigurasi NGINX:

nginx -t

3. Jalankan NGINX:

systemctl start nginx
systemctl status nginx

Jika berkas itu butuh isi yang sebenarnya, cek server lama:

scp old-server.com:/etc/nginx/snippets/block-manager.conf /etc/nginx/snippets/

---

Bagian 4: Solusi lanjutan dan optimasi

Restore satu domain per satu kali (cara paling aman)

Jika restore penuh terus gagal meski sudah diperbaiki, lakukan restore secara selektif:

# Clean previous failed attempts
rm -rf /home/*
rm -rf /var/lib/virtualmin/*

# Restore just the main domain first
virtualmin restore-domain \
  --source /Files/backup_*.tar.gz \
  --domain grahammiranda.com \
  --all-features \
  --reuid

Ini memisahkan domain mana yang bermasalah. Jika satu berhasil di-restore, pola itu berlaku untuk yang lain.

Hal yang perlu diperhatikan saat migrasi Debian 12 ke Debian 13

Saya migrasi dari Debian 12 ke Debian 13. Meski umumnya kompatibel, perhatikan:

1. Perbedaan versi PHP: Debian 12 mungkin punya PHP 8.1, Debian 13 punya 8.3
   • Cek: php -v di kedua server
   • Masalah: Masalah kompatibilitas yang jarang dengan ekstensi PHP lama
   • Perbaikan: Paksa versi PHP lama: virtualmin modify-web --domain example.com --php-version 8.1
2. Sintaks konfigurasi NGINX/Apache: Biasanya kompatibel, tapi uji setelah restore
   • Uji: nginx -t dan apache2ctl configtest
3. Kompatibilitas MySQL/MariaDB: Umumnya kompatibel ke depan
   • Cek: mysql --version di kedua server
   • Perbedaan format dump: Jarang, tapi Debian yang lebih baru mungkin punya mode SQL lebih ketat
4. Kompatibilitas sertifikat SSL: Tidak ada masalah antar versi Debian, tapi verifikasi:

certbot certificates  # Check Let's Encrypt certs

---

Bagian 5: Verifikasi setelah migrasi

Pemeriksaan penting sebelum go live

Setelah restore selesai, verifikasi semuanya berjalan:

# 1. List all restored domains
virtualmin list-domains

# 2. Test web connectivity
curl -I https://yourdomain.com

# 3. Check mail functionality
mysql -u root -p'password' -e "SELECT user FROM mysql.user;"

# 4. Verify DNS
dig yourdomain.com @localhost

# 5. Check Virtualmin module
virtualmin test-domain --domain yourdomain.com

# 6. Monitor logs for errors
journalctl -f
tail -f /var/log/nginx/error.log

Perbarui catatan DNS

Setelah semua domain berhasil di-restore:

1. Perbarui nameserver di registrar agar mengarah ke server baru
2. Pantau hitungan mundur TTL (harusnya 5 menit dengan TTL yang diturunkan)
3. Uji dari beberapa lokasi:

nslookup yourdomain.com
dig yourdomain.com +short

4. Kembalikan TTL DNS ke normal setelah 24-48 jam:

virtualmin modify-dns --all-domains --ttl 3600

---

Bagian 6: Referensi batas sistem

Untuk referensi nanti, berikut semua batas sistem yang diperiksa selama migrasi ini:

# User/process limits
ulimit -a                              # All limits
ulimit -n                              # Open files
ulimit -u                              # Max processes
ulimit -v                              # Virtual memory

# System-wide limits
cat /proc/sys/fs/file-max              # System-wide open files
cat /proc/sys/kernel/pid_max           # Max process IDs
cat /proc/sys/vm/max_map_count         # Memory map limit

# Current resource usage
df -h                                  # Disk space
df -i                                  # Inode usage
free -h                                # RAM and swap
ps aux | wc -l                         # Running processes
lsof | wc -l                           # Open file descriptors

# Filesystem specifics
mount | grep /dev/sda1                 # Mount options
quota -s                               # Disk quotas
tune2fs -l /dev/sda1                   # Filesystem properties

---

Poin penting

1. OVH (dan sebagian besar penyedia) memakai default konservatif. Kamu harus menaikkan batas file descriptor sebelum me-restore backup Virtualmin.
2. Musuh sebenarnya adalah batas sistem, bukan ruang disk. Bahkan dengan 75GB kosong, kamu akan mendapat “No space left on device” jika /tmp penuh atau file descriptor habis.
3. Meningkatkan /tmp ukurannya sebelum restore. Virtualmin membuat 5-6GB berkas sementara saat restore backup. Alokasi tmpfs default tidak cukup.
4. Gunakan restore CLI, bukan web UI. Web UI punya masalah timeout pada backup besar. Restore lewat command line lebih andal dan menunjukkan kemajuan sebenarnya.
5. Migrasi Debian 12 ke Debian 13 berhasil, tapi versi yang sama lebih aman. Perbedaan versi minor jarang menimbulkan masalah, tapi tetap di versi mayor yang sama jika memungkinkan.
6. Verifikasi integritas backup sebelum mentransfer. Gunakan checksum SHA256 untuk memastikan berkas backup tidak rusak saat transfer.
7. Perencanaan pra-migrasi menghemat waktu berjam-jam. Menurunkan TTL DNS, memeriksa ukuran basis data, dan menyiapkan server target mencegah sebagian besar masalah.

---

Kesimpulan

Migrasi Virtualmin bukanlah hal sulit—hanya saja rewel. Sebagian besar kegagalan bukan disebabkan oleh Virtualmin itu sendiri, melainkan batas sistem tersembunyi yang ditetapkan penyedia hosting. Dengan memahami batasan ini dan menerapkan perbaikan yang didokumentasikan di sini, kamu dapat memindahkan 10+ situs WordPress antar server dengan andal.

Kesalahan spesifik yang saya alami (batas deskriptor berkas, /tmp kehabisan, potongan NGINX yang hilang) dapat direproduksi dan umum terjadi. Jika kamu menemui salah satunya, kembali ke panduan ini—kamu akan menemukan solusi yang tepat.

Semoga berhasil dengan migrasimu. Semoga cadanganmu pulih dengan cepat dan domainmu online tanpa drama.

---

Bio penulis

Panduan ini mendokumentasikan migrasi Virtualmin di dunia nyata yang diselesaikan pada Februari 2026, memindahkan 10+ domain produksi dari VPS Debian 12 (Prancis) ke VPS Debian 13 (Belanda). Solusinya sudah teruji dan terverifikasi di lapangan.