كيفية عمل نسخ احتياطية تلقائية لموقع WordPress على VPS واستعادتها خطوة بخطوة

قد تقضي أسابيع أو أشهر في إنشاء موقع WordPress وإعداد القالب ونشر المقالات وتحسين ظهوره في محركات البحث، ثم تفقد جزءًا كبيرًا من عملك بسبب خطأ أثناء التحديث أو تلف قاعدة البيانات أو مشكلة في السيرفر.

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

وإذا كنت تستضيف WordPress على سيرفر VPS، فإن مسؤولية حماية البيانات تقع بدرجة كبيرة على عاتقك، خصوصًا إذا كنت تدير السيرفر بنفسك دون لوحة تحكم توفر نسخًا احتياطية تلقائية.

في هذا الدليل من حكاية تقنية، سنتعلم كيفية إنشاء نسخ احتياطية تلقائية لموقع WordPress على VPS باستخدام Ubuntu وMariaDB وCron، وكيفية الاحتفاظ بنسخ من ملفات الموقع وقاعدة البيانات، ثم اختبار استعادتها عند الحاجة.

سنستخدم Ubuntu Server 24.04 LTS مع Nginx وPHP-FPM وMariaDB، وهي البيئة التي أعددناها في المقالات السابقة من سلسلة إدارة السيرفرات.

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

لماذا تحتاج إلى نسخ احتياطية لموقع WordPress؟

حتى المواقع التي تستخدم سيرفرات مستقرة وتحديثات أمنية منتظمة قد تتعرض لفقدان البيانات.

ومن الأسباب المحتملة:

• خطأ أثناء تحديث WordPress أو إحدى الإضافات.
• حذف ملفات أو مقالات بالخطأ.
• تلف بعض جداول قاعدة البيانات.
• اختراق الموقع أو تعديل ملفاته.
• تعطل وحدة التخزين.
• مشكلة أثناء نقل الموقع إلى سيرفر جديد.
• خطأ في إعدادات السيرفر.
• فقدان الوصول إلى حساب الاستضافة.

تساعد النسخ الاحتياطية على تقليل حجم الخسارة المحتملة، لكنها لا تمنع حدوث المشكلة نفسها.

كما أن وجود نسخة احتياطية لا يكفي؛ يجب التأكد من إمكانية استعادتها.

1. ما الملفات التي يجب نسخها من WordPress؟

يتكون موقع WordPress المعتاد من جزأين رئيسيين:

ملفات الموقع

تتضمن ملفات WordPress الأساسية والقوالب والإضافات والصور والوسائط والملفات المخصصة.

ومن أهم المسارات:

wp-content/themes

wp-content/plugins

wp-content/uploads

كما يحتوي ملف wp-config.php على معلومات الاتصال بقاعدة البيانات وإعدادات حساسة.

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

تحتوي MariaDB على المقالات والصفحات والتعليقات والمستخدمين وإعدادات WordPress، إضافة إلى البيانات التي تحفظها القوالب والإضافات.

نسخ ملفات الموقع وحدها لا يعني أنك نسخت قاعدة البيانات.

وبالمثل، فإن تصدير قاعدة البيانات دون حفظ ملفات الوسائط والقوالب لا يكفي عادةً لاستعادة الموقع كاملًا.

لذلك يجب الاحتفاظ بالملفات وقاعدة البيانات ضمن مجموعة نسخ احتياطية واحدة.

2. الفرق بين النسخ الاحتياطي اليدوي والتلقائي

النسخ اليدوي مناسب قبل إجراء تغييرات كبيرة، مثل ترقية PHP أو تعديل إعدادات Nginx.

أما النسخ التلقائي فينفذ وفق جدول محدد دون الحاجة إلى تذكر العملية كل مرة.

النوع	الميزة	القيد
يدوي	مناسب قبل التغييرات المهمة	يعتمد على تذكّر المسؤول
تلقائي	ينفذ بانتظام	يحتاج مراقبة وفحصًا
خارج السيرفر	يحمي من فقدان السيرفر نفسه	يحتاج تخزينًا مستقلًا
Snapshot	قد يسهّل استعادة بيئة كاملة	لا يغني عن خطة نسخ مستقلة

