نسخ احتياطي لـ WordPress باستخدام PHP: سكربت النسخ الاحتياطي التلقائي

إذا كنت قد اكتشفت موقعًا بالفعل WordPress إذا تعطل موقعك بعد التحديث، وكان آخر نسخ احتياطي لديك قد مضى عليه ثلاثة أسابيع، فأنت تعرف المشكلة الحقيقية: إنها ليست مشكلة ووردبريس، بل مشكلة في عملية النسخ الاحتياطي. يعمل ووردبريس 6.9.4 بكفاءة تامة على PHP 8.1 والإصدارات الأحدث، ولكن لا يوجد نظام إدارة محتوى يحميك من الحذف العرضي، أو امتلاء القرص الصلب، أو الاختراق، أو استيراد الملفات بشكل خاطئ.

مشكلة/حاجة الخادم

يجب أن تغطي نسخة احتياطية قابلة للاستخدام من ووردبريس ما يلي: اثنان أشياء :

• قاعدة البيانات (المقالات، الصفحات، الإعدادات، المستخدمون، طلبات WooCommerce، إلخ).
• الملفات (محتوى ووردبريس كأولوية: القوالب، الإضافات، تحميل(ذاكرة تخزين مؤقتة محتملة، إضافات mu).

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

• لا يتم إجراء النسخ الاحتياطي "اليدوي" (ملف مضغوط تم تنزيله + تصدير SQL يدوي) في الوقت المناسب أبدًا.
• يتم تخزين النسخة الاحتياطية "التلقائية". في الملف العام (على سبيل المثال: /public_html/backupsوبالتالي يمكن الوصول إليها إذا خمن شخص ما عنوان URL، أو يتم حذفها إذا تعطل الخادم.

في النهاية، ستعرف كيفية إعداد برنامج نصي تلقائي عبر SSH + cron والذي:

• يقوم بتصدير قاعدة البيانات عبر WP-CLI (أكثر موثوقية من phpMyAdmin للأتمتة)،
• أرشفة الملفات الهامة
• يضغط، يسجل، يشفر (اختياري)،
• صنع تناوب (يحتفظ بـ N نسخة احتياطية)،
• ويتم اختباره على خشبة المسرح قبل بدء الإنتاج.

ديفي 5 / Elementor أفادا: لا يوجد تأثير مباشر. يحفظ البرنامج النصي نفس المجلدات، ولكن ضع في اعتبارك أن هذه الأدوات قد تخزن الأصول في بعض الأحيان في uploads وبيانات قاعدة البيانات: لذلك يجب عليك عمل نسخة احتياطية منها. ليه دو.

ملخص سريع

• أنت أحفظ الفسفور الابيض بين المحتوى + أ تفريغ SQL تم إنشاؤه بواسطة WP-CLI.
• تقوم بتخزين النسخ الاحتياطية خارج جذر الويب (على سبيل المثال /home/USER/backups), مع تصاريح صارمة.
• أنت تستخدم برنامج Bash نصي واحد، مع الجذوع et تناوب.
• يمكنك التخطيط عبر كرون (ليس عبر WP-Cron)، لتجنب عمليات النسخ الاحتياطي التي يتم تشغيلها بشكل عشوائي بسبب الزيارات.
• أنت تختبر عملية الترميم على انطلاق (دائماً)، وفقط عند بدء الإنتاج.
• يمكنك إضافة خيار لـإرسال عن بعد (SSH/SFTP) إذا كنت ترغب في النجاة من فقدان الخادم.

قبل البدء (المتطلبات الأساسية)

الوصول مطلوب:

• SSH على الخادم (ضروري) لتنفيذ الأوامر وتثبيت cron.
• WP-CLI هو مثبت (غالباً ما يكون موجوداً بالفعل على الخوادم الافتراضية الخاصة/الخوادم المُدارة). وإلا، يمكنك تثبيته بنفسك.
• الوصول إلى دليل ووردبريس (مسار من النوع /var/www/site ou /home/user/public_html).
• اختياري: الوصول إلى MySQL (إذا كنت ترغب في التحقق من الاستيراد يدويًا).

يُعدّ إجراء نسخة احتياطية أمرًا ضروريًا قبل أي عملية على الخادم: نعم، قد يبدو الأمر متناقضًا، لكنك ستُعدّل الأذونات، ومهام cron، وربما بعض البرامج النصية. على الأقل، أنشئ نسخة من wp-config.php وتصدير قاعدة البيانات عبر طريقتك الحالية.

الإصدارات الموصى بها (أبريل 2026):

• ووردبريس: 6.9.4
• بي أتش بي : 8.1+ (يُفضل عمومًا استخدام الإصدارين 8.2 و8.3 إذا كان مزود خدمة الاستضافة يدعمهما)
• MySQL: الإصدار 8+ أو MariaDB 10.6+
• الخادم: Nginx أو Apache (كلاهما مناسب)

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

مصادر رسمية مفيدة:

• WP-CLI: تصدير قاعدة بيانات ووردبريس
• WP-CLI: استيراد قاعدة بيانات ووردبريس
• WordPress.org: النسخ الاحتياطية
• PHP.net: تنفيذ (سياق الأمان)
• جيت هاب: WP-CLI

الخطوة 1: تحديد استراتيجية نسخ احتياطي واقعية (للملفات وقاعدة البيانات)

قبل كتابة أي كود، قرر ما أنت توفر و كم من الوقت احتفظ بالأرشيف. استراتيجية بسيطة، مناسبة للمدونين:

• يوميا قاعدة + wp-content (أو على الأقل wp-content/uploads (إذا كان حجم القرص لديك صغيرًا).
• احتفاظ : 7 أيام (يومياً)، + 4 أسابيع (أسبوعياً)، + 3 أشهر (شهرياً) إن أمكن.

في هذا الدليل، نطبق عملية تدوير "بسيطة": مع الحفاظ على آخر 14 النسخ الاحتياطية اليومية. من السهل صيانتها، ويمكنك توسيعها لاحقًا.

لماذا أفضل wp-content إلى "الموقع الكامل"؟ لأن:

• نواة ووردبريس (wp-admin, wp-includes) يتم إعادة تنزيله.
• يتم تخزين أدوات البناء (Divi/Elementor/Avada) ومحتوى الوسائط الخاص بك في wp-content.
• الأرشيفات أصغر حجماً، وبالتالي أسرع، وبالتالي يتم إنجازها بشكل متكرر.

الخطوة الثانية: تجهيز مجلد نسخ احتياطي غير متصل بالإنترنت + الأذونات

الهدف: خلق ملف خارج جذر الويبمثال نموذجي:

• ووردبريس موجود في /var/www/mon-site
• النسخ الاحتياطية في /var/backups/mon-site (أو /home/user/backups/mon-site (مشترك)

يُنشئ الأمر أدناه المجلد، ويُعيّن مالكًا له، ويُقفل الأذونات. عدّل اسم المستخدم (www-data في نظامي التشغيل ديبيان/أوبونتو، أحياناً nginx أو مستخدمك في الاستضافة المشتركة).

# Créez un dossier de backup hors du webroot
sudo mkdir -p /var/backups/mon-site

# Donnez l'accès à l'utilisateur qui exécute PHP/cron (adaptez)
sudo chown -R www-data:www-data /var/backups/mon-site

# Permissions strictes : seul le propriétaire lit/écrit/exécute
sudo chmod 700 /var/backups/mon-site

النتيجة المتوقعة: مجلد غير قابل للوصول إليه من الإنترنت وغير قابل للعرض عبر بروتوكول HTTP. إذا كنت تستخدم استضافة مشتركة بلا sudo, do:

mkdir -p ~/backups/mon-site
chmod 700 ~/backups/mon-site

في هذه المرحلة، تحقق من مساحة القرص. غالبًا ما تفشل عمليات النسخ الاحتياطي "بصمت" لأن القرص ممتلئ.

# Espace disque
df -h

# Taille du wp-content (pour estimer)
du -sh /var/www/mon-site/wp-content

الخطوة 3: كتابة برنامج نصي للنسخ الاحتياطي التلقائي (باستخدام Bash) مع تدوير الملفات

سنقوم بإنشاء برنامج نصي واحد قابل للتنفيذ بلغة باش يقوم بما يلي:

• يتم وضعه في مجلد ووردبريس.
• يقوم بتصدير قاعدة البيانات عبر WP-CLI.
• أرشيف wp-content بالإضافة إلى ملف SQL المُفرّغ،
• يحذف النسخ الاحتياطية التي تتجاوز عددًا معينًا،
• يكتب سجلاً.

لماذا باش (وليس PHP)؟ بالنسبة لعمل نسخة احتياطية للخادم، فإن باش أكثر مباشرة: الوصول إلى أدوات النظام (tar, gzip, findمعالجة الأخطاء، والتنفيذ عبر cron. كما تتجنب تحميل ووردبريس عبر HTTP (خطر انقطاع الاتصال).

أنشئ الملف /usr/local/bin/wp-backup-mon-site.sh (أو ~/bin/... (في الاستضافة المشتركة). يفتح الأمر أدناه محرر نصوص (nano). يمكنك استخدام vim إذا كنت تفضل ذلك.

sudo nano /usr/local/bin/wp-backup-mon-site.sh

ألصق هذا النص البرمجي كاملاً (مع تعديل المسارات). التعليقات باللغة الفرنسية وتشرح الخيارات.

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

# ==============================
# Script de backup WordPress (WP 6.9.4+)
# - Dump SQL via WP-CLI
# - Archive wp-content + dump
# - Rotation (garde N backups)
# - Log d'exécution
# ==============================

# Chemin vers l'installation WordPress (dossier contenant wp-config.php)
WP_PATH="/var/www/mon-site"

# Dossier de destination des backups (hors webroot)
BACKUP_DIR="/var/backups/mon-site"

# Nombre de backups à conserver
KEEP_LAST=14

# Binaire WP-CLI (souvent "wp" si dans le PATH)
WP_BIN="/usr/local/bin/wp"

# Date pour nommer les fichiers
NOW="$(date +%F_%H-%M-%S)"

# Fichiers générés
DB_DUMP="${BACKUP_DIR}/db_${NOW}.sql"
ARCHIVE="${BACKUP_DIR}/backup_${NOW}.tar.gz"
LOG_FILE="${BACKUP_DIR}/backup.log"

# Fonction de log
log() {
  echo "[$(date +%F %T)] $*" | tee -a "${LOG_FILE}"
}

# Vérifications de base
if [[ ! -d "${WP_PATH}" ]]; then
  echo "WP_PATH introuvable: ${WP_PATH}" >&2
  exit 1
fi

if [[ ! -f "${WP_PATH}/wp-config.php" ]]; then
  echo "wp-config.php introuvable dans: ${WP_PATH}" >&2
  exit 1
fi

if [[ ! -d "${BACKUP_DIR}" ]]; then
  echo "BACKUP_DIR introuvable: ${BACKUP_DIR}" >&2
  exit 1
fi

if [[ ! -x "${WP_BIN}" ]]; then
  echo "WP-CLI introuvable/exécutable: ${WP_BIN}" >&2
  exit 1
fi

log "Début backup: WP_PATH=${WP_PATH} BACKUP_DIR=${BACKUP_DIR}"

# Se placer dans le dossier WordPress
cd "${WP_PATH}"

# 1) Export base de données (WP-CLI)
# --single-transaction limite les verrous (InnoDB)
# --quick réduit la mémoire côté client
log "Export base (WP-CLI) vers ${DB_DUMP}"
"${WP_BIN}" db export "${DB_DUMP}" --add-drop-table --single-transaction --quick

# 2) Archive des fichiers
# On sauvegarde wp-content + le dump SQL
# --warning=no-file-changed évite des warnings si des fichiers changent pendant l'archivage
log "Archivage wp-content + dump SQL vers ${ARCHIVE}"
tar --warning=no-file-changed -czf "${ARCHIVE}" 
  -C "${WP_PATH}" wp-content 
  -C "${BACKUP_DIR}" "$(basename "${DB_DUMP}")"

# 3) Optionnel : checksum pour vérifier l'intégrité
log "Génération checksum SHA-256"
sha256sum "${ARCHIVE}" >> "${BACKUP_DIR}/checksums.sha256"

# 4) Nettoyage : supprimer le dump SQL brut après intégration dans l'archive
log "Suppression du dump SQL brut ${DB_DUMP}"
rm -f "${DB_DUMP}"

# 5) Rotation : garder les N derniers backups
log "Rotation: conservation des ${KEEP_LAST} derniers backups"
ls -1t "${BACKUP_DIR}"/backup_*.tar.gz 2>/dev/null | tail -n +"$((KEEP_LAST+1))" | xargs -r rm -f

log "Backup terminé: ${ARCHIVE}"

اجعله قابلاً للتنفيذ:

sudo chmod 750 /usr/local/bin/wp-backup-mon-site.sh
sudo chown root:root /usr/local/bin/wp-backup-mon-site.sh

ملاحظة عملية: إذا كانت مهمة cron الخاصة بك تعمل تحت www-data (أو مستخدمك)، يمكنك وضع المستخدم المالك هناك. في الخوادم الافتراضية الخاصة الصغيرة، غالبًا ما أفضل تشغيل النسخ الاحتياطي بصلاحيات المستخدم الجذر (cron root) ولكن الكتابة إلى مجلد مقفل. أما في الاستضافة المشتركة، فلن يكون لديك صلاحيات المستخدم الجذر: شغّل كل شيء بصلاحيات المستخدم الخاص بك.

الخطوة الرابعة: تصدير قاعدة البيانات بشكل صحيح (باستخدام WP-CLI) والتحقق من سلامتها

يُعد WP-CLI أفضل حليف لك لعمل نسخ احتياطية لموقع ووردبريس، لأنه يقرأ ملف الإعدادات (wp-config.phpويعمل محليًا، دون قيود على بروتوكول HTTP. الأوامر الرئيسية هي:

• wp db export تصدير SQL
• wp db import استيراد SQL
• wp db check : تَحَقّق

قبل إعداد cron، اختبر البرنامج النصي يدويًا (واقرأ السجل). شغّل الأمر، ثم تحقق من إنشاء الأرشيف.

# Exécution manuelle
sudo /usr/local/bin/wp-backup-mon-site.sh

# Vérifier la présence des fichiers
sudo ls -lh /var/backups/mon-site | tail -n 20

# Lire le log
sudo tail -n 50 /var/backups/mon-site/backup.log

تحقق من سلامة الأرشيف:

# Tester l'archive (ne restaure rien, vérifie juste la structure gzip/tar)
gzip -t /var/backups/mon-site/backup_YYYY-MM-DD_HH-MM-SS.tar.gz

# Lister le contenu
tar -tzf /var/backups/mon-site/backup_YYYY-MM-DD_HH-MM-SS.tar.gz | head

إذا رأيت wp-content/ وملف db_....sqlهذه علامة جيدة.

الخطوة 5: جدولة التنفيذ (cron) وتسجيله

لا تخلط بين الأمور:

• WP-كرون : يتم تشغيلها عن طريق الزيارات، وهي غير موثوقة لعمل نسخة احتياطية للخادم.
• أنظمة كرون : يتم تشغيله في وقت محدد، موثوق.

سنقوم بجدولة عملية نسخ احتياطي كل ليلة في تمام الساعة 03:15 صباحًا. قبل عرض سطر cron، إليك ما يفعله:

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

قم بتحرير ملف crontab (هنا للمستخدم الجذر؛ قم بتعديله إذا كنت تستخدم مستخدمًا آخر):

sudo crontab -e

يضيف:

# Backup WordPress quotidien à 03:15
15 3 * * * /usr/local/bin/wp-backup-mon-site.sh >> /var/backups/mon-site/cron.log 2>&1

في الاستضافة المشتركة (بدون استخدام sudo)، استخدم:

crontab -e

15 3 * * * /home/VOTRE_USER/bin/wp-backup-mon-site.sh >> /home/VOTRE_USER/backups/mon-site/cron.log 2>&1

نصيحة ميدانية: كثيراً ما أرى نسخاً احتياطية مجدولة (cron) "لا تفعل شيئاً" ببساطة لأن cron لا يمتلك نفس... PATH من سطر الأوامر الخاص بك. لهذا السبب يشير البرنامج النصي إلى /usr/local/bin/wp بشكل صريح. إذا كان برنامج WP-CLI موجودًا في مكان آخر، فابحث عنه:

which wp
wp --info

الخطوة السادسة: الترميم (التحضير ثم الإنتاج) دون الوقوع في مأزق

النسخة الاحتياطية غير المختبرة مجرد فرضية. اختبر عملية الاستعادة على انطلاق (انسخ من الموقع) قبل اليوم الذي تحتاجه فيه.

6.1 جهّز المسرح بسرعة

الحل الأبسط: مضيف افتراضي ثانٍ (على سبيل المثال، staging.monsite.tld) يشير إلى مجلد منفصل وقاعدة بيانات منفصلة. من جانب الكود/الأمر، لديك خياران:

• قم بإنشاء تثبيت جديد لـ WordPress 6.9.4، ثم قم باستعادة التثبيت.
• استنسخ الملفات وأنشئ قاعدة بيانات جديدة، ثم استوردها.

سألتزم بسيناريو "التثبيت الجديد + الاستعادة"، وهو أنظف.

6.2 استخراج الأرشيف

أنشئ مجلدًا مستهدفًا (مرحلة تجريبية) واستخرج منه فقط ما تحتاجه. هنا، نقوم بالاستعادة. wp-content ونقوم باستعادة ملف SQL.

# Exemple : dossier staging
STAGING_PATH="/var/www/mon-site-staging"
ARCHIVE="/var/backups/mon-site/backup_YYYY-MM-DD_HH-MM-SS.tar.gz"

# Extraire
sudo tar -xzf "${ARCHIVE}" -C "${STAGING_PATH}"

# Vérifier que wp-content est bien en place
sudo ls -la "${STAGING_PATH}/wp-content" | head

تحذير: قد تقوم باستخراج البيانات بناءً على كيفية تنظيم بيئة الاختبار الخاصة بك. wp-content في المستوى الخاطئ (خطأ شائع). تحقق دائمًا من شجرة الدليل بعد الاستخراج.

6.3 استيراد قاعدة البيانات

حدد موقع ملف SQL المستخرج (في هذا المثال، يوجد في الأرشيف في جذر مجلد الاستخراج). ثم استورده باستخدام WP-CLI.

# Se placer dans le staging (dossier contenant wp-config.php du staging)
cd /var/www/mon-site-staging

# Vérifier que WP-CLI "voit" bien WordPress
wp core version

# Import DB (adaptez le nom du fichier)
wp db import /var/www/mon-site-staging/db_YYYY-MM-DD_HH-MM-SS.sql

# Vérifier la base
wp db check

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

# Remplacer l'URL prod par l'URL staging (adaptez)
wp search-replace 'https://monsite.tld' 'https://staging.monsite.tld' --all-tables --precise --skip-columns=guid

المعلمة --skip-columns=guid تجنب كسر معرّفات GUID لمنشورات RSS. إنها ممارسة جيدة أتبعها دائمًا.

ملفات التكوين الكاملة

يحتوي هذا القسم على ملفات "جاهزة للصق" مناسبة للنسخ الاحتياطي: الحماية، وحدود PHP، ومثال Nginx لمنع أي كشف عرضي إذا كنت لا تزال تخزن الأرشيفات في مجلد مُخدّم (وهو ما لا أوصي به).

ملف .htaccess (أباتشي): قم بحظر مجلد النسخ الاحتياطي إذا لم يكن لديك خيار آخر

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

# Fichier: /chemin/site/backups/.htaccess
# Objectif: interdire tout accès HTTP aux archives et aux .sql
Require all denied

<FilesMatch ".(sql|gz|zip|tar|tgz)$">
  Require all denied
</FilesMatch>

nginx.conf: امنع الوصول إلى /backups/ إذا كان مكشوفًا

بالنسبة لـ Nginx، أضف كتلة في قسم الخادم {} الخاص بالموقع:

# Exemple à placer dans le server {} de votre vhost
location ^~ /backups/ {
  deny all;
  return 403;
}

wp-config.php: فرض تعطيل محرر الملفات

هذا ليس "نسخة احتياطية"، ولكنه يحد من الضرر في حالة اختراق صلاحيات المسؤول. أضفه إلى wp-config.php :

/** Désactive l'éditeur de fichiers dans l'admin (réduit le risque en cas de compromission) */
define('DISALLOW_FILE_EDIT', true);

إشارة: wp-config.php (WordPress.org)

ملف php.ini (أو تعديله): منع حدوث مهلة أثناء العمليات التي تستهلك موارد كثيرة

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

; Exemple php.ini (adaptez selon votre hébergeur)
memory_limit = 512M
max_execution_time = 300
post_max_size = 64M
upload_max_filesize = 64M

إذا كنت غير متأكد من مكان وضع هذا الملف، فلا تُجبره على ذلك: في العديد من الخوادم، تتم معالجته بشكل عام. اختبره أولاً.

---

التحقق

أنت تريد عناصر تحكم بسيطة وقابلة للتكرار بدون واجهة رسومية.

1) تأكد من أن cron قيد التشغيل

انتظر حتى الموعد المحدد، ثم:

# Voir les logs
sudo tail -n 100 /var/backups/mon-site/cron.log
sudo tail -n 100 /var/backups/mon-site/backup.log

يجب أن ترى عبارة "بدء النسخ الاحتياطي" ثم "اكتمل النسخ الاحتياطي".

2) تحقق من الدوران

بعد عدة عمليات إعدام:

ls -1 /var/backups/mon-site/backup_*.tar.gz | wc -l

يجب ألا يتجاوز العدد المحدد في KEEP_LAST.

3) التحقق من سلامة البيانات عبر مجموع التحقق

cd /var/backups/mon-site
# Vérifie que les checksums correspondent (si vous ne conservez que les derniers, adaptez)
sha256sum -c checksums.sha256 2>/dev/null | tail -n 20

4) تأكد من أن WP-CLI يعمل في الوضع غير التفاعلي

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

sudo -u www-data /usr/local/bin/wp --info
sudo -u www-data /usr/local/bin/wp --path=/var/www/mon-site core version

إذا لم ينجح الأمر

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

التشخيص خطوة بخطوة

1) لا يتم تشغيل البرنامج النصي

• تحقق من بت التنفيذ: ls -l /usr/local/bin/wp-backup-mon-site.sh
• تحقق من السطر الأول (shebang): head -n 1 ...
• اختبار مباشر: bash -x /usr/local/bin/wp-backup-mon-site.sh (وضع التصحيح)

2) يفشل WP-CLI عبر cron ولكنه يعمل عبر SSH

• السبب المشترك: WP_BIN غير صحيح أو PATH مختلف.
• الحل: استخدم المسار المطلق لـ wp (تم ذلك بالفعل في البرنامج النصي) ثم مرر --path=... اذا لزم.

# Exemple si WP-CLI "ne trouve pas" WordPress
/usr/local/bin/wp --path=/var/www/mon-site db export /var/backups/mon-site/test.sql

3) "تم رفض الإذن"

