النسخ الاحتياطي لمتجرك الإلكتروني

كثير من أصحاب المتاجر يبنون استراتيجية نسخ احتياطي «كافية» لموقع عادي، ثم يفاجَؤون أن متجرهم يفقد بيانات حقيقية رغم وجود نسخ. السبب أن المتجر كائن حيّ: بينما تنام، تدخل طلبات، تُسجَّل حسابات، تتغيّر كميات المخزون، وتُحدَّث حالات الشحن. أي نسخة لا تواكب هذا الإيقاع تترك فجوة قد تكلّفك مالًا وثقة عملاء وربما التزامًا قانونيًا. في هذا المرجع نبني استراتيجية نسخ مصمّمة خصّيصًا للمتاجر: ماذا تنسخ بالضبط، كم مرّة حسب حجم مبيعاتك، أين تخزّن، كيف تؤتمت دون أن تُثقل المتجر وقت الذروة، وكيف تستعيد بأقل توقّف حين تقع الكارثة.

لماذا نسخ المتجر أحرج من نسخ أي موقع آخر؟

الموقع التعريفي أو المدوّنة محتواه شبه ثابت: تنشر مقالًا اليوم، وقد لا يتغيّر شيء لأسبوع. إن فقدت يومًا من بياناته، فأسوأ ما يحدث غالبًا هو إعادة كتابة منشور. المتجر مختلف جوهريًا: بياناته معاملاتية (transactional) وتتغيّر باستمرار، وكل سجلّ فيها يمثّل مالًا والتزامًا تجاه عميل حقيقي ينتظر منتجه.

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

ثلاثة أبعاد تجعل الخسارة مضاعفة

البُعد الأول هو المال المباشر: كل طلب مفقود = قيمة بيع + احتمال رفع مبلغ (Chargeback) لاحقًا حين يحتجّ عميل دفع ولم يصله شيء. البُعد الثاني هو الثقة: العميل الذي دفع ولم يجد أثرًا لطلبه نادرًا ما يعود، وغالبًا يكتب تجربته للعالم. البُعد الثالث هو الامتثال: بيانات العملاء (الأسماء والعناوين والهواتف) بيانات شخصية تخضع لأنظمة حماية البيانات، وفقدانها أو تسريبها أثناء استعادة فوضوية قد يحمّلك التزامات تبليغ وغرامات.

معدّل التغيّر هو الفرق الحاسم

الفكرة المحورية: ما يحدّد صعوبة النسخ ليس حجم البيانات بل سرعة تغيّرها. مدوّنة بآلاف المقالات لكنها لا تتغيّر إلا أسبوعيًا أسهل في النسخ من متجر صغير يستقبل طلبًا كل بضع دقائق. كلّما زادت حركة متجرك، صَغُر الزمن الذي تتحمّل فقدانه، وارتفعت أهمّية النسخ المتكرّر شبه الفوري لجداول الطلبات تحديدًا. هذا المفهوم سنُعطيه اسمًا دقيقًا بعد قليل (RPO)، لكن جوهره أن المتجر النشط لا يحتمل «نسخة يومية واحدة» إطلاقًا.

ماذا تنسخ بالضبط في المتجر؟

الخطأ الأشيع هو نسخ جزء واحد فقط. متجر WooCommerce — كأي موقع ووردبريس ديناميكي — يتكوّن من نصفين متلازمين: ملفات على نظام الملفات، وقاعدة بيانات تحوي كل المحتوى المعاملاتي. نسخ الملفات وحدها يعطيك «متجرًا فارغًا» بلا طلبات ولا منتجات؛ ونسخ قاعدة البيانات وحدها يعطيك «بيانات بلا واجهة». المتجر العامل يحتاج النصفين معًا ومتزامنين.

مكوّنات نسخة المتجر الكاملة

ما الذي تخزّنه قاعدة بيانات المتجر؟

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

ملاحظة مهمّة: WooCommerce الحديث يستخدم تخزين الطلبات عالي الأداء (HPOS) في جداول مخصّصة (wc_orders وأخواتها) بدل جداول posts/postmeta القديمة. أيًّا كان وضع متجرك، فإن نسخة قاعدة البيانات الكاملة تلتقط الجداول الصحيحة تلقائيًا — لا تحاول نسخ «جداول مختارة» يدويًا في متجر، فقد تفوتك جداول حرجة.

تزامن النصفين: لماذا يهمّ في المتجر أكثر من غيره؟

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

كم مرّة تنسخ متجرك؟ التكرار حسب حجم المبيعات

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

جدول التكرار حسب حركة المتجر

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

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

مفهوم RPO و RTO: العمود الفقري لقرار التكرار

كل قرارات النسخ تنبثق من رقمين يجب أن تحدّدهما بوعي لا بالتخمين:

طبّق هذا على متجرك بسؤال صريح: هل تقبل بخسارة طلبات ساعة كاملة؟ ساعتين؟ يوم؟ إجابتك هي RPO لديك، وهي ما يحدّد تكرار النسخ. متجر يبيع بـ١٠٠ ريال في الساعة قد يتحمّل RPO ساعتين؛ متجر يبيع بآلاف في الساعة لا يتحمّل أكثر من دقائق، ويحتاج نسخًا تزايديًا مستمرًا للطلبات. أما RTO فيحدّد طريقة الاستعادة لا تكرارها: إن كان متجرك لا يحتمل أكثر من ساعة توقّف، فأنت بحاجة لقطة خادم سريعة الاستعادة، لا نسخة كاملة تستغرق نقلها ساعات.

النسخ المجدول مقابل النسخ قبل التغييرات

التكرار المنتظم يحميك من الأعطال المفاجئة، لكنه لا يكفي وحده. اجعل قاعدتك الثابتة: خذ نسخة كاملة يدوية قبل أي عملية محفوفة بالمخاطر — تحديث WooCommerce أو إضافة دفع، تغيير القالب، تشغيل استعلام على قاعدة البيانات، أو هجرة المتجر. هذه «نسخة الأمان قبل القفزة» أنقذت متاجر لا تُحصى. وإن كنت لا تزال في مرحلة الإعداد، فالنسخ الاحتياطي جزء أصيل من إطلاق متجر سليم؛ راجع دليل إطلاق متجر WooCommerce لترتيب الأولويات من البداية.

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

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

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

قاعدة 3-2-1: لماذا نسخة على الخادم لا تكفي؟

قاعدة 3-2-1 هي المعيار الذهبي عالميًا لحماية البيانات، وتنطبق على المتجر بقوّة مضاعفة. تنصّ على: 3 نسخ من بياناتك، على 2 نوعين مختلفين من الوسائط/المواقع، مع 1 نسخة على الأقل خارج الموقع (Off-site). ولدت هذه القاعدة من خبرة متراكمة في استعادة البيانات: أغلب حالات الفقدان الكامل تحدث حين تجتمع كل النسخ في سلّة واحدة، فيكفي عطل واحد ليمحوها جميعًا.

تفكيك القاعدة للمتجر

السبب الجوهري: النسخة على الخادم تسقط مع الخادم

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

لنرَ منطق القاعدة الثلاثي مرئيًا — كل محور يحمي من فشل لا يحميه الآخر:

مثال تطبيقي لمتجر WooCommerce

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

طرق النسخ الاحتياطي للمتجر

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

الطبقات الثلاث الموصى بها للمتجر

ادمج الطرق في ثلاث طبقات مستقلّة، كلٌّ بآلية وموقع وصلاحيات مختلفة:

لماذا لا تكفي اللقطات (Snapshots) وحدها؟

لقطة المضيف مريحة وسريعة، لكنها ليست نسخة كاملة بالمعنى الدقيق: فهي غالبًا مرتبطة بالبنية نفسها، فإن فشل التخزين الأساسي قد تسقط معه اللقطة. كما تلتقط «الحالة كما هي» بما فيها أي اختراق أو فساد بيانات لحظة اللقطة. اعتبرها طبقة استرجاع سريع ممتازة، لكن لا تجعلها بديلًا عن نسخة كاملة Off-site تنقلها لمزوّد آخر تمامًا عند الحاجة.

اختيار مضيف يقدّم نسخًا منتظمة ولقطات سهلة الاستعادة عامل مهمّ في القرار من الأساس؛ والمتجر يستفيد أيضًا من استضافة سريعة تجعل الاستعادة والتشغيل سلسين، وهو ما يلتقي مع تسريع متجر WooCommerce.

مقارنة إضافات النسخ الاحتياطي للمتاجر

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

لماذا النسخ التزايدي مهمّ للمتاجر؟

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

النسخ التلقائي على مستوى الاستضافة

كثير من خطط الاستضافة المُدارة لووردبريس/WooCommerce تقدّم نسخًا تلقائية يومية وأحيانًا لقطات أكثر تكرارًا. ميزتها أنها تعمل خارج الموقع منطقيًا ولا تستهلك موارد PHP الخاصّة بمتجرك أثناء النسخ، فلا تبطئ تجربة الزبائن. عيبها أنها قد تكون على البنية نفسها. القاعدة: استخدم نسخ المضيف كطبقة مريحة سريعة، لكن املك دائمًا نسختك الخاصّة Off-site ولا تعتمد على المضيف وحده.

النسخ بالأوامر: نسخة دقيقة تحت سيطرتك