أفضل استراتيجية عادةً تجمع بين النسخ المجدولة، والنسخ قبل التغييرات المهمة، والاحتفاظ بنسخة خارج السيرفر.

3. تحديد خطة النسخ الاحتياطي المناسبة

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

هناك مفهومان مهمان:

RPO – Recovery Point Objective

يمثل الحد الأقصى المستهدف لفقدان البيانات زمنيًا.

إذا كنت تنسخ الموقع يوميًا، فقد تخسر التغييرات التي حدثت منذ آخر نسخة ناجحة.

RTO – Recovery Time Objective

يمثل المدة المستهدفة لاستعادة الخدمة بعد حدوث مشكلة.

تختلف هذه الأهداف بحسب طبيعة الموقع.

فموقع تعريفي قليل التحديثات يختلف عن متجر يستقبل طلبات ومدفوعات باستمرار.

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

4. التحقق من بيئة السيرفر

اتصل بالسيرفر عبر SSH:

ssh adminuser@SERVER_IP

استبدل اسم المستخدم وعنوان السيرفر بالقيم الصحيحة.

تحقق من إصدار Ubuntu:

cat /etc/os-release

ثم افحص حالة MariaDB:

systemctl is-active mariadb

وافحص مساحة التخزين:

df -h

تأكد من وجود مساحة كافية لإنشاء النسخ المؤقتة والنهائية.

إذا كانت مساحة القرص شبه ممتلئة، فقد تفشل عملية النسخ أو تؤثر في عمل الموقع.

5. إنشاء مجلد آمن للنسخ الاحتياطية

سنستخدم المسار التالي:

/var/backups/wordpress

من الأفضل أن يكون خارج مجلد الموقع العام الذي يقدمه Nginx.

أنشئ المجلد:

sudo install -d -m 700 -o root -g root /var/backups/wordpress

هذا الأمر ينشئ المجلد بملكية المستخدم root وصلاحيات تمنع المستخدمين الآخرين من تصفحه.

لماذا لا نضع النسخ داخل public_html؟

لأن ملفات النسخ قد تحتوي على قاعدة البيانات وكلمات المرور وإعدادات حساسة.

وجودها داخل مجلد يمكن لخادم الويب الوصول إليه يزيد مخاطر كشفها عند حدوث خطأ في إعدادات Nginx.

مهم: حفظ النسخة خارج مجلد الموقع لا يجعلها محمية من تعطل القرص أو فقدان السيرفر. سنناقش التخزين الخارجي لاحقًا.

6. إنشاء نسخة احتياطية يدوية لقاعدة بيانات MariaDB

في مقال تثبيت WordPress السابق، استخدمنا قاعدة بيانات باسم:

wordpress_db

سنستخدم الاسم نفسه في هذا المثال.

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

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

في بيئة Ubuntu التي تستخدم المصادقة المحلية لحساب MariaDB الإداري، يمكن تنفيذ:

sudo mariadb-dump --single-transaction --quick wordpress_db > /tmp/wordpress-test.sql

قد يفشل الأمر إذا كانت طريقة المصادقة أو الصلاحيات مختلفة.

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

ما وظيفة الخيارات؟

--single-transaction

يساعد على إنشاء لقطة متسقة للجداول التي تستخدم محرك InnoDB دون الحاجة إلى قفلها طوال مدة النسخ.

--quick

يساعد على قراءة النتائج تدريجيًا بدل تحميل جميع الصفوف في الذاكرة دفعة واحدة.

هل يضمن الأمر نسخة متسقة دائمًا؟

لا.

تقتصر ضمانات --single-transaction على محركات التخزين التي تدعم المعاملات بصورة مناسبة، مثل InnoDB.

كما ينبغي تجنب إجراء تغييرات بنيوية على الجداول أثناء التصدير.

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

حذف الملف التجريبي بعد الفحص

بعد التأكد من نجاح تجربة التصدير وعدم حاجتك إلى الملف:

sudo rm -i /tmp/wordpress-test.sql