• تحقق من ملكية مجلد النسخ الاحتياطي وصلاحياته: namei -l /var/backups/mon-site
• تحقق من المستخدم الذي يقوم بتشغيل cron: sudo crontab -l (إذا كان المستخدم الجذر) أو crontab -l

4) القرص الكامل

df -h
du -sh /var/backups/mon-site
du -sh /var/www/mon-site/wp-content/uploads

مخطط تشخيصي (أعراض واقعية)

عرض	السبب المحتمل	التحقق	الحلول
الملف cron.log لا يزال فارغًا	لم يتم تكوين Cron للمستخدم الصحيح	crontab -l (المستخدم) و sudo crontab -l (الجذر)	أضف المهمة إلى جدول المهام الصحيح (crontab).
WP-CLI introuvable/exécutable	WP_BIN خطأ أو لم يتم تثبيت WP-CLI	which wp, wp --info	قم بتثبيت WP-CLI أو تصحيح المسار المطلق
Error: This does not seem to be a WordPress installation	WP_PATH ملف حالي خاطئ أو تالف في cron	ls -la $WP_PATH/wp-config.php	يتدخل WP_PATH و/أو استخدام --path=
tar: Cannot open: Permission denied	حقوق غير كافية بشأن BACKUP_DIR	ls -ld BACKUP_DIR	chown/chmod تم تعديلها، أو تشغيل cron باستخدام المستخدم الصحيح
عمليات النسخ الاحتياطي بطيئة للغاية	uploads ضخم، محدود بوحدة المعالجة المركزية، إدخال/إخراج بطيء	du -sh uploads, top	استبعاد من ذاكرة التخزين المؤقت، والتبديل إلى النسخ الاحتياطي التزايدي (rsync)، وزيادة نافذة النسخ الاحتياطي
تم إنشاء الأرشيف ولكن لا يمكن استعادته	لم يتم اختبار النسخة الاحتياطية، والملف مفقود، والأرشيف تالف.	tar -tzf, gzip -t	أضف مجموع التحقق + استعد الاختبار على بيئة الاختبار

