النسخ الاحتياطي لووردبريس: الإضافات وWP-CLI وStaging

ووردبريس يشغّل نسبة هائلة من مواقع الويب، وهذا تحديدًا ما يجعله هدفًا للأعطال: تحديث إضافة يكسر الواجهة، تعارض بين قالب وإضافة يعطب لوحة التحكّم، اختراق يحقن أكوادًا في الملفات، أو خطأ في استعلام قاعدة بيانات يمحو منشورات. هذا الدليل خاصّ بووردبريس تحديدًا — لا نظرية عامّة في النسخ الاحتياطي. إن كنت تبحث عن الأساسيات النظرية (قاعدة 3-2-1، أنواع الوسائط، استراتيجية الاحتفاظ العامّة) فالمرجع هو الدليل العام للنسخ الاحتياطي للموقع؛ هنا نركّز على ما يجعل نسخ ووردبريس مختلفًا: بنيته الخاصّة، أدواته (UpdraftPlus وWP-CLI)، وبيئة الـStaging كحلبة آمنة للنسخ والاستعادة والاختبار.

ما الذي يجعل نسخ ووردبريس مختلفًا؟

كثير من أصحاب المواقع يتعاملون مع ووردبريس وكأنه «مجلّد ملفات» يكفي أرشفته. هذا الفهم ناقص وخطير. ووردبريس تطبيق ديناميكي يفصل الكود والوسائط (على نظام الملفات) عن المحتوى والإعدادات (في قاعدة بيانات MySQL). كل منشور تكتبه، كل إعداد تضبطه، كل تعليق وكل طلب WooCommerce وكل مستخدم — كلّها تعيش في قاعدة البيانات، لا في الملفات. في المقابل، كل صورة رفعتها، كل ملف PDF أرفقته، والقالب والإضافات نفسها — كلّها ملفات. النسخة التي تلتقط نصفًا دون الآخر تعطيك إمّا «هيكلًا فارغًا» أو «محتوى بلا واجهة».

ما يميّز ووردبريس عن موقع ثابت عادي أمور ثلاثة تستحقّ الانتباه. الأول أن قاعدة البيانات هي القلب: حذف جدول wp_posts بالخطأ يمحو كل محتواك حتى لو بقيت كل الملفات سليمة. الثاني أن الملفات والقاعدة يجب أن تكونا متزامنتين؛ نسخة ملفات من اليوم مع نسخة قاعدة بيانات من الأسبوع الماضي تسبّب تعارضات (مراجع لصور غير موجودة، إصدارات إضافات لا تطابق جداولها). الثالث أن عناوين URL مخزّنة مضمّنة داخل قاعدة البيانات (في wp_options وداخل المحتوى المسلسل/serialized)، لذا نقل النسخة إلى نطاق آخر يتطلّب عملية استبدال حذرة لا مجرّد نسخ ولصق.

تشريح موقع ووردبريس: ماذا تنسخ بالضبط؟

الجدول التالي يفصّل مكوّنات ووردبريس وموقع كلٍّ منها وأهمّيته في النسخة. احفظ هذا الجدول جيدًا — فهو خريطة كل ما يلي:

لماذا wp-content هو الكنز الحقيقي؟

من بين كل ما سبق، مجلّد wp-content هو الذي لا يُغفَر فقدانه. ملفات النواة (wp-admin وwp-includes) متطابقة في كل مواقع ووردبريس على الإصدار نفسه — يمكنك تنزيلها مجددًا من wordpress.org في دقائق. لكن wp-content يحوي كل ما هو خاصّ بموقعك: قالبك وتعديلاته، إضافاتك وإعداداتها، وقبل كل شيء مجلّد uploads/ الذي يضمّ سنوات من الصور والوسائط التي لا توجد نسخة منها في أي مكان آخر. لهذا، إن اضطررت للاختيار بسبب ضيق المساحة، فأولويتك المطلقة: قاعدة البيانات أولًا، ثم wp-content/uploads، ثم بقية wp-content. النواة تأتي أخيرًا لأنها قابلة لإعادة التنزيل دائمًا.