للمتاجر على VPS أو من يريد تحكّمًا كاملًا، النسخ بالأوامر عبر SSH يمنحك دقّة لا تضاهيها الإضافات. القاعدة الذهبية للمتاجر الحيّة: شغّل هذه الأوامر في ساعات الهدوء بعيدًا عن الذروة — mysqldump يضع أقفالًا قد تبطئ الطلبات الجارية، وtar على مجلّد كبير يستهلك I/O. حدّد نافذة منخفضة الحركة (مثلًا الفجر بتوقيت أغلب زبائنك) قبل الجدولة.

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

استخدم wp db export (الأذكى لووردبريس، يقرأ الإعداد تلقائيًا) أو mysqldump المباشر:

# الطريقة المفضّلة عبر WP-CLI (يقرأ wp-config.php تلقائيًا)
wp db export /backups/store-db-$(date +%F-%H%M).sql --add-drop-table

# أو mysqldump مباشرة — مع خيارات آمنة للمتجر الحيّ
mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  --default-character-set=utf8mb4 \
  -u DB_USER -p DB_NAME > /backups/store-db-$(date +%F-%H%M).sql

الخيارات هنا ليست تجميلية: --single-transaction يأخذ لقطة متّسقة دون قفل الجداول (حيوي لمتجر حيّ كي لا توقف الطلبات أثناء النسخ)، و--quick يقلّل استهلاك الذاكرة على القواعد الكبيرة، و--routines --triggers يلتقطان الإجراءات والمشغّلات التي تستخدمها بعض إضافات WooCommerce، وutf8mb4 يحافظ على الرموز والإيموجي في أسماء المنتجات والعناوين.

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

# أرشفة ملفات الموقع مع استبعاد الكاش والنسخ القديمة لتقليل الحجم
tar -czf /backups/store-files-$(date +%F).tar.gz \
  --exclude='wp-content/cache' \
  --exclude='wp-content/uploads/backups' \
  -C /var/www/store .

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

نقل النسخة خارج الموقع (Off-site)

لا قيمة للنسخة إن بقيت على الخادم. ارفعها فورًا لمزوّد بعيد عبر rsync (لخادم آخر) أو أداة سحابة (لتخزين كائنات متوافق مع S3):

# نقل لخادم بعيد عبر rsync فوق SSH
rsync -avz --progress /backups/ backupuser@offsite-host:/remote/backups/

# أو رفع لسحابة كائنات متوافقة مع S3
aws s3 cp /backups/store-db-$(date +%F-%H%M).sql \
  s3://my-store-backups/db/ --storage-class STANDARD_IA

الجدولة بـ cron بعيدًا عن الذروة

اجمع الأوامر في سكربت واحد، ثم جدوله في الفجر. عدّل التوقيت ليطابق أهدأ ساعات متجرك:

# تحرير جدول cron
crontab -e

# نسخة قاعدة بيانات كل 3 ساعات (RPO صغير للطلبات)
0 */3 * * * /usr/local/bin/wp db export /backups/db-$(date +\%F-\%H).sql --path=/var/www/store

# نسخة كاملة (ملفات + قاعدة) يوميًا 4 فجرًا + رفعها Off-site
0 4 * * * /usr/local/bin/store-backup.sh >> /var/log/store-backup.log 2>&1

لاحظ تكرار قاعدة البيانات (كل 3 ساعات) المنفصل عن النسخة الكاملة (يوميًا): تحمي الطلبات بكثافة دون نسخ الملفات الثقيلة كل مرّة — تطبيق عملي لمبدأ RPO الذي شرحناه.

تشفير النسخ وحمايتها

نسخة المتجر تحوي بيانات عملاء شخصية، لذا حمايتها التزام لا رفاهية. نسخة احتياطية غير مشفّرة مسرّبة = تسريب بيانات كامل لقاعدة عملائك. شفّر النسخ قبل رفعها Off-site:

# تشفير أرشيف النسخة بـ GPG قبل الرفع
gpg --symmetric --cipher-algo AES256 \
  /backups/store-files-$(date +%F).tar.gz

# استعادة لاحقًا
gpg --decrypt store-files-2026-06-13.tar.gz.gpg > store-files.tar.gz

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

اختبار الاستعادة: النسخة التي لم تُجرَّب ليست نسخة

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

كيف تختبر الاستعادة دون لمس المتجر الحيّ؟

# استعادة قاعدة بيانات على بيئة تجريبية
wp db import /backups/store-db-2026-06-13.sql --path=/var/www/staging

# تحقّق سريع من سلامة الطلبات بعد الاستعادة
wp wc shell --user=admin --path=/var/www/staging
# أو استعلام مباشر لعدّ الطلبات
wp db query "SELECT COUNT(*) FROM wp_wc_orders;" --path=/var/www/staging

اجعل الاختبار دوريًا

