ย้ายเซิร์ฟเวอร์ Virtualmin: แก้ข้อผิดพลาดและขีดจำกัด

บทนำ

การย้ายจาก VPS เครื่องหนึ่งไปอีกเครื่องหนึ่งที่มี Virtualmin โดเมน WordPress 10 โดเมนขึ้นไปฟังดูตรงไปตรงมาในทางทฤษฎี—แบ็กอัปบนเซิร์ฟเวอร์เดิม กู้คืนบนเครื่องใหม่ เป็นอันจบ แต่ในความเป็นจริงมันเต็มไปด้วยกับดักของขีดจำกัดระบบที่ซ่อนอยู่ ข้อจำกัดจำนวน file descriptor และปัญหาเนื้อที่ดิสก์ที่ทำให้คุณติดอยู่ได้หลายชั่วโมง

เมื่อไม่นานมานี้ผมเพิ่งทำงานย้าย Virtualmin ที่ท้าทายจาก Debian 12 VPS ในฝรั่งเศสไปยัง VPS Debian 13 เครื่องใหม่ในเนเธอร์แลนด์ โดยย้ายข้อมูลแบ็กอัปกว่า 4.4GB ครอบคลุมโดเมนกว่า 10 โดเมน ในระหว่างนั้นผมเจอข้อผิดพลาดสำคัญทุกแบบที่ผู้ดูแล Virtualmin ต้องเจอ—และแก้ไขได้หมด บทความนี้บันทึกปัญหาและวิธีแก้ไว้อย่างละเอียด เพื่อให้คุณไม่ต้องเรียนรู้แบบเจ็บตัว

ไม่ว่าคุณจะอัปเกรดผู้ให้บริการ VPS ขยายระบบแนวนอน หรือกู้ระบบจากเซิร์ฟเวอร์ที่ล่ม คู่มือนี้จะพาคุณไล่ดูข้อผิดพลาดจริงและวิธีแก้

---

ตอนที่ 1: วางแผนและเตรียมตัวก่อนย้าย

การเลือกสเปก VPS ปลายทาง

ก่อนจะแตะอะไรบนเซิร์ฟเวอร์ปัจจุบัน ตรวจสอบให้แน่ใจว่า VPS ใหม่มีทรัพยากรเพียงพอ ข้อผิดพลาดที่พบบ่อยคือคิดว่าเนื้อที่ดิสก์อย่างเดียวก็พอ—ซึ่งไม่ใช่

สเปกขั้นต่ำสำหรับ Virtualmin ที่มีโดเมน 10 โดเมนขึ้นไป:

• เนื้อที่ดิสก์: 100GB (ไม่ใช่ 50GB—เว็บ WordPress ที่มีแบ็กอัปโตเร็ว)
• CPU: 6 คอร์ขึ้นไป (แนะนำ 8 คอร์ขึ้นไปสำหรับโดเมน 10 โดเมนขึ้นไป)
• RAM: ขั้นต่ำ 8GB (15GB ขึ้นไปสำหรับระบบโปรดักชัน)
• Swap: 4GB (เพิ่มหลังติดตั้ง OS หากยังไม่ได้ตั้งค่าไว้ล่วงหน้า)

เซิร์ฟเวอร์ใหม่ควรมี CPU และ RAM เท่ากับหรือมากกว่าเครื่องเดิม และมีเนื้อที่ดิสก์มากกว่า Virtualmin ใช้ CPU และ I/O หนักมากระหว่างการกู้คืน—โปรเซสเซอร์ที่อ่อนจะทำให้การกู้คืนอืดอาด

เช็กลิสต์ก่อนการย้าย

บนเซิร์ฟเวอร์เดิม (48 ชั่วโมงก่อนการย้าย):

1. ลดค่า DNS TTL เหลือ 300 วินาที (5 นาที) เพื่อลดปัญหาแคช:

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

2. สร้างแบ็กอัปใหม่ ด้วยรูปแบบที่ Virtualmin แนะนำ:

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