نصيحة خبير: راقب حجم wp-content/uploads بمرور الوقت — فهو ينمو باستمرار، وكثير من مهامّ النسخ الفاشلة تنهار لأن المجلّد كبر حتى تجاوز حدود الذاكرة أو مهلة التنفيذ في الإضافة. إن صار ثقيلًا، فهذا مؤشّر قوي على الانتقال من النسخ بالإضافة إلى النسخ بـWP-CLI أو على مستوى الخادم.

طرق نسخ ووردبريس: نظرة عامّة

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

الجدول يقارن الطرق الثلاث الأساسية الخاصّة بووردبريس:

نسخة كاملة مقابل نسخة تزايدية (Incremental)

مفهوم مهمّ يحدّد كفاءة استراتيجيتك. النسخة الكاملة تأخذ كل شيء في كل مرّة؛ بسيطة لكنها ثقيلة على المواقع الكبيرة. النسخة التزايدية تأخذ المتغيّر فقط منذ آخر نسخة؛ أخفّ بكثير وأسرع، لكنها تحتاج نسخة كاملة كأساس وتُعقّد الاستعادة قليلًا.

UpdraftPlus وبعض الإضافات المتقدّمة تدعم التزايدي؛ ومع WP-CLI تحاكيه عبر rsync للملفات (ينقل المتغيّر فقط) مع تصدير قاعدة بيانات كامل (القاعدة عادةً أصغر بكثير من الوسائط فلا مشكلة في نسخها كاملة كل مرّة).

النسخ بالإضافات: UpdraftPlus خطوة بخطوة

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

إعداد UpdraftPlus والجدولة

بعد تثبيت UpdraftPlus وتفعيله، انتقل إلى الإعدادات → UpdraftPlus Backups. الخطوات الجوهرية:

1. من تبويب Settings، اضبط جدول نسخ الملفات (Files backup schedule) وجدول نسخ قاعدة البيانات (Database backup schedule) — يمكن أن يكونا مختلفين (مثلًا الملفات أسبوعيًا والقاعدة يوميًا، لأن القاعدة تتغيّر أكثر).
2. حدّد عدد النسخ المحفوظة (Retention) — مثلًا الاحتفاظ بآخر 14 نسخة. لا تتركه على 1، فقد تحتاج نسخة سابقة لما قبل اختراق اكتُشف متأخّرًا.
3. اختر وجهة التخزين البعيدة (Remote storage) — Google Drive، Dropbox، Amazon S3، أو أي تخزين متوافق مع S3 مثل Cloudflare R2. هذا هو ما يحقّق شرط off-site؛ لا تترك النسخ على الخادم فقط.
4. اضغط Save Changes، ثم صرّح للإضافة بالوصول إلى وجهة التخزين (عبر تدفّق OAuth لخدمات مثل Drive).
5. اضغط Backup Now لأخذ أول نسخة يدوية والتأكّد أن كل شيء يعمل قبل الاعتماد على الجدولة.

نصيحة جوهرية حول الوجهة البعيدة: اضبط وجهة التخزين بحيث تكون صلاحياتها منفصلة عن الموقع. الفكرة أن من يخترق ووردبريس يجب ألّا يستطيع حذف نسخك المخزّنة بعيدًا. خدمات التخزين الكائني (S3/R2) تتيح تفعيل الإصدارات (Versioning) وقفل الكائنات (Object Lock) لمنع الحذف — وهذا يحوّل نسختك البعيدة إلى ملاذ آمن حتى لو سيطر مهاجم على لوحة ووردبريس بالكامل.

الاستعادة عبر UpdraftPlus

الاستعادة من أسهل ما يكون: في تبويب Backup / Restore سترى قائمة بالنسخ السابقة بتواريخها. اضغط Restore بجانب النسخة المطلوبة، ثم اختر المكوّنات التي تريد استعادتها (Plugins، Themes، Uploads، Others، Database)، ودع الإضافة تتولّى فكّ الضغط والاستيراد. للنسخ المخزّنة بعيدًا، تستطيع أيضًا الضغط على Rescan remote storage لتظهر نسخ موجودة في Drive/S3 لكنها ليست محليًا.

