النسخ الاحتياطي لـ WordPress على Storage Server: دليل مع WPvivid

النسخة الاحتياطية الموجودة على الخادم نفسه الذي يحمل الموقع ليست نسخة احتياطية. فإذا مُحي القرص أو استُولي على الوصول أو شُفّرت المنصة، ذهبت معها. ولا تكون النسخة تأميناً حقيقياً إلا إذا كانت على مساحة منفصلة.

يعرض هذا الدليل أسرع طريق إلى هناك: إضافة مجانية تنسخ WordPress عبر SFTP إلى Storage Server، مع جدول زمني وقاعدة احتفاظ. والإعداد ينتهي في ربع ساعة.

لماذا WPvivid

الخيارات ضيّقة بشكل مفاجئ عند نقطة واحدة. والنقطة التي يتوقف عليها الأمر هي نقل مشفّر في الإصدار المجاني:

ينقل FTP البسيط بيانات الدخول والمحتويات دون تشفير. وهذا ليس فكرة جيدة لنسخة احتياطية تحتوي قاعدة البيانات كاملة مع جدول المستخدمين. وبذلك يكون WPvivid الخيار البديهي، فله أكثر من 900,000 تثبيت نشط وآخر تحديث له كان في سبتمبر 2026.

الخطوة 1: إنشاء حساب فرعي على المساحة

أنشئوا في منطقة العملاء ضمن Storage Server الخاص بكم حساباً فرعياً مخصصاً للنسخ الاحتياطي، بمجلد بداية /backup/wordpress. وهذا أهم مما يبدو: فبيانات الدخول تصل مباشرة إلى قاعدة بيانات WordPress، ومن يجدها هناك لا ينبغي أن يبلغ بها شيئاً غير هذا المجلد وحده.

وتحقّقوا في الخطوة نفسها في «إعدادات الوصول» من زرّي تبديل:

• SSH / SFTP / SCP / rsync يجب أن يكون مفعّلاً.
• الوصول الخارجي يجب أن يكون مشغّلاً، وإلا لن يصل خادم الويب لديكم إلى المساحة عبر الإنترنت.

وعند الخوادم المطلوبة حديثاً يكون الاثنان مفعّلين. سجّلوا اسم المضيف واسم المستخدم، وتستخدم الأمثلة هنا:

الخطوة 2: فحص إمكانية الوصول قبل إعداد أي شيء

هذا يوفّر بحثاً كثيراً لاحقاً. إذا كان لديكم وصول إلى سطر الأوامر على خادم الويب:

timeout 5 bash -c '</dev/tcp/u123456.storage.kernelhost.net/23' && echo "المنفذ 23 متاح"

ودون وصول إلى سطر الأوامر، ضعوا ملفاً باسم pruefen.php في مجلد الويب، ونادوه مرة واحدة ثم امحوه بعد ذلك:

<?php
$f = @fsockopen('u123456.storage.kernelhost.net', 23, $e, $t, 5);
echo $f ? 'المنفذ 23 متاح' : 'لا يوجد اتصال: ' . $t;

إذا لم يتم الاتصال، فمزوّد الاستضافة لديكم يحجب الاتصالات الصادرة على هذا المنفذ. وهذا ليس نادراً على الاستضافة المشتركة. وعندها يبقى إما سؤال المزوّد أو الطريق عبر WebDAV الذي يعمل على المنفذ 443.

الخطوة 3: تثبيت الإضافة وإدخال الهدف

في لوحة WordPress ضمن الإضافات، إضافة جديدة، ابحثوا عن WPvivid Backup & Migration وثبّتوه وفعّلوه. بعد ذلك يظهر في القائمة الجانبية عنصر WPvivid Backup.

ومن هناك إلى تبويب Remote Storage واختاروا SFTP. وتملؤون الحقول كما يلي:

وبالزر Test and Add تفحص الإضافة الاتصال قبل أن تحفظه. وإذا فشل ذلك، فالسبب في تسع حالات من عشر إما منفذ خطأ أو وصول خارجي مُغلق.

الخطوة 4: أول نسخة احتياطية يدوياً

في تبويب Backup & Restore تختارون Database + Files (WordPress Files)، وكهدف Send backup to remote storage مع السطر الذي أنشأتموه قبل قليل. ثم Backup Now.

ويستغرق التشغيل الأول دقائق عدة حسب الحجم. واتركوا نافذة المتصفح مفتوحة أثناء ذلك، فالإضافة تدير التقدّم عبر نداءات متكررة.

الخطوة 5: الجدول الزمني والاحتفاظ

في تبويب Schedule تفعّلون الجدول الزمني. وقد أثبت نفسه ما يلي:

اجعلوا الوقت في ساعات الليل عند جمهوركم الرئيسي. وتضبطون الاحتفاظ ضمن Settings، وهناك أيضاً زر التبديل الذي يحدد ما إذا كانت النسخ القديمة تُمحى من المساحة البعيدة كذلك. شغّلوه، وإلا امتلأت المساحة مع الوقت.