استخدم الخيار -i للمطالبة بالتأكيد قبل الحذف.

7. إنشاء نسخة احتياطية من ملفات WordPress

نفترض أن ملفات الموقع موجودة في:

/var/www/example.com/html

استبدل example.com بدومينك الحقيقي.

لإنشاء أرشيف مضغوط:

sudo tar -czf /var/backups/wordpress/files-manual.tar.gz \
  -C /var/www/example.com html

يحتوي الأرشيف على مجلد html ومحتوياته.

ماذا عن الملفات المخفية؟

عند أرشفة المجلد كاملًا باستخدام tar، تُضمّن الملفات المخفية الموجودة داخله أيضًا، ما لم تستثنها صراحةً.

ماذا عن إعدادات Nginx؟

أرشيف WordPress السابق لا يشمل ملفات إعداد Nginx أو شهادات HTTPS الموجودة خارج مجلد الموقع.

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

8. إنشاء سكربت نسخ احتياطي تلقائي

بدل تنفيذ أوامر النسخ يدويًا كل يوم، سننشئ سكربت Bash.

سيقوم السكربت بالمهام التالية:

1. إنشاء مجلد خاص بالنسخة الجديدة.
2. تصدير قاعدة بيانات WordPress.
3. ضغط ملفات الموقع.
4. إنشاء ملف تحقق SHA-256.
5. نقل النسخة المكتملة إلى مجلد النسخ.
6. حذف النسخ المحلية القديمة وفق سياسة الاحتفاظ.

هذا مثال تعليمي لموقع واحد على سيرفر واحد.

تثبيت الأدوات المطلوبة

تأكد من توفر الأدوات الأساسية:

sudo apt update
sudo apt install tar gzip coreutils cron

إنشاء ملف السكربت

sudo nano /usr/local/sbin/wordpress-backup.sh

أضف المحتوى التالي:

#!/usr/bin/env bash
set -Eeuo pipefail
umask 077

SITE_DIR="/var/www/example.com/html"
DB_NAME="wordpress_db"
BACKUP_ROOT="/var/backups/wordpress"
RETENTION_DAYS=14

STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
FINAL_DIR="$BACKUP_ROOT/$STAMP"
TEMP_DIR="$(mktemp -d "$BACKUP_ROOT/.incomplete-XXXXXX")"

cleanup() {
    rm -rf -- "$TEMP_DIR"
}
trap cleanup EXIT

if [[ ! -d "$SITE_DIR" ]]; then
    echo "ERROR: WordPress directory not found" >&2
    exit 1
fi

mariadb-dump \
    --single-transaction \
    --quick \
    "$DB_NAME" \
    | gzip -c > "$TEMP_DIR/database.sql.gz"

test -s "$TEMP_DIR/database.sql.gz"
gzip -t "$TEMP_DIR/database.sql.gz"

tar -czf "$TEMP_DIR/wordpress-files.tar.gz" \
    -C "$SITE_DIR" .

tar -tzf "$TEMP_DIR/wordpress-files.tar.gz" > /dev/null

(
    cd "$TEMP_DIR"
    sha256sum database.sql.gz wordpress-files.tar.gz \
        > SHA256SUMS
)

mv -- "$TEMP_DIR" "$FINAL_DIR"
trap - EXIT

find "$BACKUP_ROOT" \
    -mindepth 1 -maxdepth 1 \
    -type d -name '20??????T??????Z' \
    -mtime +"$RETENTION_DAYS" \
    -exec rm -rf -- {} +

echo "Backup completed: $FINAL_DIR"

ماذا يجب تعديله؟

غيّر:

SITE_DIR

إلى المسار الفعلي لموقع WordPress.

وغيّر:

DB_NAME

إلى اسم قاعدة بيانات الموقع.

أما RETENTION_DAYS فيحدد سياسة الاحتفاظ بالنسخ المحلية القديمة.

كيف يتصل السكربت بقاعدة البيانات؟

يعتمد هذا المثال على تشغيل السكربت بصلاحيات root، وعلى وجود مصادقة محلية مناسبة لحساب MariaDB الإداري، كما في بعض إعدادات Ubuntu الافتراضية.

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