العيب الجوهري لكل إضافات النسخ أنها تعمل من داخل ووردبريس: تعتمد على PHP وذاكرته ومهلة تنفيذه. على المواقع الكبيرة قد تتعثّر النسخة أو الاستعادة بانتهاء المهلة (timeout) أو نفاد الذاكرة. والأخطر: إن تعطّل ووردبريس كليًا (بياض الموت، خطأ قاعدة بيانات) فقد لا تستطيع حتى الوصول للإضافة لتستعيد. لهذا لا تجعل الإضافة طبقتك الوحيدة؛ اجعلها طبقة مريحة فوق طبقة WP-CLI أو نسخ الخادم.

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار

النسخ الاحترافي بـ WP-CLI

WP-CLI هو واجهة سطر الأوامر الرسمية لووردبريس، وهو أداة النسخ المفضّلة للتقنيين وأصحاب الـVPS: سريع، دقيق، لا يقيّده PHP الخاصّ بالويب، وقابل للأتمتة بالكامل عبر سكربتات وcron. شرط استخدامه أن يكون لديك وصول SSH للخادم وWP-CLI مثبّتًا. إن كنت جديدًا على الطرفية، فدليل أساسيات SSH للمبتدئين نقطة بداية جيّدة قبل المتابعة هنا.

أوامر WP-CLI الأساسية للنسخ — جدول مرجعي

تصدير قاعدة البيانات

قلب نسخة ووردبريس هو قاعدة بياناتها. الأمر الأساسي بسيط ومباشر:

# تصدير قاعدة البيانات كاملة إلى ملف SQL مع التاريخ في الاسم
wp db export wp-db-$(date +%F).sql

ميزة wp db export على mysqldump المباشر أنه يقرأ بيانات الاتصال تلقائيًا من wp-config.php فلا تحتاج تمرير اسم المستخدم وكلمة المرور يدويًا. للمواقع الكبيرة، اضغط الناتج فورًا لتوفير المساحة والنقل:

# تصدير مضغوط مباشرةً (مناسب للقواعد الكبيرة)
wp db export - | gzip > wp-db-$(date +%F).sql.gz

ولمن يفضّل أو يحتاج mysqldump مباشرةً (مثلًا خارج بيئة ووردبريس)، إليك المكافئ مع قراءة الإعدادات من wp-config.php:

# المكافئ عبر mysqldump مباشرةً
mysqldump -u DB_USER -p'DB_PASSWORD' DB_NAME > wp-db-$(date +%F).sql

# نسخة مضغوطة
mysqldump -u DB_USER -p'DB_PASSWORD' DB_NAME | gzip > wp-db-$(date +%F).sql.gz

أرشفة الملفات

النصف الثاني هو الملفات. أرشف مجلّد الموقع كاملًا — والأهمّ wp-content وwp-config.php — مع استبعاد الكاش والملفات المؤقتة لتقليص الحجم:

# أرشفة ملفات الموقع كاملة مع استبعاد الكاش والملفات المؤقتة
tar -czf wp-files-$(date +%F).tar.gz \
  --exclude='wp-content/cache' \
  --exclude='wp-content/uploads/cache' \
  --exclude='*.log' \
  -C /var/www/html .

إن أردت نسخة مركّزة على ما لا يُسترجَع (الأخفّ والأهمّ)، أرشف wp-content وwp-config.php فقط، وأعِد تنزيل النواة لاحقًا عند الاستعادة:

# نسخة مركّزة: المحتوى الخاصّ + ملف الإعداد فقط
tar -czf wp-content-$(date +%F).tar.gz \
  -C /var/www/html wp-content wp-config.php

سكربت نسخ كامل وجدولته بـ cron

اجمع النصفين في سكربت واحد يأخذ القاعدة والملفات معًا متزامنين، ثم يرفعهما off-site. هذا مثال عملي قابل للتشغيل:

#!/usr/bin/env bash
set -euo pipefail

SITE="/var/www/html"
DEST="/backups/wp"
STAMP=$(date +%F-%H%M)
mkdir -p "$DEST"

# 1) تصدير قاعدة البيانات مضغوطة
wp --path="$SITE" db export - | gzip > "$DEST/db-$STAMP.sql.gz"

# 2) أرشفة الملفات مع استبعاد الكاش
tar -czf "$DEST/files-$STAMP.tar.gz" \
  --exclude='wp-content/cache' --exclude='*.log' \
  -C "$SITE" .