الأخطاء الشائعة والمزالق

خطأ	سبب	الحلول
انسخ النص البرمجي إلى functions.php	الخلط بين "كود ووردبريس" و"كود الخادم"	يتم إجراء النسخ الاحتياطي للخادم عبر SSH/cron، وليس في القالب (مخاطر أمنية + مهلات).
نسيان الفاصلة المنقوطة... في باش	نسخ ولصق جزئي، علامات اقتباس مكسورة	رماح bash -n script.sh et shellcheck إذا كان متاحا
الاختبار مباشرة في بيئة الإنتاج بدون وجود نسخة احتياطية.	عبارة روتينية: "سأراك لاحقاً"	قم بإجراء نسخة احتياطية يدوية واحدة على الأقل قبل نشر cron.
النسخ الاحتياطية المخزنة في /public_html/backups	كان الأمر أبسط "في ذلك الوقت"	قم بتخزين الملفات خارج جذر الموقع؛ وإلا، احظر الوصول عبر Nginx/Apache باستخدام أسماء يصعب تخمينها.
يعمل WP-CLI عبر SSH ولكن ليس عبر cron	بيئة كرون المصغرة (PATH)	استخدم المسار المطلق إلى wp وتحديد WP_PATH
روابط دائمة "غريبة" بعد الاستعادة	قواعد إعادة الكتابة غير المُعاد إنشاؤها	رماح wp rewrite flush --hard بعد الترميم (أولاً على الأسطح المُجهزة)
تعارض في ذاكرة التخزين المؤقت (صفحات غير متناسقة بعد الاستعادة)	ذاكرة التخزين المؤقت للملحقات + ذاكرة التخزين المؤقت للخادم + شبكة توصيل المحتوى (CDN)	قم بمسح ذاكرة التخزين المؤقت (المكون الإضافي، Nginx fastcgi، CDN) بعد الاستعادة
شرح قديم مبني على mysqldump باستخدام معرّفات نصية عادية	نسخة من مقتطفات قديمة	تفضل wp db export (ووردبريس 6.9.4) وتقييد ملفات التكوين