هل السكربت مناسب لكل مواقع WordPress؟

لا.

هذا المثال مناسب كبداية لموقع واحد يستخدم MariaDB محليًا وجداول InnoDB.

أما المتاجر والمواقع ذات العمليات المستمرة أو الملفات الكبيرة، فقد تحتاج إلى آلية تحقق واتساق أكثر تقدمًا، وجدولة تراعي حركة البيانات.

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

9. ضبط صلاحيات السكربت

بعد حفظ الملف:

sudo chown root:root /usr/local/sbin/wordpress-backup.sh
sudo chmod 700 /usr/local/sbin/wordpress-backup.sh

بهذا يقتصر تشغيل السكربت وقراءته على المستخدم الإداري root.

فحص صياغة Bash

نفذ:

sudo bash -n /usr/local/sbin/wordpress-backup.sh

إذا لم تظهر أخطاء، فهذا يعني أن فحص الصياغة الأساسي نجح.

لكنه لا يضمن نجاح النسخ الفعلي.

10. تشغيل النسخة الأولى يدويًا

قبل إضافة مهمة مجدولة، شغّل السكربت:

sudo /usr/local/sbin/wordpress-backup.sh

إذا اكتمل بنجاح، سيعرض مسار النسخة الجديدة.

استعراض النسخ

sudo ls -lah /var/backups/wordpress

فحص محتويات النسخة

انتقل إلى مجلد النسخة الذي أنشأه السكربت، ثم نفذ:

sudo sha256sum -c SHA256SUMS

يجب أن يتم الفحص من داخل مجلد النسخة الذي يحتوي على الملفات الثلاثة.

يمكن أيضًا اختبار أرشيف الملفات:

sudo tar -tzf wordpress-files.tar.gz > /dev/null

وفحص سلامة ملف الضغط الخاص بقاعدة البيانات:

sudo gzip -t database.sql.gz

هذه الفحوص تكشف بعض أنواع التلف، لكنها لا تثبت وحدها أن الموقع قابل للاستعادة بالكامل.

11. جدولة النسخ باستخدام Cron

يوفر Cron طريقة لتنفيذ الأوامر وفق جدول زمني.

سنستخدمه لتشغيل السكربت مرة واحدة يوميًا.

فتح جدول Cron للمستخدم Root

sudo crontab -e

أضف السطر التالي:

0 3 * * * /usr/local/sbin/wordpress-backup.sh >> /var/log/wordpress-backup.log 2>&1

هذا المثال يشغّل السكربت يوميًا عند الساعة الثالثة صباحًا وفق المنطقة الزمنية التي يستخدمها Cron على السيرفر.

ماذا تعني الأرقام؟

• 0: الدقيقة صفر.
• 3: الساعة الثالثة.
• النجوم الثلاث: كل يوم من الشهر، وكل شهر، وكل يوم من الأسبوع.

هل الثالثة صباحًا أفضل وقت؟

ليس بالضرورة.

اختر وقتًا تقل فيه حركة الموقع، مع مراعاة توقيت السيرفر ومهام الصيانة الأخرى.

منع تداخل عمليات النسخ

إذا استغرق النسخ وقتًا طويلًا أو شغّل أحد المسؤولين السكربت يدويًا أثناء تشغيله المجدول، فقد تتداخل العمليتان.

يمكن استخدام flock لمنع تشغيل نسختين متزامنتين.

مثلًا، يمكن تعديل مهمة Cron إلى:

0 3 * * * /usr/bin/flock -n /run/wordpress-backup.lock /usr/local/sbin/wordpress-backup.sh >> /var/log/wordpress-backup.log 2>&1

تحقق من وجود flock على السيرفر قبل اعتماد هذا السطر.

12. مراقبة نجاح النسخ الاحتياطي

لا يكفي إنشاء مهمة Cron وتركها دون متابعة.

قد تفشل المهمة بسبب:

• امتلاء مساحة التخزين.
• توقف MariaDB.
• تغيّر صلاحيات الملفات.
• مشكلة في السكربت.
• تلف أحد الأرشيفات.
• انقطاع السيرفر أثناء التنفيذ.