# 3) رفع off-site إلى تخزين متوافق مع S3 (مثل R2) عبر rclone
rclone copy "$DEST" remote:wp-backups/ --include "*-$STAMP.*"

# 4) تنظيف النسخ المحلية الأقدم من 7 أيام
find "$DEST" -type f -mtime +7 -delete

احفظ السكربت (مثلًا /usr/local/bin/wp-backup.sh)، اجعله قابلًا للتنفيذ بـ chmod +x, ثم جدوله عبر cron ليعمل ليلًا في ساعة هادئة:

# افتح محرّر cron
crontab -e

# أضف السطر التالي: نسخة يومية الساعة 3:15 فجرًا مع تسجيل المخرجات
15 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

نصيحة خبير: لا تكتفِ بتشغيل cron ونسيانه. أضف إشعارًا عند الفشل (سطر يرسل بريدًا أو رسالة إن خرج السكربت بخطأ)، وافحص ملف السجلّ /var/log/wp-backup.log دوريًا. الفشل الصامت — أن يتوقّف cron منذ أسابيع وأنت تظنّه يعمل — هو أخطر أنواع فشل النسخ على الإطلاق.

قواعد بيانات ضخمة: حيل التصدير الكبير

حين تتجاوز قاعدة البيانات بضعة جيجابايتات (متاجر WooCommerce نشطة، مواقع عضويات كبيرة)، يصبح التصدير العادي بطيئًا أو يفشل. إليك حيلًا عملية:

لتشخيص ما يثقل قاعدتك قبل النسخ، استخدم:

# عرض حجم كل جدول لكشف الجداول المنتفخة
wp db size --tables --human-readable

# تنظيف العناصر المؤقتة وتحسين الجداول قبل التصدير
wp transient delete --all
wp db optimize

تنظيف القاعدة قبل النسخ ليس ترفًا — جداول wp_options المنتفخة بـtransients منتهية، أو سجلّات إضافات متروكة، قد تضاعف حجم نسختك بلا داعٍ. لمزيد من العمق في هذا الجانب، راجع دليل تحسين قاعدة بيانات ووردبريس إن كان موقعك يعاني بطئًا متراكمًا.

النسخ والاستعادة عبر بيئة Staging

بيئة Staging هي نسخة طبق الأصل من موقعك الحيّ تعيش في مكان منفصل (نطاق فرعي أو مجلّد أو خادم آخر)، وتُستخدم للتجربة دون أن تمسّ الموقع الحيّ. كثير من المضيفين المُدارين لووردبريس يقدّمون Staging بضغطة زر، ويمكن إنشاؤها أيضًا عبر إضافات (مثل Duplicator أو WP Staging). دورها في استراتيجية النسخ محوري لسببين: اختبار الاستعادة بأمان، واختبار التحديثات قبل تطبيقها على الحيّ.

لماذا تختبر الاستعادة في Staging تحديدًا؟

القاعدة الذهبية في النسخ الاحتياطي: النسخة التي لم تُجرَّب استعادتها ليست نسخة، بل افتراض. لكن أين تجرّبها؟ ليس على الموقع الحيّ بالطبع. بيئة Staging هي الحلبة المثالية: استعد فيها آخر نسخة، تصفّح الموقع، تحقّق من الصور والنماذج وتسجيل الدخول والسلّة (لمتجر)، ثم احذف كل شيء بأمان دون أثر على الحيّ. هذا يحوّل اختبار الاستعادة من مخاطرة إلى روتين هادئ.

سير العمل النموذجي لاختبار استعادة في Staging عبر WP-CLI:

# في بيئة Staging — استعادة نسخة كاملة للاختبار

# 1) فكّ ضغط ملفات النسخة إلى جذر الـStaging
tar -xzf files-2026-06-13-0315.tar.gz -C /var/www/staging

# 2) استيراد قاعدة البيانات (بعد التأكّد من بيانات الاتصال في wp-config)
gunzip < db-2026-06-13-0315.sql.gz | wp --path=/var/www/staging db import -

# 3) تحديث عناوين URL من نطاق الحيّ إلى نطاق الـStaging (يعالج البيانات المسلسلة)
wp --path=/var/www/staging search-replace 'https://example.com' 'https://staging.example.com' --all-tables --skip-columns=guid