أمان الخادم

يمكن أن يصبح نظام النسخ الاحتياطي مصدرًا لتسريب البيانات إذا تعاملت معه كملف مضغوط بسيط.

1) الأذونات والموقع

• النسخ الاحتياطي خارج نطاق ويب روت (الأولوية رقم 1).
• ملف في 700، ملفات في 600 إذا كان ذلك ممكنا.
• تجنب ترك الأشياء ملقاة في كل مكان .sql غير مضغوط.

2) التشفير (خيار عملي)

إذا كنت بحاجة إلى نقل/تخزين الأرشيف في مكان آخر (مثل جهاز تخزين متصل بالشبكة أو خادم آخر)، فقم بتشفيره. مثال باستخدام OpenSSL (كلمة المرور):

# Chiffre une archive (AES-256)
openssl enc -aes-256-cbc -salt -pbkdf2 
  -in /var/backups/mon-site/backup_YYYY.tar.gz 
  -out /var/backups/mon-site/backup_YYYY.tar.gz.enc

المخاطرة: إذا فقدت كلمة المرور، ستفقد النسخة الاحتياطية. لذا، احفظها في برنامج إدارة كلمات المرور.

3) الإرسال عن بعد (في حالة تعطل الخادم)

تتضمن خطة التعافي من الكوارث "الحقيقية" نسخة احتياطية خارج الخادم. أبسط مثال على الكود: rsync عبر بروتوكول SSH إلى خادم آخر.

