استعدنا حزمة Duplicator فعلية داخل بيئة محلية معزولة حتى نتأكد أن النسخة قابلة للاستخدام قبل أي تغيير في الموقع الحي. لم نستخدم قاعدة مشروع GZ تقنية، ولم نكتب فوق ملفات ووردبريس الجديدة. التجربة كشفت أيضًا مشكلة عملية: فحص Duplicator نجح في السجل، لكن واجهته بقيت معلقة على خادم PHP أحادي الطلب، فانتقلنا إلى Apache ثم أكملنا الاستعادة اليدوية من الحزمة نفسها.
العزل قبل تشغيل installer.php
أنشأنا مجلدًا لا يخدم الموقع الجديد، وقاعدة باسم gzkhabar_restore_test. قبل المتابعة تحققنا أن القاعدة فارغة وأن اسمها لا يطابق gzkhabar_local. خيار Empty Database داخل Duplicator قادر على حذف جداول القاعدة التي تدخلها، لذلك الخطأ هنا أخطر من خطأ في عنوان المقال.
ما الذي حدث أثناء الفحص؟
تعرف المثبّت على الحزمة، وأظهر السجل نجاح الاتصال والصلاحيات وحجم القرص. ظهرت تحذيرات توافق لا تمنعنا من قراءة النسخة، منها اختلاف PHP ومحارف في قاعدة المصدر. على خادم PHP البسيط اكتمل الفحص في الخلفية لكن المتصفح لم يتلق النتيجة؛ لأنه خادم تطوير يعالج طلبًا واحدًا. أعدنا التجربة على Apache متعدد الطلبات بدل افتراض أن الحزمة تالفة.
مسار الاستعادة الذي تحققنا منه
- وضعنا Archive وinstaller.php وحدهما في مجلد وجهة معزول.
- ربطنا المثبّت بقاعدة الاختبار على
127.0.0.1:3308. - حفظنا سجل التحقق، ثم فككنا الحزمة داخل المجلد نفسه عندما تعطلت الواجهة.
- استوردنا ملف SQL المستخرج إلى القاعدة المنفصلة؛ ظهر 19 جدولًا.
- ضبطنا عنواني home وsiteurl على العنوان المحلي، وجعلنا
blog_public=0. - عطّلنا إضافات النسخة القديمة في قاعدة الاختبار عندما سببت بطئًا، ثم فتحنا الصفحة وصفحة الدخول.
متى نتوقف؟
نتوقف إذا كانت قاعدة الوجهة غير فارغة ولم نعرف محتواها، أو إذا كان اسم القاعدة قريبًا من قاعدة الموقع الحي، أو إذا لم توجد نسخة ثانية من Archive. لا ننفذ استعادة تجريبية داخل public_html لمجرد أن الرابط أسهل.