3. ตรวจสอบความสมบูรณ์ของแบ็กอัป ก่อนโอนข้อมูล:

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

4. จดขนาดฐานข้อมูลของคุณ เพื่อใช้ในการวางแผน:

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. ตรวจหาการตั้งค่าเฉพาะที่คุณปรับเอง ที่อาจไม่ถูกโอนย้ายไปด้วย:
   • เวอร์ชัน PHP ที่กำหนดเอง
   • คอนฟิก NGINX ที่แก้ไข
   • งาน Cron ใน /etc/cron.d/
   • ใบรับรอง SSL ที่กำหนดเอง

---

ตอนที่ 2: ขั้นตอนการย้าย

ขั้นตอนที่ 1: โอนไฟล์แบ็กอัป

การใช้งาน SCP พร้อมเช็กซัม เพื่อตรวจสอบความสมบูรณ์ของไฟล์:

# 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

ถ้าเช็กซัมไม่ตรงกัน ให้หยุดทันที. ไฟล์เสียหายระหว่างการโอน ถ่ายโอนใหม่หรือใช้ rsync พร้อมเช็กซัม:

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

ขั้นตอนที่ 2: ติดตั้ง Virtualmin บนเซิร์ฟเวอร์ใหม่

ใช้ตัวติดตั้งอย่างเป็นทางการของ Virtualmin:

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

สำคัญ: ติดตั้ง OS เวอร์ชันเดียวกัน (หรือใกล้เคียง)—เรื่องนี้สำคัญกว่าที่หลายคนคิด ผมย้ายจาก Debian 12 ไป Debian 13 (ไม่แนะนำ แต่ทำได้) ถ้าเป็นไปได้ให้อยู่เวอร์ชันเมเจอร์เดียวกัน

ขั้นตอนที่ 3: ตั้งค่าระบบก่อนกู้คืน

นี่คือจุดที่การย้ายล้มเหลวมากที่สุด ก่อนจะเริ่มกู้คืน ให้แก้ขีดจำกัดสำคัญสามข้อนี้ก่อน:

วิธีแก้ที่ 1: เพิ่มจำนวน open file descriptor

นี่คือ สาเหตุอันดับ 1 ของข้อผิดพลาด “No space left on device” ระหว่างกู้คืน, แม้เนื้อที่ดิสก์จะเหลือเฟือ

# 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

ทำไมต้อง 65536? ไฟล์ที่เปิดอยู่ ซ็อกเก็ต ท่อ และการเชื่อมต่อฐานข้อมูลแต่ละรายการกิน file descriptor หนึ่งตัว เมื่อมีเว็บ WordPress 10 กว่าเว็บ เมลเซิร์ฟเวอร์ NGINX worker และการเชื่อมต่อ MySQL คุณจะเกิน 1024 ได้ง่าย OVH และผู้ให้บริการรายอื่นตั้งค่าเริ่มต้นแบบอนุรักษ์นิยมเพื่อความปลอดภัย—ค่านี้ตั้งใจให้ปรับเพิ่มตามแอปพลิเคชัน

วิธีแก้ที่ 2: ขยาย /tmp (tmpfs)

ระหว่างกู้คืน Virtualmin จะสร้างดัมป์ MySQL ไว้ใน /tmp/. โดยค่าเริ่มต้น /tmp เป็น tmpfs (ดิสก์แรม) ที่จำกัดไว้ประมาณ 50% ของ RAM ทั้งหมด เมื่อมี RAM 11GB /tmp จะเต็มที่ราว 5.8GB แต่ Virtualmin สร้างไฟล์ชั่วคราว 5-6GB ได้ง่าย ๆ ระหว่างกู้คืน

# 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

วิธีแก้ที่ 3: เพิ่มพื้นที่ Swap

ถ้าการกู้คืนกิน RAM จนหมด ระบบจะตอบสนองไม่ได้ swap 4GB จะเป็นบัฟเฟอร์ความปลอดภัย:

# 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

---

ตอนที่ 3: กระบวนการกู้คืนและข้อผิดพลาดที่พบบ่อย