# 4) مسح الكاش والتحقّق
wp --path=/var/www/staging cache flush
wp --path=/var/www/staging core verify-checksums

الخطوة الثالثة (search-replace) حاسمة وخاصّة بووردبريس: لأن عناوين URL مخزّنة داخل القاعدة وبعضها ضمن بيانات مسلسلة (serialized PHP)، فالاستبدال النصّي الساذج (عبر sed أو محرّر) يُفسد هذه البيانات. أمر wp search-replace يفهم التسلسل ويعالجه بأمان — لهذا هو الأداة الصحيحة لتغيير النطاق. خيار --skip-columns=guid يتجنّب تعديل حقل GUID الذي يجب أن يبقى ثابتًا.

الاتجاه المعاكس: نسخ احتياطي عبر Staging قبل التحديثات

الـStaging ليست لاختبار الاستعادة فقط، بل أيضًا شبكة أمان قبل التغييرات الخطرة. سير العمل الموصى به: انسخ الحيّ إلى Staging، طبّق التحديثات (نواة، إضافات، قالب) على الـStaging، اختبر أن كل شيء يعمل، ثم — وفقط بعد التأكّد — طبّق التحديثات على الحيّ (مع نسخة أمان قبلها مباشرةً). هذا يقطع دابر أكثر كارثة شائعة: تحديث يكسر الموقع الحيّ أمام زوّارك. وحين يحين وقت نقل التغييرات من Staging إلى الحيّ، تتقاطع العملية مع الهجرة؛ راجع دليل نقل موقع ووردبريس بدون توقّف لتفاصيل النشر الآمن من Staging إلى Production.

نصيحة خبير: انتبه إلى أن بيئة Staging أحيانًا تُستثنى من مهامّ النسخ المجدولة، أو يُحظر فهرستها من محرّكات البحث — وهذا صحيح. لكن لا تخلط: الـStaging أداة اختبار وتجربة، وليست بديلًا عن نسخة off-site. نسختك الحقيقية يجب أن تعيش خارج الخادم تمامًا، لا في نطاق فرعي على الخادم نفسه.

ملاحظات خاصّة: WordPress Multisite والمواقع الكبيرة

شبكة WordPress Multisite تضيف طبقة تعقيد تستحقّ انتباهًا خاصًّا. في الشبكة، كل المواقع تشترك في نواة وإضافات وقاعدة بيانات واحدة، لكن لكل موقع فرعي جداوله الخاصّة (ببادئة رقمية مثل wp_2_posts, wp_2_options) ومجلّد رفع خاصّ تحت wp-content/uploads/sites/<ID>/. هذا يعني:

لتصدير قاعدة شبكة كاملة، الأمر نفسه (wp db export). أما لتصدير موقع واحد من الشبكة، فاستهدف جداوله المحدّدة:

# عرض كل الجداول لتحديد جداول الموقع المطلوب (مثلًا الموقع رقم 2)
wp db tables 'wp_2_*' --all-tables-with-prefix

# تصدير جداول موقع فرعي واحد من الشبكة
wp db export site-2-$(date +%F).sql --tables=$(wp db tables 'wp_2_*' --all-tables-with-prefix --format=csv)

استعادة موقع فرعي مفرد داخل شبكة عملية حسّاسة: يجب استيراد جداوله ومجلّد رفعه sites/<ID>/ دون المساس ببقية الشبكة، وغالبًا تحتاج تشغيل search-replace مقيّدًا بجداول ذلك الموقع. لذا، إن كنت تدير شبكة، وثّق بنية الجداول والمواقع بدقّة في دليل الاستعادة — الارتجال هنا مكلف.

الجدولة والتخزين الخارجي (off-site) وقاعدة 3-2-1

كل ما سبق يخدم هدفًا واحدًا: نسخة سليمة في المكان الصحيح. هنا يأتي دور قاعدة 3-2-1 التي يشرحها بالتفصيل الدليل العام للنسخ الاحتياطي للموقع؛ باختصار شديد: 3 نسخ، على 2 وسيطين مختلفين، 1 منها على الأقل خارج الخادم. الرسم يلخّص الفكرة:

تطبيقها على ووردبريس عمليًا: النسخة الأولى لقطة المضيف اليومية (على الخادم، للاسترجاع السريع)، الثانية نسخة UpdraftPlus/WP-CLI تُرفع تلقائيًا إلى تخزين كائني بعيد، والثالثة نسخة شهرية تنزّلها وتحفظها محليًا. الجدول يقارن وجهات التخزين البعيدة الشائعة لووردبريس:

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

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار

دمج النسخ مع تأمين ووردبريس

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

أولًا، النسخ تلتقط الاختراق إن وُجد. إن أخذت نسخة بعد أن حُقن موقعك بكود خبيث دون أن تدري، فإن استعادتها لاحقًا تعيد الكود الخبيث معها. لهذا تحتاج عدّة نسخ سابقة تسمح بالعودة لما قبل تاريخ الاختراق — لا أحدث نسخة فقط. ثانيًا، مخزن النسخ يجب أن يكون أكثر أمانًا من الموقع نفسه: صلاحيات منفصلة، Versioning، وعدم وصول إليه من داخل ووردبريس. ثالثًا، بعد أي استعادة إثر اختراق، غيّر كل المفاتيح السرّية (Salts في wp-config.php) وكلمات المرور والمصادقة.

# توليد مفاتيح سرّية (Salts) جديدة في wp-config بعد استعادة إثر اختراق
wp config shuffle-salts

# إجبار كل المستخدمين على إعادة تسجيل الدخول (يبطل الجلسات المسروقة)
wp user session destroy --all --all

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

أخطاء شائعة في نسخ ووردبريس

هذه الأخطاء تتكرّر حتى عند أصحاب المواقع الحريصين، وكلٌّ منها قد يُبطل قيمة النسخ بالكامل:

استكشاف مشاكل نسخ ووردبريس واستعادته

عند تعثّر النسخ أو الاستعادة في ووردبريس تحديدًا، إليك أكثر المشكلات شيوعًا وحلولها:

إن واجهت أخطاء ووردبريس عامّة بعد الاستعادة (بياض الموت، خطأ 500، مشاكل الروابط الدائمة)، فدليل إصلاح أخطاء ووردبريس الشائعة يغطّي تشخيصها وحلولها خطوة بخطوة. ولفهم ووردبريس ككل وموقع النسخ ضمن دورة إدارته، يبقى دليل ووردبريس الكامل المرجع الشامل.

قائمة تحقّق نسخ ووردبريس

استخدم هذه القائمة كمعيار لاكتمال استراتيجيتك. أي بند لا تستطيع وضع علامة عليه يمثّل ثغرة:

الخلاصة

النسخ الاحتياطي لووردبريس ليس مهمّة تؤجّلها، بل وثيقة تأمين على عملك الرقمي. المبادئ الخاصّة بووردبريس واضحة: انسخ قاعدة بيانات MySQL مع wp-content وwp-config.php معًا ومتزامنين، واختر أداتك حسب مستواك — UpdraftPlus وأخواتها للمبتدئين والمواقع المتوسّطة، وWP-CLI مع cms وrsync للتقنيين والمواقع الكبيرة. فعّل الرفع off-site من اليوم الأول وفق قاعدة 3-2-1، واحتفظ بعدّة نسخ سابقة تنجيك من اختراق متأخّر الاكتشاف. لكن يبقى الفيصل الحقيقي بندًا واحدًا: اختبار الاستعادة في بيئة Staging دوريًا. النسخة التي لم تُجرَّب وهمٌ مريح حتى تنكشف وقت الكارثة. طبّق قائمة التحقّق، أتمت ما يمكن أتمتته، واجعل اختبار الاستعادة في Staging عادة شهرية.

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

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار

الأسئلة الشائعة

ما الذي يجب أن تشمله نسخة ووردبريس الكاملة؟ جزأان متلازمان: الملفات (وأهمّها wp-content بكل ما فيه من قوالب وإضافات ووسائط، مع wp-config.php) وقاعدة بيانات MySQL كاملة. الملفات وحدها تعطيك هيكلًا فارغًا، والقاعدة وحدها محتوى بلا واجهة — وكلاهما يجب أن يكونا متزامنين زمنيًا لتجنّب التعارضات.