قراءة سجل النسخ

sudo tail -n 50 /var/log/wordpress-backup.log

فحص أحدث نسخة

sudo ls -lt /var/backups/wordpress

أهمية التنبيهات

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

فنجاح جدولة Cron لا يعني بالضرورة نجاح عملية النسخ.

13. لماذا يجب الاحتفاظ بنسخة خارج VPS؟

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

لهذا ينبغي نقل نسخة إلى موقع مستقل.

يمكن استخدام:

• خادم تخزين منفصل عبر اتصال آمن.
• خدمة تخزين كائني تدعم التشفير والتحكم في الوصول.
• نظام نسخ احتياطي متخصص.
• مساحة تخزين خارجية يوفرها مزود الاستضافة.

قاعدة 3-2-1

من المبادئ الشائعة في التخطيط للنسخ الاحتياطية:

• الاحتفاظ بثلاث نسخ من البيانات، بما فيها النسخة الأصلية.
• استخدام وسيطين أو نظامي تخزين مختلفين.
• الاحتفاظ بنسخة واحدة على الأقل خارج الموقع الأساسي.

هذه قاعدة إرشادية، وليست ضمانًا مطلقًا للحماية.

ماذا عن تشفير النسخ؟

قد تحتوي النسخ على كلمات مرور وبيانات مستخدمين ومعلومات خاصة.

لذلك يجب تشفير النسخ المخزنة خارجيًا عندما تكون حساسية البيانات تستدعي ذلك، مع حماية مفاتيح التشفير والاحتفاظ بطريقة آمنة لاستعادتها.

ولا تحفظ مفتاح التشفير الوحيد داخل السيرفر الذي تحاول حمايته.

14. كيفية استعادة ملفات WordPress من نسخة احتياطية

نفّذ الخطوات التالية على سيرفر اختبار أو بيئة استعادة معزولة أولًا.

افترض أنك نقلت نسخة احتياطية إلى سيرفر الاختبار.

إنشاء مجلد الاستعادة

sudo mkdir -p /srv/wordpress-restore-test

استخراج الملفات

من داخل مجلد النسخة الاحتياطية:

sudo tar -xzf wordpress-files.tar.gz \
  -C /srv/wordpress-restore-test

يحتوي الأرشيف الذي أنشأه السكربت على محتويات WordPress.

التحقق من الملفات

sudo ls -lah /srv/wordpress-restore-test

تأكد من وجود ملفات مثل:

wp-config.php

wp-admin

wp-content

wp-includes

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

15. كيفية استعادة قاعدة بيانات MariaDB

لاختبار الاستعادة، أنشئ قاعدة بيانات جديدة بدل استخدام قاعدة الموقع الأصلي.

إنشاء قاعدة اختبار

sudo mariadb

ثم:

CREATE DATABASE wordpress_restore_test
CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

اخرج:

EXIT;

استيراد النسخة

من مجلد النسخة الاحتياطية:

gunzip -c database.sql.gz | sudo mariadb wordpress_restore_test

قد يتطلب الأمر طريقة مصادقة مختلفة إذا لم تكن المصادقة الإدارية المحلية متاحة.

التحقق من الجداول

sudo mariadb wordpress_restore_test

ثم:

SHOW TABLES;

إذا ظهرت جداول WordPress المتوقعة، فهذا مؤشر على نجاح الاستيراد.

لكنه لا يضمن وحده أن جميع وظائف الموقع تعمل.

16. اختبار الموقع المستعاد

بعد استعادة الملفات وقاعدة البيانات، يجب إعداد بيئة اختبار منفصلة.

قد تحتاج إلى:

• إعداد Nginx خاص ببيئة الاختبار.
• ضبط PHP-FPM.
• إنشاء مستخدم قاعدة بيانات للاختبار.
• تعديل wp-config.php ليتصل بقاعدة الاختبار.
• ضبط عنوان الموقع إذا كان الاختبار يستخدم دومينًا مختلفًا.
• منع إرسال رسائل البريد الحقيقية من بيئة الاختبار.
• منع محركات البحث من فهرسة نسخة الاختبار.
• تعطيل تكاملات الدفع والخدمات الخارجية الحساسة.