اختبار مرّة واحدة لا يكفي، فالمتجر يتغيّر والإضافات تُحدَّث. اجعل اختبار الاستعادة عادة ربع سنوية على الأقل (وشهرية للمتاجر الحرجة). كل اختبار يفعل أمرين: يثبت أن نسخك سليمة، ويقيس RTO الفعلي حتى تعرف كم سيستغرق المتجر للعودة وقت الكارثة الحقيقية — قبل أن تحتاجها تحت الضغط.

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

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

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

الاستعادة بأقل توقّف وقت الكارثة

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

قائمة تحقّق الاستعادة

الخطوة الحرجة: سدّ فجوة الطلبات

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

سيناريوهات الاستعادة الشائعة

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

طبقات أمان المتجر والنسخ معًا

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

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

أخطاء شائعة في نسخ المتاجر

نصائح خبير

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

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

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

كم مرّة يجب أن أنسخ متجري؟ حسب حجم مبيعاتك (RPO). متجر ناشئ قد يكفيه نسخ يومي، أمّا المتجر النشط فيحتاج نسخ قاعدة بيانات كل بضع ساعات أو شبه فوري، مع نسخة كاملة يومية. اسأل نفسك: «كم طلبًا أتحمّل فقده؟» — الإجابة تحدّد التكرار.

هل نسخة الاستضافة التلقائية تكفي وحدها؟ لا. نسخ المضيف طبقة مريحة سريعة الاستعادة، لكنها غالبًا على البنية نفسها وقد لا تكون مضمونة تعاقديًا. تطبيقًا لقاعدة 3-2-1، يجب أن تملك نسخة Off-site مستقلّة تنجو حتى لو تعطّل المضيف أو اختُرق حسابك أو علّق خدمتك.

ما قاعدة 3-2-1 ولماذا تهمّ المتجر؟ ثلاث نسخ، على وسيطين مختلفين، وواحدة على الأقل خارج الموقع. تهمّ المتجر لأن أكثر سيناريوهات الفقدان الكامل تأتي من اجتماع كل النسخ في مكان واحد؛ النسخة Off-site هي الوحيدة التي تنجو من اختراق الحساب أو فشل المضيف أو الفدية.

هل أنسخ المتجر وقت الذروة؟ لا. النسخ بـmysqldump وtar يستهلك موارد ويضع أقفالًا قد تبطئ الطلبات أو تفقدها. جدول النسخ الثقيل في ساعات الهدوء (الفجر غالبًا)، واستخدم --single-transaction لـmysqldump كي تأخذ لقطة متّسقة دون قفل الجداول على متجر حيّ.

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

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

لماذا يجب أن أختبر الاستعادة؟ لأن نسخة لم تُجرَّب استعادتها قد تكون تالفة أو ناقصة دون أن تدري، فتكتشف ذلك في أسوأ لحظة. اختبر الاستعادة دوريًا على بيئة تجريبية للتأكّد من سلامة النسخ ولقياس وقت الاستعادة الفعلي (RTO) قبل أن تحتاجه.

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

كيف أحمي النسخ نفسها من السرقة؟ شفّر النسخ (مثلًا بـGPG/AES256) قبل رفعها Off-site لأنها تحوي بيانات عملاء، وخزّنها خارج الجذر العام للموقع كي لا تُنزَّل عبر المتصفّح، واستخدم صلاحيات ومفاتيح وصول منفصلة كي لا يصل اختراق الموقع إلى تخزين النسخ.

هل أحتاج نسخًا أكثر في مواسم التخفيضات؟ نعم. الذروة تعني طلبات أكثر وRPO أصغر، فكل ساعة تحوي مبيعات تعادل أيامًا عادية. كثّف تكرار النسخ مؤقتًا (كل ساعة أو أقل لقاعدة البيانات) خلال مواسم الذروة، ثم عُد للجدول المعتاد بعدها.

الخلاصة

النسخ الاحتياطي للمتجر ليس مهمّة تُنجَز مرّة، بل منظومة حيّة تواكب إيقاع مبيعاتك. ابدأ بتحديد RPO وRTO بوعي، انسخ الملفات وقاعدة البيانات (بطلباتها وعملائها) معًا ومتزامنين، اضبط التكرار حسب حجم المبيعات مع تكثيف خاص لجدول الطلبات، طبّق 3-2-1 بنسخة Off-site مشفّرة، شغّل النسخ بعيدًا عن الذروة، والأهمّ: اختبر الاستعادة دوريًا حتى تثق أن متجرك سيعود بأقل توقّف وقت الكارثة. النسخة المُختبَرة هي الفرق بين كارثة عابرة وخسارة دائمة.

استضافة مُدارة لووردبريس/WooCommerce مع لقطات ونسخ تلقائية تجعل بناء هذه المنظومة أسهل وأسرع وأأمن. ادمجها مع دليل النسخ الاحتياطي للموقع لترسّخ الأساسيات.

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

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

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