هل UpdraftPlus كافٍ وحده لحماية موقعي؟ هو نقطة بداية ممتازة للمبتدئين والمواقع الصغيرة والمتوسّطة، خاصّة مع تفعيل الرفع off-site إلى Drive أو S3/R2 والاحتفاظ بعدّة نسخ. لكنه يعمل من داخل ووردبريس، فقد يتعثّر على المواقع الكبيرة أو يصبح غير متاح إن تعطّل الموقع كليًا. لا تجعله طبقتك الوحيدة؛ أضف طبقة WP-CLI أو نسخ خادم للمواقع الحرجة.

كيف أنسخ ووردبريس عبر WP-CLI؟ خطوتان: صدّر القاعدة بـ wp db export wp-db.sql (أو مضغوطة wp db export - | gzip > wp-db.sql.gz)، وأرشف الملفات بـ tar -czf wp-files.tar.gz -C /var/www/html . مع استبعاد الكاش. ثم اجمعهما في سكربت وجدوله بـ cron مع رفع off-site. الاستعادة بـ wp db import وفكّ ضغط الأرشيف.

لماذا أستخدم wp search-replace بدل البحث والاستبدال العادي عند تغيير النطاق؟ لأن ووردبريس يخزّن بعض البيانات بصيغة مسلسلة (serialized PHP) تتضمّن أطوال النصوص. الاستبدال النصّي الساذج (sed أو محرّر) يغيّر النص دون تحديث الأطوال، فيفسد البيانات وتتعطّل الإعدادات. أمر wp search-replace يفهم التسلسل ويعالجه بأمان، لذا هو الأداة الصحيحة عند نقل الموقع لنطاق جديد.

كيف أختبر أن نسختي قابلة للاستعادة فعلًا؟ استعدها في بيئة Staging منفصلة لا على الموقع الحيّ: فكّ ضغط الملفات، استورد القاعدة، شغّل wp search-replace لتعديل النطاق، ثم تصفّح الصفحات والصور والنماذج وتسجيل الدخول والسلّة (لمتجر). كرّر الاختبار شهريًا للمواقع الحرجة وكل بضعة أشهر لغيرها. النسخة غير المُختبَرة ليست نسخة.

كيف أتعامل مع نسخ قاعدة بيانات ووردبريس الضخمة؟ نظّف أولًا (wp transient delete --all وwp db optimize)، استخدم wp db export مع ضغط gzip فوريًا بدل أدوات المتصفّح، شخّص الجداول المنتفخة بـ wp db size --tables, واستورد دائمًا عبر wp db import من SSH لا من phpMyAdmin (الذي تقيّده حدود الرفع والمهلة في المتصفّح).

كيف يختلف النسخ في WordPress Multisite؟ الشبكة تشترك في نواة وإضافات وقاعدة واحدة، لكن لكل موقع فرعي جداوله الخاصّة (wp_<ID>_*) ومجلّد رفعه uploads/sites/<ID>/. تصدير الشبكة كاملة كالعادي (wp db export)، أما استعادة موقع فرعي مفرد فتتطلّب فصل جداوله ومجلّد رفعه وتشغيل search-replace مقيّدًا بجداوله — عملية حسّاسة تستحقّ توثيقًا دقيقًا.

هل أحتاج نسخة قبل كل تحديث في ووردبريس؟ نعم، بقوّة. التحديثات (نواة، إضافات، قوالب) أكثر أسباب أعطال ووردبريس. خذ نسخة كاملة قبل أي تحديث، والأفضل أن تختبر التحديث أولًا في Staging ثم تطبّقه على الحيّ. هذه «نسخة الأمان قبل القفزة» أرخص بكثير من إعادة بناء موقع أعطبه تحديث فاشل.

موقعي اختُرق — أي نسخة أستعيد وماذا أفعل بعدها؟ استعد نسخة نظيفة سابقة لتاريخ الاختراق، لا أحدث نسخة (التي قد تحوي الكود الخبيث) — ولهذا تحتاج عدّة نسخ سابقة. بعد الاستعادة، جدّد المفاتيح السرّية بـ wp config shuffle-salts, أبطل كل الجلسات بـ wp user session destroy --all --all, غيّر كل كلمات المرور، وافحص سبب الثغرة قبل إعادة التشغيل.