ماذا يجب اختباره؟

افتح الصفحة الرئيسية، ثم اختبر:

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

في المتاجر، يجب اختبار الطلبات والمنتجات والعملاء في بيئة آمنة دون تشغيل معاملات حقيقية.

17. استعادة الموقع على السيرفر الأصلي

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

اتبع خطة منظمة:

أولًا: حدد سبب العطل، خصوصًا إذا كان مرتبطًا باختراق أو تلف في التخزين.

ثانيًا: احتفظ بنسخة من الحالة الحالية قبل الكتابة فوقها، إن أمكن.

ثالثًا: اختر نسخة احتياطية سليمة ومناسبة زمنيًا.

رابعًا: أوقف أو قيّد العمليات التي قد تكتب بيانات جديدة أثناء الاستعادة.

خامسًا: استعد الملفات وقاعدة البيانات المتوافقتين.

سادسًا: اضبط الصلاحيات وبيانات الاتصال وإعدادات Nginx.

سابعًا: اختبر الموقع قبل إعادة استقبال الزيارات.

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

18. كم نسخة احتياطية يجب الاحتفاظ بها؟

لا توجد مدة واحدة مناسبة لجميع المواقع.

يمكن وضع سياسة تعتمد على أهمية البيانات ومعدل تغيّرها.

على سبيل المثال:

نوع النسخة	مثال لسياسة الاحتفاظ
يومية	آخر 14 يومًا
أسبوعية	آخر 4 أسابيع
شهرية	آخر 3 أشهر
قبل التحديثات	حتى التأكد من نجاح التحديث

هذه أمثلة تنظيمية، وليست متطلبات إلزامية.

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

لتنفيذ سياسة متعددة المستويات، تحتاج إلى إعداد إضافي أو أداة نسخ احتياطي تدعم ذلك.

19. أخطاء شائعة في النسخ الاحتياطي لمواقع WordPress

نسخ ملفات WordPress دون قاعدة البيانات

قد يؤدي ذلك إلى فقدان المقالات والإعدادات والمستخدمين عند الاستعادة.

حفظ جميع النسخ على VPS نفسه

لا يحمي من فقدان السيرفر بالكامل.

عدم اختبار الاستعادة

قد تكتشف وقت الطوارئ أن النسخة ناقصة أو تالفة.

الاحتفاظ بنسخة واحدة فقط

قد تكون النسخة الأحدث قد أُنشئت بعد حدوث مشكلة في البيانات.

تجاهل صلاحيات ملفات النسخ

قد يؤدي إلى كشف قاعدة البيانات أو كلمات المرور.

الاعتماد على Snapshot وحده

قد لا توفر اللقطات جميع خصائص النسخ المستقلة أو مدد الاحتفاظ المطلوبة.

عدم مراقبة Cron

قد تتوقف النسخ لأيام دون ملاحظة المشكلة.

حذف النسخ القديمة دون التحقق من الجديدة

قد يؤدي إلى فقدان آخر نسخة صالحة.

استخدام أوامر الاستعادة على قاعدة الإنتاج بالخطأ

قد يستبدل بيانات حديثة بنسخة قديمة.

لهذا يجب اختبار الأوامر والمسارات وأسماء قواعد البيانات بعناية.

20. هل الأفضل استخدام سكربت أم إضافة WordPress؟

يعتمد ذلك على مستوى خبرتك وطبيعة الموقع.

السكربت على مستوى السيرفر

يمنحك تحكمًا مباشرًا في الملفات وقاعدة البيانات والجدولة.

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

إضافات WordPress

قد توفر واجهة أسهل للجدولة والتخزين الخارجي والاستعادة.

لكن إمكاناتها تختلف من إضافة إلى أخرى، وقد تعتمد بعض الوظائف على إصدارات مدفوعة.

خدمات النسخ الاحتياطي المُدارة

قد توفر مراقبة وتنبيهات وتخزينًا خارجيًا وآليات استعادة أكثر تنظيمًا.