# Exemple: pousser les archives vers un serveur distant
# À faire après la création de l'archive, idéalement avec une clé SSH dédiée
rsync -av --delete /var/backups/mon-site/ backupuser@backup-host:/data/backups/mon-site/

4) لا تكشف السجلات مطلقًا

قد تحتوي سجلاتك على مسارات وأسماء ملفات ومعلومات أخرى قد تفيد المهاجم. لذا، خزّنها في نفس موقع نسخك الاحتياطية، خارج مجلد الموقع الرئيسي.

الموارد

• WordPress.org — نسخ احتياطية من ووردبريس
• Developer.WordPress.org — WP-CLI: wp db export
• Developer.WordPress.org — WP-CLI: wp db import
• Developer.WordPress.org — WP-CLI: wp search-replace
• GitHub — WP-CLI (شفرة المصدر)
• PHP.net — سطر أوامر PHP (CLI)

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

هل يمكنني إجراء هذا النسخ الاحتياطي "عبر الكود" في إضافة ووردبريس؟

من الناحية التقنية، نعم، لكنني لا أنصح المبتدئين بذلك: فتشغيل أرشفة قواعد البيانات وتصديرها عبر طلبات HTTP يعرضك لمخاطر انقطاع الاتصال ومخاطر أمنية (إذ قد يقوم شخص ما بتشغيل النسخ الاحتياطي). يُعد استخدام مهمة مجدولة (cron job) وبرنامج نصي (SSH script) أكثر موثوقية.