ข้อผิดพลาดที่ 1: “Checking contents of the backup ..” ค้างนานกว่า 20 นาที

หน้าตาจะเป็นแบบนี้:

Checking contents of the backup ..

[ค้าง 15-30 นาทีโดยไม่มีความคืบหน้า]

สาเหตุที่แท้จริง: นี่ไม่ใช่การค้าง—มันช้าจริง ๆ การตรวจสอบของ Virtualmin ด้วย tar -tzf จะอ่านไฟล์บีบอัดขนาด 4.4GB ทั้งไฟล์ ตรวจเฮดเดอร์ทุกไฟล์ และตรวจความสมบูรณ์ของ tar บน CPU รุ่นเก่า (อย่าง Haswell) อาจใช้เวลา 20 นาทีขึ้นไปสำหรับแบ็กอัป 4GB

วิธีแก้ไข:

1. อย่าตื่นตระหนก ตรวจว่า tar กำลังทำงานอยู่จริงหรือไม่:

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

2. ใช้การกู้คืนผ่าน CLI แทนหน้าเว็บ (ข้ามการหมดเวลาของการตรวจสอบ):

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

กรณี --reuid จะปรับ ID ผู้ใช้/กลุ่มให้อัตโนมัติ—สำคัญมากเมื่อกู้คืนข้ามระบบที่ต่างกัน

ข้อผิดพลาดที่ 2: “/bin/tar: Cannot write: No space left on device”

หน้าตาจะเป็นแบบนี้:

/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

[ข้อผิดพลาดแบบนี้อีกหลายสิบรายการ]

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

จุดที่สับสนคือ: คุณมีเนื้อที่ว่าง 75GB แต่มันกลับบอกว่า “No space left on device.”

สาเหตุที่เป็นไปได้ (เรียงตามความเป็นไปได้):

1. ชนขีดจำกัด file descriptor (พบบ่อยที่สุด)
   • อาการ: ข้อผิดพลาดเกิดหลังกู้คืนไปได้ 5-10 นาที ไม่ใช่ตั้งแต่เริ่ม
   • วิธีแก้: ulimit -n 65536 (อธิบายไว้ข้างต้นแล้ว)
2. /tmp เต็ม (พบบ่อยเป็นอันดับสอง)
   • อาการ: ข้อผิดพลาดอ้างถึง MySQL หรือไฟล์ชั่วคราว
   • ตรวจสอบ: df -h /tmp ระหว่างกู้คืน—สังเกตว่ามันเต็มถึง 100%
   • วิธีแก้: mount -o remount,size=8G /tmp (อธิบายไว้ข้างต้นแล้ว)
3. เนื้อที่ดิสก์จริงหมด (พบน้อยกว่าแต่เกิดขึ้นได้)
   • ตรวจสอบ: df -h / แสดงเนื้อที่ว่าง <5GB
   • วิธีแก้ไข:

# 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 หมด (พบได้น้อย)
   • ตรวจสอบ: df -i / แสดงค่า iUsed >90%
   • สาเหตุ: ระบบไฟล์ถูกสร้างโดยมี inode น้อยเกินไป
   • วิธีแก้ไข: ฟอร์แมตระบบไฟล์ใหม่ให้มี inode มากขึ้น (ข้อมูลจะหาย)

วิธีวินิจฉัยระหว่างกู้คืน:

เปิดเทอร์มินัลที่สองแล้วเฝ้าดูแบบเรียลไทม์:

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

คำสั่งนี้แสดงให้เห็นชัดว่าคุณชนขีดจำกัดเมื่อไรและที่ไหน

ข้อผิดพลาดที่ 3: NGINX ไม่ยอมเริ่มทำงานหลังกู้คืน

ข้อความข้อผิดพลาด:

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

สาเหตุที่แท้จริง: การกู้คืนล้มเหลวบางส่วน หรือไฟล์บางไฟล์ไม่ได้ถูกโอนมาอย่างถูกต้อง คอนฟิก NGINX อ้างถึงไฟล์ที่ไม่มีอยู่

วิธีแก้ไข:

1. สร้างไฟล์ที่ขาดไป:

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

2. ทดสอบคอนฟิก NGINX:

nginx -t

3. เริ่ม NGINX:

systemctl start nginx
systemctl status nginx

ถ้าไฟล์นั้นต้องมีเนื้อหาจริง ให้ดูจากเซิร์ฟเวอร์เดิม:

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

---

ตอนที่ 4: วิธีแก้ขั้นสูงและการปรับประสิทธิภาพ

กู้คืนทีละโดเมน (วิธีที่ปลอดภัยที่สุด)

ถ้าการกู้คืนทั้งหมดยังล้มเหลวแม้แก้ไขแล้ว ให้กู้คืนแบบเลือกเฉพาะ:

# 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

วิธีนี้ช่วยแยกว่ามีปัญหาที่โดเมนไหน ถ้าตัวหนึ่งกู้คืนสำเร็จ รูปแบบเดียวกันก็ใช้ได้กับตัวอื่น

ข้อควรพิจารณาในการย้ายจาก Debian 12 ไป Debian 13

ผมย้ายจาก Debian 12 ไป Debian 13 โดยทั่วไปเข้ากันได้ แต่ควรระวัง:

1. ความต่างของเวอร์ชัน PHP: Debian 12 อาจมี PHP 8.1 ส่วน Debian 13 มี 8.3
   • ตรวจสอบ: php -v บนทั้งสองเซิร์ฟเวอร์
   • ปัญหา: ปัญหาความเข้ากันได้ที่พบได้น้อยกับส่วนขยาย PHP รุ่นเก่า
   • วิธีแก้: บังคับใช้ PHP เวอร์ชันเก่า: virtualmin modify-web --domain example.com --php-version 8.1
2. ไวยากรณ์คอนฟิก NGINX/Apache: โดยทั่วไปเข้ากันได้ แต่ควรทดสอบหลังกู้คืน
   • ทดสอบ: nginx -t และ apache2ctl configtest
3. ความเข้ากันได้ของ MySQL/MariaDB: โดยทั่วไปรองรับเวอร์ชันใหม่กว่าได้
   • ตรวจสอบ: mysql --version บนทั้งสองเซิร์ฟเวอร์
   • ความต่างของรูปแบบดัมป์: พบได้น้อย แต่ Debian รุ่นใหม่กว่าอาจมี SQL mode ที่เข้มงวดกว่า
4. ความเข้ากันได้ของใบรับรอง SSL: ไม่พบปัญหาระหว่างเวอร์ชัน Debian แต่ควรตรวจสอบ:

certbot certificates  # Check Let's Encrypt certs

---

ตอนที่ 5: การตรวจสอบหลังการย้าย

การตรวจสอบสำคัญก่อนเปิดใช้งานจริง

เมื่อกู้คืนเสร็จ ให้ตรวจสอบว่าทุกอย่างทำงานได้:

# 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

อัปเดตเรกคอร์ด DNS

เมื่อทุกโดเมนกู้คืนสำเร็จ:

1. อัปเดตเนมเซิร์ฟเวอร์ที่ผู้จดทะเบียนโดเมน ให้ชี้ไปที่เซิร์ฟเวอร์ใหม่
2. เฝ้าดูการนับถอยหลังของ TTL (ควรเป็น 5 นาทีเมื่อลด TTL แล้ว)
3. ทดสอบจากหลายตำแหน่ง:

nslookup yourdomain.com
dig yourdomain.com +short

4. คืนค่า TTL ของ DNS ให้เป็นปกติ หลัง 24-48 ชั่วโมง:

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

---

ตอนที่ 6: ข้อมูลอ้างอิงขีดจำกัดของระบบ

สำหรับอ้างอิงในอนาคต นี่คือขีดจำกัดระบบทั้งหมดที่ตรวจระหว่างการย้ายครั้งนี้:

# 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

---

สรุปสาระสำคัญ

