دليل شامل لترحيل خادم Virtualmin: حل الأخطاء والحدود الشائعة

مقدمة

الترحيل من VPS إلى آخر مع Virtualmin تشغيل أكثر من 10 نطاقات WordPress يبدو بسيطًا في النظرية—نسخة احتياطية على الخادم القديم، واستعادة على الجديد، وانتهى الأمر. في الواقع، هو حقل ألغام من حدود النظام الخفية وقيود واصفات الملفات ومشكلات مساحة القرص التي قد تتركك عالقًا لساعات.

أكملت مؤخرًا ترحيلًا صعبًا لـ 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 (تُضاف بعد تثبيت نظام التشغيل إن لم تكن مُعدّة مسبقًا)

يجب أن يعادل خادمك الجديد خادمك القديم أو يتجاوزه في CPU وRAM، مع مساحة قرص أكبر. Virtualmin كثيف الاستهلاك لـ CPU وعمليات الإدخال/الإخراج أثناء الاستعادة—والمعالج الضعيف سيجعل الاستعادة تزحف.

قائمة تحقق قبل الترحيل

على خادمك القديم (48 ساعة قبل الترحيل):

1. اخفض TTL الخاص بـ DNS إلى 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

مهم: ثبّت نفس إصدار نظام التشغيل (أو قريبًا منه)—وهذا أهم مما يظن الناس. رحّلت من Debian 12 إلى Debian 13 (غير موصى به، لكنه قابل للتنفيذ). التزم بنفس الإصدار الرئيسي إن أمكن.

الخطوة 3: إعداد النظام قبل الاستعادة

هنا تفشل معظم عمليات الترحيل. قبل أن تبدأ الاستعادة، أصلح هذه الحدود الثلاثة الحاسمة:

الإصلاح 1: زيادة واصفات الملفات المفتوحة

هذا هو السبب رقم 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؟ كل ملف مفتوح ومقبس وأنبوب واتصال قاعدة بيانات يستهلك واصف ملف واحدًا. مع أكثر من 10 مواقع WordPress وخوادم بريد وعمال NGINX واتصالات MySQL، تتجاوز 1024 بسهولة. تضبط OVH ومزوّدون آخرون هذه القيمة الافتراضية المتحفظة لأسباب أمنية—ومن المفترض رفعها لكل تطبيق.

الإصلاح 2: تكبير /tmp (tmpfs)

أثناء الاستعادة، ينشئ Virtualmin نسخًا من MySQL في /tmp/. افتراضيًا، /tmp هو tmpfs (قرص في RAM) محدود بنحو 50% من إجمالي RAM. مع 11GB من RAM، /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. على معالجات أقدم (مثل 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 يضبط هذا الخيار تلقائيًا معرّفات المستخدم والمجموعة—وهو أمر حاسم عند الاستعادة عبر أنظمة مختلفة.

الخطأ 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. بلوغ حد واصفات الملفات (الأكثر شيوعًا)
   • العَرَض: تظهر الأخطاء بعد 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. نفاد الـ inodes (نادر)
   • تحقق: df -i / يُظهر >90% iUsed
   • السبب: نظام ملفات أُنشئ بعدد inodes أقل من اللازم
   • الحل: أعد تهيئة نظام الملفات بعدد inodes أكبر (إجراء تدميري)

نهج التشخيص أثناء الاستعادة:

افتح طرفية ثانية وراقب في الوقت الحقيقي:

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 أكثر صرامة
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 (ومعظم المزوّدين) تضبط قيمًا افتراضية متحفظة. يجب أن ترفع حدود واصفات الملفات قبل استعادة نسخ Virtualmin الاحتياطية.
2. حدود النظام هي العدو الحقيقي، وليست مساحة القرص. حتى مع وجود 75GB حرة، ستحصل على “No space left on device” إذا /tmp كان ممتلئًا أو استُنفدت واصفات الملفات.
3. زيادة /tmp الحجم قبل الاستعادة. ينشئ Virtualmin ما بين 5 و6GB من الملفات المؤقتة أثناء استعادة النسخ الاحتياطي. التخصيص الافتراضي لـ tmpfs لا يكفي.
4. استخدم الاستعادة عبر CLI، لا واجهة الويب. تواجه واجهة الويب مشكلات مهلة مع النسخ الاحتياطية الكبيرة. الاستعادة عبر سطر الأوامر أكثر موثوقية وتُظهر التقدم الفعلي.
5. الترحيل من Debian 12 إلى Debian 13 يعمل، لكن البقاء على نفس الإصدار أكثر أمانًا. نادرًا ما تسبب اختلافات الإصدارات الفرعية مشكلات، لكن التزم بنفس الإصدار الرئيسي إن أمكن.
6. تحقق من سلامة النسخة الاحتياطية قبل النقل. استخدم مجاميع تحقق SHA256 لتتأكد من أن ملف النسخة الاحتياطية لم يتلف أثناء النقل.
7. التخطيط قبل الترحيل يوفّر ساعات. تقليل TTL لـ DNS، وفحص أحجام قواعد البيانات، وتجهيز الخادم الهدف يمنع معظم المشكلات.

---

الخاتمة

ترحيل Virtualmin ليس صعبًا—إنه فقط كثير المتطلبات. معظم الإخفاقات لا تعود إلى Virtualmin نفسه، بل إلى حدود نظام خفية يضبطها مزوّدو الاستضافة. بفهم هذه القيود وتطبيق الإصلاحات الموثقة هنا، يمكنك ترحيل أكثر من 10 مواقع WordPress بين الخوادم بموثوقية.

الأخطاء المحددة التي واجهتها (حدود واصفات الملفات، /tmp نفادها، وغياب مقتطفات NGINX) قابلة للتكرار وشائعة. إذا واجهت أيًا منها، فعُد إلى هذا الدليل—ستجد الحل الدقيق.

حظًا موفقًا في الترحيل. لعل نسخك الاحتياطية تُستعاد بسرعة ونطاقاتك تعود للعمل دون مشاكل.

---

نبذة عن الكاتب

يوثّق هذا الليل عملية ترحيل واقعية لـ Virtualmin أُنجزت في فبراير 2026، حيث نُقلت أكثر من 10 نطاقات إنتاجية من VPS يعمل بـ Debian 12 (فرنسا) إلى VPS يعمل بـ Debian 13 (هولندا). الحلول مجرّبة ومتحقّق منها ميدانيًا.