لماذا لا تقوم بعمل نسخة احتياطية من جميع ملفات ووردبريس (بما في ذلك الملفات الأساسية)؟

يمكنك فعل ذلك، لكنه يزيد حجم الأرشيف بشكل كبير مقابل فائدة ضئيلة. سيتم إعادة تثبيت النظام الأساسي. wp-content + يغطي DB الأساسيات.

هل برنامج WP-CLI متوافق مع ووردبريس 6.9.4؟

نعم، يدعم WP-CLI ووردبريس. ثبّت إصدارًا حديثًا. تحقق من ذلك باستخدام wp --info والاختبار wp core version.

ليس لديّ إمكانية الوصول إلى SSH، ماذا أفعل؟

بدون SSH، لن تتمكن من إجراء نسخ احتياطي تلقائي حقيقي للخادم باستخدام البرامج النصية أو مهام cron. البدائل المتاحة أمامك هي استخدام إضافة نسخ احتياطي موثوقة أو طلب تفعيل SSH/cron من مزود خدمة الاستضافة.

كم عدد النسخ الاحتياطية التي يجب أن أحتفظ بها؟

بالنسبة للمدونة: يُعدّ نشر 14 منشورًا يوميًا بداية جيدة. إذا كنت تنشر بشكل متكرر (أو تستخدم ووكومرس)، فقم بزيادة هذا العدد وأضف نسخة احتياطية.