1. OVH (และผู้ให้บริการส่วนใหญ่) ตั้งค่าเริ่มต้นแบบอนุรักษ์นิยม คุณต้องเพิ่มขีดจำกัด file descriptor ก่อนกู้คืนแบ็กอัป Virtualmin
2. ศัตรูตัวจริงคือขีดจำกัดของระบบ ไม่ใช่เนื้อที่ดิสก์ แม้มีเนื้อที่ว่าง 75GB คุณก็ยังเจอ “No space left on device” ถ้า /tmp เต็มหรือ file descriptor ถูกใช้จนหมด
3. เพิ่ม /tmp ขนาดก่อนกู้คืน Virtualmin สร้างไฟล์ชั่วคราว 5-6GB ระหว่างกู้คืนแบ็กอัป พื้นที่ tmpfs ที่ตั้งไว้โดยค่าเริ่มต้นไม่พอ
4. ใช้การกู้คืนผ่าน CLI ไม่ใช่หน้าเว็บ หน้าเว็บมีปัญหาหมดเวลากับแบ็กอัปขนาดใหญ่ การกู้คืนผ่านบรรทัดคำสั่งเชื่อถือได้กว่าและแสดงความคืบหน้าจริง
5. การย้ายจาก Debian 12 ไป Debian 13 ทำได้ แต่เวอร์ชันเดียวกันปลอดภัยกว่า ความต่างของเวอร์ชันรองแทบไม่ก่อปัญหา แต่ถ้าเป็นไปได้ให้อยู่ในเมเจอร์เวอร์ชันเดียวกัน
6. ตรวจสอบความสมบูรณ์ของแบ็กอัปก่อนโอน ใช้เช็กซัม SHA256 เพื่อยืนยันว่าไฟล์แบ็กอัปไม่เสียหายระหว่างการโอน
7. การวางแผนก่อนย้ายเซิร์ฟเวอร์ช่วยประหยัดเวลาได้หลายชั่วโมง การลด TTL ของ DNS การตรวจสอบขนาดฐานข้อมูล และการเตรียมเซิร์ฟเวอร์ปลายทางช่วยป้องกันปัญหาได้เกือบทั้งหมด

---

บทสรุป

การย้าย Virtualmin ไม่ใช่เรื่องยาก—แค่ต้องพิถีพิถันหน่อย ความล้มเหลวส่วนใหญ่ไม่ได้เกิดจากตัว Virtualmin เอง แต่เกิดจากขีดจำกัดของระบบที่ซ่อนอยู่ซึ่งผู้ให้บริการโฮสติ้งกำหนดไว้ เมื่อคุณเข้าใจข้อจำกัดเหล่านี้และนำวิธีแก้ที่บันทึกไว้ในบทความนี้ไปใช้ คุณก็ย้ายเว็บไซต์ WordPress 10+ แห่งข้ามเซิร์ฟเวอร์ได้อย่างมั่นคง

ข้อผิดพลาดเฉพาะที่ผมพบ (ขีดจำกัดจำนวน file descriptor, /tmp การใช้จนหมด ขาด snippet ของ NGINX) ล้วนเกิดซ้ำได้และพบได้บ่อย หากคุณเจอข้อใดข้อหนึ่ง ให้กลับมาที่คู่มือนี้—คุณจะพบวิธีแก้ที่ตรงจุด

ขอให้การย้ายเซิร์ฟเวอร์ของคุณราบรื่น ขอให้แบ็กอัปกู้คืนได้อย่างรวดเร็ว และโดเมนของคุณกลับมาออนไลน์ได้โดยไม่มีเรื่องวุ่นวาย

---

ประวัติผู้เขียน

คู่มือนี้บันทึกการย้าย Virtualmin ในสภาพการใช้งานจริงที่เสร็จสิ้นในเดือนกุมภาพันธ์ 2026 โดยย้ายโดเมนโปรดักชัน 10+ แห่งจาก VPS Debian 12 (ฝรั่งเศส) ไปยัง VPS Debian 13 (เนเธอร์แลนด์) วิธีแก้เหล่านี้ผ่านการทดสอบหนักและตรวจสอบหน้างานมาแล้ว