وانتبهوا: لقطات Storage Server مستوى إضافي وتعمل بشكل مستقل عن ذلك. وحسب التعرفة تتوفر 10 أو 20 أو 30 أو 40 لقطة يدوية، ومثلها تلقائية.

الخطوة 6: التحقق من أن النسخة الاحتياطية تنفع

هذه الخطوة هي الأكثر تخطّياً وهي الأهم. انظروا ما يقع فعلاً على المساحة:

sftp -P 23 u123456-sub3@u123456.storage.kernelhost.net
sftp> ls -l
sftp> bye

وانتبهوا إلى أمرين: يجب أن يكون حجم الملف معقولاً، ويجب أن يوجد أرشيف لقاعدة البيانات وأرشيف للملفات معاً. فأرشيف من بضعة كيلوبايت فشل، لا نجاح.

ثم الاختبار الحقيقي: أعيدوا النسخة مرة واحدة على تثبيت تجريبي. فنسخة احتياطية لم تُختبر قط هي تخمين.

الاستعادة، والمطبّ فيها

في الإصدار المجاني لا يمكن إرجاع نسخة موجودة على المساحة البعيدة مباشرة، فاستعادة النسخ البعيدة تنتمي إلى الإصدار المدفوع. والطريق المجاني يعمل مع ذلك ولا يستغرق غير دقائق قليلة أكثر:

1. نزّلوا الأرشيف من المساحة عبر SFTP.
2. افتحوا في الإضافة ضمن Backup & Restore قسم Upload وارفعوا الأرشيف.
3. تظهر النسخة المرفوعة في القائمة ويمكن استعادتها من هناك.

واحسبوا هذا الطريق غير المباشر في خطة الطوارئ لديكم. فمن يكتشف عند وقوع المشكلة أول مرة أن هناك تنزيلاً في الطريق، يخسر وقتاً بلا داعٍ.

حيث ينتهي هذا الطريق

كل إضافة نسخ احتياطي تعمل داخل PHP، وتصطدم بذلك بحدود الوقت والذاكرة. وابتداءً من بضعة غيغابايت من الحجم الكلي يصبح الأمر ثقيلاً، ومع مكتبات وسائط كبيرة جداً يتوقف التشغيل في مرحلة ما.

وعندها يكون الطريق الأفضل rsync أو BorgBackup، كلاهما من جدول زمني على الخادم مباشرة وكلاهما متاح على المساحة بشكل أصلي:

rsync -az --delete -e "ssh -p 23" \
      /var/www/example.com/ \
      u123456-sub3@u123456.storage.kernelhost.net:/dateien/

وهذا ينقل التغييرات وحدها ولا يعرف حدود PHP. غير أنه يفترض خادماً خاصاً مع وصول إلى سطر الأوامر. والمزيد عن هذا الطريق في استخدام Storage Server لموقعكم الخاص.

وأي أجزاء أخرى من WordPress يمكن نقلها إلى المساحة، أي مكتبة الوسائط والتنزيلات، وأين تقع حدود ذلك، هذا موضوع استخدام Storage Server مع WordPress.

أكثر أربعة أخطاء شيوعاً

• المنفذ 22 بدل 23. تقترح الإضافة 22، أما مساحتنا فتسمع على 23.
• الوصول الخارجي مُغلق. وعندها ينجح الاختبار من منطقة العملاء، لكنه لا ينجح من خادم الويب.
• الحساب الرئيسي بدل الحساب الفرعي. فبيانات الدخول تقع بعد ذلك في قاعدة بيانات الموقع. ومع الحساب الرئيسي يتعلق بها كل شيء.
• النسخ القديمة لا تُمحى أبداً. فبدون قاعدة احتفاظ مشغّلة للمساحة البعيدة تمتلئ المساحة، وفي مرحلة ما يفشل النسخ بصمت.

أي تعرفة تناسب

لنسخ موقع WordPress واحد يكفي Storage-1 بسعة ⁦1 TB⁩ مقابل ⁦9.99 EUR⁩ مدة طويلة جداً. وللتصوّر: موقع متوسط بحجم كلي ⁦5 GB⁩ يشغل مع عشر نسخ محفوظة نحو ⁦50 GB⁩، أي خمسة بالمئة من التعرفة.

وتقع جميع خوادم Storage Server في ألمانيا، وتسمح بما يصل إلى 100 حساب فرعي، وتتحدث إلى جانب SFTP أيضاً SMB وWebDAV وrsync وBorgBackup، وتأتي دون رسوم إعداد. والحساب بنظام PrePaid دون حد أدنى لمدة الالتزام، فتستطيعون البدء صغيراً والنمو عندما تُضاف مواقع أخرى.