كيف يمكنني استبعاد مجلدات التخزين المؤقت في wp-content؟

يمكنك استبعاد مسارات في ملف tar، لكن هذه طريقة متقدمة. يمكن إعادة إنشاء ذاكرة التخزين المؤقت، لذا فإن استبعادها يقلل من حجم الملف. مثال (قابل للتعديل): استخدم --exclude='wp-content/cache' في أمر tar.

موقعي الإلكتروني ضخم، وضغط الملفات باستخدام tar/gzip بطيء للغاية. هل من بدائل؟

نعم: نسخة احتياطية تزايدية بواسطة rsync (لقطة)، ونسخة احتياطية منفصلة من قاعدة البيانات. هذا ما أنتهي به غالبًا عند تحميل الملفات على مواقع الوسائط المتعددة ذات الأحجام الكبيرة.

بعد عملية الاستعادة، يعرض Elementor/Divi/Avada تخطيطات معطوبة.

الأسباب الشائعة: عدم استبدال عنوان URL (باستخدام البحث والاستبدال)، أو عدم مسح ذاكرة التخزين المؤقت، أو الحاجة إلى إعادة إنشاء الأصول المُنشأة. wp search-replaceقم بمسح ذاكرة التخزين المؤقت، ثم أعد إنشاء ملفات CSS عبر أداة الإنشاء إذا لزم الأمر.

هل يمكنني تخزين النسخ الاحتياطية على نفس الخادم ولكن في مجلد مختلف؟

نعم، لكن هذا لا يحمي من تعطل الخادم بالكامل. الحد الأدنى هو "خارج جذر الموقع". والأفضل هو "خارج الخادم".

كيف يمكنني التأكد من أن النسخة الاحتياطية الخاصة بي تحتوي على قاعدة البيانات؟

قائمة الأرشيف: tar -tzf backup_...tar.gz وتحقق من وجود db_....sqlبعد ذلك، اختبر عملية الترميم على مرحلة تجريبية: هذا هو الاختبار الوحيد المهم حقًا.