لكن يجب مراجعة شروط الخدمة ومستوى الحماية والتكلفة.

الأهم ليس اسم الأداة، بل التأكد من أن النسخ تعمل ويمكن استعادتها.

الأسئلة الشائعة حول النسخ الاحتياطي لـ WordPress

هل يكفي نسخ مجلد wp-content؟

لا. يحتوي wp-content على ملفات مهمة، لكن الاستعادة الكاملة تحتاج عادةً إلى قاعدة البيانات وملفات الإعداد وغيرها من مكونات الموقع.

هل يمكن نسخ WordPress دون إيقاف الموقع؟

نعم في كثير من الحالات، لكن اتساق البيانات يعتمد على طريقة النسخ ونوع الجداول والعمليات الجارية.

هل Cron مجاني؟

نعم، وهو من أدوات جدولة المهام الشائعة في أنظمة Linux.

هل يمكن إنشاء نسخة كل ساعة؟

نعم، لكن يجب مراعاة حجم البيانات والموارد ومعدل تغيّر الموقع.

هل النسخ الاحتياطي يبطئ VPS؟

قد يستهلك عمليات قراءة وكتابة ومعالجًا وذاكرة، خصوصًا في المواقع الكبيرة. لهذا يُفضل اختيار جدول مناسب ومراقبة تأثيره.

هل أحتاج إلى نسخ قاعدة البيانات والملفات معًا؟

نعم، لاستعادة موقع WordPress نموذجي بصورة كاملة.

هل يمكن استعادة WordPress على سيرفر مختلف؟

نعم، بشرط تجهيز بيئة متوافقة ونقل الملفات وقاعدة البيانات وضبط الإعدادات والعناوين عند الحاجة.

هل يمكن الاعتماد على النسخ التي يوفرها مزود VPS؟

يمكن أن تكون جزءًا من خطة الحماية، لكن يجب مراجعة نطاقها ومدة الاحتفاظ وإمكانية الاستعادة، والاحتفاظ بنسخ مستقلة عند الحاجة.

هل النسخ المضغوطة آمنة؟

الضغط يقلل الحجم لكنه لا يوفر تشفيرًا بحد ذاته. يجب حماية الملفات بالصلاحيات والتشفير المناسب.

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

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

الخلاصة

إنشاء نسخ احتياطية تلقائية لموقع WordPress على VPS خطوة أساسية لحماية المحتوى والملفات وقاعدة البيانات.

تعلمنا في هذا الدليل كيفية تصدير MariaDB باستخدام mariadb-dump، وأرشفة ملفات WordPress، وإنشاء سكربت Bash لتنفيذ النسخ بصورة منتظمة.

كما شرحنا جدولة المهمة باستخدام Cron، ومراجعة السجلات، وفحص سلامة الملفات، والاحتفاظ بنسخ خارج السيرفر.

والأهم أننا تعرفنا على كيفية اختبار استعادة ملفات WordPress وقاعدة البيانات في بيئة منفصلة قبل الحاجة إلى تنفيذ استعادة حقيقية.

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

وإذا كنت تتابع سلسلة إدارة السيرفرات على حكاية تقنية، فننصحك بقراءة الأدلة السابقة:

• ما هو VPS؟ دليل شامل لفهم السيرفرات الافتراضية.

• كيفية إعداد سيرفر Ubuntu وتأمينه باستخدام SSH وUFW.
• كيفية تثبيت Nginx على Ubuntu وربط الدومين وتفعيل SSL مجانًا.
• كيفية تثبيت WordPress على Ubuntu باستخدام Nginx وPHP وMariaDB.
• كيفية تسريع WordPress على VPS باستخدام Nginx وPHP-FPM وRedis.

هذا المقال بالتعاون مع فريق حكاية هوست

المصادر الرسمية

• WordPress – دليل النسخ الاحتياطي
• WordPress – نسخ ملفات الموقع
• WordPress – نسخ قاعدة البيانات واستعادتها
• MariaDB – توثيق mariadb-dump
• MariaDB – دليل إنشاء النسخ الاحتياطية
• Ubuntu – دليل crontab