النسخ الاحتياطي

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

لا، لا يوجد خيار نسخ احتياطي يومي ‎premium‎. على الاستضافة المشتركة، النسخ الاحتياطي اليومي مشمول في خطة ‎Pro‎؛ وتتضمّن خطة ‎Business‎ نسخة احتياطية أسبوعية.

حسب خطتك، يمكنك الاستعادة من cPanel. في الحالات الأخرى، يقوم فريق الدعم لدينا بالاستعادة بناءً على طلبك.

تعتمد مدة الاحتفاظ على خطتك وخياراتك. تواصل مع الدعم لمعرفة مدة الاحتفاظ المطبّقة على عرضك.

نعم، تتوفّر اللقطات (snapshots) حسب خطة VPS (VPS Power و VPS Business). تتيح لك تجميد حالة الخادم قبل إجراء عملية حسّاسة.

لديك صلاحية root: يمكنك أتمتة نسخك الاحتياطية باستخدام أدوات مثل rsync أو restic أو borgbackup، نحو مساحة تخزين بعيدة من اختيارك.

اجمع بين تصدير أحجام Docker وأداة نسخ احتياطي تزايدي مثل Restic أو BorgBackup. أوقف الحاوية مؤقتًا (أو استخدم `docker exec` لأخذ نسخة نظيفة من قواعد البيانات)، ثم اضغط الحجم وأرسل الأرشيف إلى تخزين بعيد. جدوِل العملية عبر ‎cron أو بنيّة CI/CD، وخزِّن ملفّات ‎`docker-compose‎.yml` و‎`‎.env` في مستودع ‎git خاص.

تُحفظ النسخ الاحتياطية المضمّنة في خطط الاستضافة داخل بنية ‎ServOrbit‎ التحتية. من خادم ‎VPS‎، يمكنك إعداد ‎Restic‎ أو ‎BorgBackup‎ لإرسال نسخ مشفّرة خارج الموقع إلى ‎S3‎ أو ‎Backblaze B2‎ أو ‎Scaleway Object Storage‎ أو خادم ‎SFTP‎ تختاره بنفسك. يُنصح بهذا النهج بشدة لأي بيانات حساسة. تتوفر قوالب جاهزة لهذه الأدوات في ‎Marketplace ServOrbit‎.

نعم لقواعد MySQL وMariaDB: من مساحة العميل (الخادم الافتراضي ← إدارة ← قواعد البيانات) تفعّل جدولة يومية أو أسبوعية، وتختار الساعة ومدّة الاحتفاظ، وتُودَع الأرشيفات في مساحة النسخ الاحتياطي الخاصة بك. وتتوفّر أيضاً نسخة فورية يؤكَّد تشغيلها بكلمة المرور ورمز لمرة واحدة — مفيدة قبل عملية حسّاسة مباشرةً مثل ترقية إصدار رئيسي للمحرّك. أمّا المحرّكات الأخرى (PostgreSQL وMongoDB وغيرها) فلا تكتشفها هذه الأداة: جهّز تصديراً خاصاً بك وأرسله إلى تخزين بعيد.

نعم، على استضافات ‎cPanel‎ من ‎ServOrbit‎، يتيح ‎JetBackup‎ استعادة دقيقة: تختار بالتحديد الملف أو المجلد المراد استعادته من قائمة النسخ الاحتياطية المتاحة، دون المساس ببقية حسابك. أما على خادم ‎VPS‎، فإن استعادة لقطة (‎snapshot‎) تشمل اللقطة بأكملها: فهي تستبدل الحالة الحالية للخادم، دون استخراج ملف بملف. وأما الخوادم المخصّصة فلا تتوفّر لها لقطات ولا نسخ احتياطية مقدَّمة: تتم استعادة أي ملف من نسخك الاحتياطية الخاصة. على ‎cPanel‎، تُجنّبك هذه الدقة الكتابة فوق البيانات الحديثة عند استرجاع عنصر واحد.

تتضمن أداة Restic أمر `restic check` الذي يفحص المستودع ويكشف أي تلف في الكتل المشفرة دون الحاجة إلى استعادة البيانات. جدوِل هذا الفحص عبر مؤقت systemd أو مهمة cron أسبوعية، وأرسل مخرجاته إلى قناة تنبيه (بريد إلكتروني، webhook في n8n، أو ntfy). إذا أرجع الأمر رمز خطأ غير صفري، تأكد سريعاً من إمكانية الاسترداد الفعلي بإجراء استعادة تجريبية في مجلد مؤقت قبل وقوع أي حادثة.

في ‎cPanel، يتيح ‎JetBackup الاستعادة إلى مجلد وجهة مختلف بدلاً من الكتابة فوق الموقع الأصلي. اختر خيار «استعادة إلى» وحدد دليلاً مؤقتاً؛ يمكنك بعدها مقارنة الملفات المُستعادة بملفات الإنتاج قبل أي تبديل. تضمن هذه الطريقة بقاء موقعك متاحاً طوال فترة التحقق. إذا كنت بحاجة إلى مساعدة، افتح تذكرة من فضاء عميلك.

لقطة VPS هي صورة فورية لقرص الخادم بأكمله، مثالية قبل أي عملية محفوفة بالمخاطر؛ تُخزَّن على نفس البنية التحتية ويمكن استعادتها بسرعة. أما JetBackup (المتاح على استضافة cPanel) فيوفر نسخاً احتياطية تدريجية تلقائية لملفاتك وقواعد بياناتك وبريدك الإلكتروني، مخزنة في فضاء بعيد، مع إمكانية الاستعادة ملفاً بملف من cPanel. لحماية شاملة على VPS، ادمج اللقطات مع حل نسخ احتياطي خارجي (Restic أو BorgBackup).

تتوفر عدة مقاربات بحسب مستوى الدقة المطلوب. تتمثل الطريقة الأكثر مباشرةً في استخدام `docker run --rm -v <volume>:/data alpine tar czf - /data` لأرشفة حجم في ملف، ثم نقله إلى تخزين خارجي عبر `rsync` أو `rclone` (المتوافق مع ‎S3 و‎SFTP وغيرهما). للحصول على نسخ احتياطية متسقة لقواعد البيانات، فضّل تفريغًا على مستوى التطبيق (`pg_dump` أو `mysqldump`) بدلًا من نسخ الحجم الخام. أتمت هذه النسخ الاحتياطية بمهمة ‎cron يومية واحتفظ بأجيال متعددة. تتيح ‎ServOrbit أيضًا لقطات ‎VPS تُنشأ عند الطلب من لوحة العملاء، يمكن استخدامها كشبكة أمان إضافية.

نعم، يمكنك تماماً استعادة نسخة احتياطية من ‎VPS‎ على آخر — مثلاً للترقية إلى خطة أقوى أو لإنشاء بيئة استعادة الكوارث. **مع ‎JetBackup‎** (رخصة اختيارية بـ95 درهم/شهر، على خادم يعمل بـ‎cPanel‎): اتصل بواجهة ‎JetBackup‎، اختر النسخة الاحتياطية المراد استعادتها، واختر **استعادة على خادم آخر**. أدخل عنوان ‎IP‎ لـ‎VPS‎ الوجهة وبيانات ‎SSH‎. يقوم ‎JetBackup‎ تلقائياً بنقل البيانات واستعادتها. **بدون ‎JetBackup‎**: صدّر نسختك الاحتياطية (لقطة أو أرشيف ‎tar‎) من لوحة التحكم، انقلها إلى ‎VPS‎ الوجهة عبر `rsync` أو `scp`، ثم استعِدها يدوياً. لاحظ أن عناوين ‎IP‎ تتغير عند الترحيل: لا تنسَ تحديث ‎DNS‎ وإعدادات تطبيقاتك بعد الاستعادة.

أحجام ‎Docker‎ هي المكان الذي تخزّن فيه تطبيقات ‎Docker‎ بياناتها الدائمة. إليك ثلاثة أساليب لنسخها احتياطياً. **الأسلوب 1 — نسخ مجلد الحجم مباشرةً**: تُخزَّن أحجام ‎Docker‎ في `/var/lib/docker/volumes/`. يمكن نسخها بـ`tar`: `tar czf /نسخ_احتياطي/حجمي-$(date +%Y%m%d).tar.gz -C /var/lib/docker/volumes/حجمي/_data .` **الأسلوب 2 — التصدير عبر حاوية مؤقتة** (موصى به): يعمل دون معرفة المسار الفعلي للحجم: `docker run --rm -v حجمي:/data -v /نسخ_احتياطي:/backup alpine tar czf /backup/حجمي-$(date +%Y%m%d).tar.gz -C /data .` **الأسلوب 3 — لقطة التطبيق** (لقواعد البيانات): استخدم الأداة الأصيلة لقاعدة البيانات لتصدير نسخة متسقة. مثلاً لـ‎PostgreSQL‎ في حاوية: `docker compose exec -T db pg_dump -U مستخدم قاعدتي | gzip > /نسخ_احتياطي/قاعدة-$(date +%Y%m%d).sql.gz` للأتمتة، أضف الأمر في سكريبت وجدوله بـ‎cron‎. ثم زامن مع تخزين بعيد باستخدام ‎rclone‎ للحماية خارج الموقع.

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

يقوم الاستنساخ الخالي (‏`git clone --bare <url>`) بنسخ كامل السجل والفروع والعلامات دون شجرة عمل، مما يجعله الصيغة المثالية للأرشفة والاستعادة. من خادم ‎VPS‎ الخاص بك، جدوّل مهمة ‎cron‎ تنفّذ ‏`git clone --mirror`‏ في مجلد النسخ الاحتياطية، ثم اضغط الأرشيف وانقله إلى تخزين خارجي (‏‎S3‎‏ أو ‎SFTP‎). للمزيد، راجع صفحة ‏`/vps-cloud`‏.

قبل أي تحديث، أرشف مجلد ‏`/etc/postfix/`‏ (الإعدادات الرئيسية) ومجلد ‏`/etc/opendkim/`‏ أو ‏`/etc/dkim/`‏ (مفاتيح ‎DKIM‎) وملف ‏`/etc/aliases`‏. استخدم الأمر ‏`tar -czf postfix-backup-$(date +%F).tar.gz /etc/postfix /etc/opendkim`‏ ثم انقل الأرشيف إلى مكان خارج الخادم باستخدام ‏`rsync`‏ أو ‏`scp`‏. احتفظ كذلك بسجلات ‎DNS TXT‎ المقابلة لإعادة نشر المفاتيح عند الحاجة. تواصل مع فريق الدعم عبر [email protected] للحصول على مساعدة في الاستعادة.

بالنسبة لـ‏‎PrivateGPT‎‏، انسخ مجلد ‏`local_data/`‏ (المستندات المفهرسة وقاعدة البيانات المتجهية) إلى جانب ملف الإعداد ‏`settings.yaml`‏. وبالنسبة لـ‏‎LocalAI‎‏، أرشف مجلد النماذج (عادةً ‏`models/`‏) وملفات إعداد ‎YAML‎ إن وُجدت. جدوّل مهمة ‏`rsync`‏ أو استخدم ‎Restic‎ لنقل هذه المجلدات إلى تخزين خارجي؛ لاحظ أن ملفات النماذج قد تكون كبيرة الحجم فاستفد من إلغاء التكرار. اعثر على قوالب ‎PrivateGPT‎ و‎LocalAI‎ في ‎Marketplace ServOrbit‎ عبر ‏`/vps-cloud`‏.

أوقف أولًا حاوية ‎Mattermost (`docker compose stop mattermost`) لتفادي أي كتابة جارية، ثم نفّذ أمر التفريغ: `docker exec mattermost-db pg_dump -U mmuser mattermost | gzip > mattermost-backup-$(date +%Y%m%d)‎.sql‎.gz`. احفظ الأرشيف خارج الخادم (تخزين كائنات، نقل بـ`scp`/`rsync`) قبل البدء بالترقية. للاستعادة: `gunzip -c mattermost-backup-YYYYMMDD‎.sql‎.gz | docker exec -i mattermost-db psql -U mmuser mattermost`. يأخذ خيار النسخ الاحتياطي في ‎ServOrbit لقطة كاملة للقرص — فعّله أيضًا لتغطية أحجام الملفات.

يخزّن Chatwoot افتراضيًا الملفات في مجلد `storage/` داخل الحاوية وتُفقد عند إعادة إنشائها. Cloudflare R2 متوافق مع S3 بلا رسوم خروج. تحذير: عدم توافق بين Active Storage وR2 يتسبب في فقدان صامت للمرفقات (issue #13299). الحل: إضافة `request_checksum_calculation: "when_required"` و`response_checksum_validation: "when_required"` في `config/storage.yml` مع المتغيرات البيئية المناسبة. أعد تشغيل الحاويات واختبر رفع ملف من تذكرة.

يخزّن Docmost بياناته في قاعدة PostgreSQL وملفاته في حجم Docker أو تخزين S3. للنسخ الاحتياطي الكامل: (1) نفّذ `pg_dump -U docmost docmost > docmost_backup_$(date +%Y%m%d).sql`، (2) أرشف حجم تخزين الملفات أو صدّر bucket R2/S3، (3) جدوِل النسخ الاحتياطي في cron وأرسل الأرشيفات إلى تخزين خارجي (S3 أو Backblaze B2 أو SFTP).

يخزّن ‎Stalwart بياناته في مجلد قابل للضبط (افتراضيًا ‎`/opt/stalwart-mail/data`): أوقف الخدمة، وانسخ هذا المجلد إلى مساحة تخزين بعيدة باستخدام ‎Restic أو ‎BorgBackup، ثم أعد التشغيل. احرص على تضمين شهادات ‎TLS (‎Let's Encrypt أو المخصصة)، ومفاتيح ‎DKIM (في المجلد الفرعي ‎`dkim/`)، وملف الإعداد `config.toml`. في حالة تثبيت ‎Docker، جَبِّل مجلد البيانات كحجم مُسمَّى واحتفظ بنسخة احتياطية من هذا الحجم. جدوِّل النسخ الاحتياطية اليومية عبر ‎cron وتحقق بشكل دوري من استعادتها على خادم ‎VPS تجريبي.

يجب أن تكون تكرارية النسخ الاحتياطية متناسبة مع **RTO** (هدف وقت الاسترداد) و**RPO** (هدف نقطة الاسترداد) — كم من الوقت يمكنك تحمّل التوقف، وكم من البيانات يمكنك تحمّل خسارتها. **توصيات عملية:** | نوع الموقع | التكرار | الاحتفاظ | |---|---|---| | موقع إعلاني ثابت | مرة/أسبوع | 4 أسابيع | | مدونة نشطة | مرة/يوم | 30 يوماً | | متجر إلكتروني | 4 مرات/يوم | 30 يوماً + 3 أشهر شهرية | | تطبيق حرج | مرة/ساعة | 48 ساعة بالساعة + 30 يوماً يومياً | **أين تُخزّن النسخ الاحتياطية — قاعدة 3-2-1:** - **3** نسخ من البيانات - على **2** وسيطَين مختلفَين - **1** منها خارج الموقع الرئيسي **ما يقدمه ServOrbit:** لقطات VPS تُنشأ عند الطلب من منطقة العميل (ابتداءً من باقة VPS Power) ومساحة نسخ احتياطي على تخزين منفصل (VPS Business أو كخيار إضافي). لا شيء مُجدوَل تلقائيًا: تُؤتمت الوتيرة ومدة الاحتفاظ المذكورتان أعلاه من جهتك (cron أو Restic أو Borg). البيانات تبقى في أوروبا.

قبل أي عملية حساسة على Plane، احتفظ بنسخة احتياطية من أحجام Docker. الأمر `docker compose exec plane-db pg_dump -U plane plane > plane_backup.sql` يُصدِّر قاعدة البيانات الرئيسية؛ أكمله بنسخة من ملفات الإعداد (`.env`، `docker-compose.yml`) وأي ملفات مرفوعة. اختبر الاستعادة على بيئة تجريبية قبل الشروع في الترحيل.

نعم، هذا أمر لا غنى عنه: فترقية ‎PostgreSQL‎ إلى إصدار رئيسي جديد (مثلاً ‎15 → 17‎) تغيّر التنسيق الداخلي للبيانات ولا يمكن التراجع عنها دون استعادة. قبل أي ترحيل، صدّر نسخة كاملة باستخدام ‎`pg_dumpall -U postgres > backup_avant_migration.sql`‎ واحتفظ بها على تخزين منفصل عن خادم ‎VPS‎ الخاص بك (‎Backblaze B2‎ أو ‎SFTP‎ بعيد). تحقّق من أن الاستعادة تعمل على بيئة اختبار قبل إيقاف المحرّك القديم. إذا كنت تستخدم لقطات (‎snapshots‎) خادم ‎VPS‎ من ‎ServOrbit‎، فتأكّد من أن آخر لقطة حديثة قبل بدء الإجراء.

يوفر ‎Elasticsearch واجهة برمجية للنسخ الاحتياطي والاستعادة (‎Snapshot and Restore) تُنشئ نسخاً احتياطية تدريجية مكررة الإزالة لمؤشراتك. اضبط مستودع ‎S3 (متوافق مع ‎Backblaze B2 و‎Cloudflare R2 وأي تخزين كائنات متوافق مع ‎S3) وحدّد سياسة دورة حياة اللقطات (‎SLM) لأتمتة التكرار والاحتفاظ. مهم: لا تنسخ ملفات البيانات مباشرةً من القرص أثناء تشغيل ‎Elasticsearch — فقط آلية اللقطات الأصلية تضمن نسخة احتياطية متسقة. اختبر الاستعادة على خادم ‎VPS ثانٍ بانتظام للتحقق من سلامة النسخ.

لخادم VPS في بيئة الإنتاج، استهدف نسخًا احتياطيًا يوميًا على الأقل مع فترة احتفاظ تبلغ 7 أيام. التطبيقات الحيوية (قواعد البيانات وملفات العملاء) تستحق نسخًا كل ساعة أو نسخًا تزايديًا. ميّز بين لقطات النظام (مفيدة قبل تحديث) والنسخ الاحتياطية للبيانات (ضرورية للاستمرارية). اختبر الاستعادة بانتظام: نسخة احتياطية لم يُتحقَّق من استعادتها قط هي نسخة غير موثوقة. خزِّن النسخ على موقع بعيد أو خدمة تخزين كائني مستقلة عن خادمك.

اللقطة (snapshot) هي صورة لحالة القرص في لحظة بعينها، تُؤخَذ على مستوى المُراقب الافتراضي (hypervisor): سريعة الإنشاء، تتيح التراجع في دقائق، لكنها تبقى مرتبطة بالتخزين الفعلي نفسه. أما النسخة الاحتياطية الكاملة فتنسخ البيانات إلى موقع منفصل (خادم آخر أو تخزين كائني) وتحمي من الأعطال المادية. كلاهما مكمِّل للآخر: اللقطات تغطي الأخطاء البشرية والتحديثات الفاشلة، والنسخ الاحتياطية تغطي الكوارث وفقدان البيانات. على خادم VPS من ServOrbit، تتوفّر اللقطات والنسخ الاحتياطية حسب الخطة، وتُطلَق عند الطلب من منطقة العميل.

يُنشئ ‎ERPNext‎ نسخاً احتياطية مضغوطة عبر `bench backup` في مجلد `private/backups/` لكل موقع. ادمج هذا مع `rclone` أو أداة ‎AWS CLI‎ لرفع كل أرشيف إلى حاوية متوافقة مع ‎S3‎ (مثل ‎Backblaze B2‎ أو ‎Cloudflare R2‎ أو ‎MinIO‎) مباشرةً بعد إنشائه. جدوِل كل شيء بمهمة ‎cron‎ ليلية، وشفِّر الأرشيفات قبل رفعها إذا كانت تحتوي بيانات حساسة، واختبر الاستعادة بانتظام في بيئة تجريبية للتحقق من سلامتها. احتفظ بحد أدنى 7 نسخ يومية و4 نسخ أسبوعية.

على الاستضافة المشتركة، تتم الاستعادة بالخدمة الذاتية: من منطقة عميل ‎ServOrbit‎، افتح ‎cPanel‎ («الوصول إلى ‎cPanel‎»)، ثم قائمة ‎JetBackup‎؛ واختر النسخة الاحتياطية بالتاريخ المطلوب والعنصر المراد استعادته (الحساب كاملًا، أو الملفات، أو قاعدة البيانات). وتتوقف النسخ المتاحة على عرضك: أسبوعية في ‎Business‎، ويومية في ‎Pro‎؛ ولا يشمل ‎Start‎ أي نسخة احتياطية. وإن واجهتك صعوبة، افتح تذكرة دعم في فئة «الاستضافة» مع تحديد تاريخ النسخة الاحتياطية والمسار أو قاعدة البيانات المراد استعادتها.

اللقطة (snapshot) هي نسخة فورية من القرص تُؤخَذ على مستوى المشرّف الافتراضي (hypervisor): مثالية للتراجع عن خطأ ما، غير أنها تقيم على البنية التحتية المادية ذاتها التي يعمل عليها خادمك. أما قاعدة ‎3-2-1 فتذهب أبعد من ذلك: 3 نسخ من البيانات، على وسيطَين مختلفَين، إحداهما خارج الموقع. وإذا تعرّض مركز البيانات لعطل أجهزة أو فيضان أو حذف عرضي لحسابك، فلن تُنقذك سوى النسخة الخارجية. اجمع بين اللقطات (للاستجابة السريعة) ونسخة احتياطية مُحوَّلة إلى تخزين كائنات خارجي (‏Backblaze B2 أو ‏S3 أو ‏Scaleway…) لتغطية كلا مستويَي الخطر.

نعم، وهذه تحديدًا الميزة الجوهرية لمستودع ‏Restic المستضاف خارج VPS. يقيم المستودع على وحدة التخزين الكائني الخارجية (‏S3 أو ‏Backblaze B2 أو ‏Scaleway…) ولا يرتبط بخادمك بأيّ تبعية؛ ويمكنك الوصول إليه من أي جهاز يحمل الأداة ‏Restic ومفتاح التشفير وبيانات اعتماد المستودع. احتفظ بهذه العناصر في مدير أسرار (‏Bitwarden أو ‏Vault…) مستقل عن بنيتك التحتية، واختبر عملية استرداد كاملة على جهاز مستقل مرةً على الأقل كل شهر.

في ‎cPanel، افتح ‎JetBackup واختر «‏File Backups‏» وتصفح إلى الملف في قائمة النسخ الاحتياطية المتاحة. حدد التاريخ المطلوب ثم انقر على «‏Restore‏» بجانب الملف لاستعادته منفرداً دون التأثير على بقية الحساب. إن لم تعثر على الملف، تواصل مع ‎[email protected] مع المسار والتاريخ المستهدف.

على الاستضافة المشتركة، يتوقف التواتر على الخطة: لا تتضمّن ‎Start‎ أي نسخة احتياطية، وتتضمّن ‎Business‎ نسخة احتياطية أسبوعية، و‎Pro‎ نسخة احتياطية يومية. أما خطط ‎VPS‎ فتتوفر لها سياسات قابلة للتهيئة وفق عقدك؛ في حين لا تتضمّن الخوادم المخصّصة أي نسخ احتياطية مقدَّمة. راجع بوابة العميل أو راسل ‎[email protected]‎ للاطلاع على السياسة الدقيقة لخطتك.

قبل أي ترحيل رئيسي لـ‎PostgreSQL‎، أجرِ نسخاً احتياطياً كاملاً بـ‎`pg_dumpall -U postgres > backup_before_migration.sql`‎ للكلستر بأكمله، أو ‎`pg_dump -U postgres -Fc db_name > db_name.dump`‎ لقاعدة بيانات فردية (صيغة مضغوطة قابلة للاستعادة بـ‎`pg_restore`‎). تحقق من اكتمال النسخة وإمكانية قراءتها قبل بدء الترقية. للاستعادة، أنشئ كلستراً جديداً بالإصدار الجديد ثم استورد باستخدام ‎`psql`‎ أو ‎`pg_restore`‎. راجع مقالنا عن ترحيل ‎PostgreSQL 18‎ للاطلاع على الاحتياطات الخاصة بهذا الإصدار.

بالنسبة لنظام Odoo في الإنتاج، يُعدّ النسخ الاحتياطي الكامل اليومي لقاعدة بيانات PostgreSQL الحدَّ الأدنى الموصى به. تُفضّل الشركات ذات حجم المعاملات العالي أو التسامح المنخفض مع فقدان البيانات النسخَ الاحتياطي التزايدي كل 4 إلى 6 ساعات. يجب نسخ ملفات مجلد `filestore` (المرفقات، المستندات) بنفس تواتر قاعدة البيانات لضمان التماسك. يُستحسن أيضًا الاحتفاظ بما لا يقل عن 7 أيام من النسخ اليومية و4 أسابيع من النسخ الأسبوعية، مخزَّنة في موقع بعيد أو تخزين كائنات منفصل عن الـ VPS الرئيسي.

قبل أي نقل، تحقّق من أن آخر نسخة احتياطية كاملة (الملفات وقواعد البيانات والبريد الإلكتروني) حديثة ومختبَرة. في خطط الاستضافة لدينا، يمكنك تشغيل نسخة احتياطية يدوية من ‎cPanel‎ في أي وقت. وعلى الـ‎VPS‎، التقِط صورة ‎snapshot‎ إن أتاحت ذلك خطتك، أو صدِّر ‎volumes‎ بياناتك قبل الترحيل. أبقِ البنية التحتية القديمة نشطةً حتى التحقّق من الموقع الجديد واكتمال انتشار ‎DNS‎ — وبذلك تبقى نافذة التحويل قابلةً للتراجع دون فقدان البيانات.

لا تُجدوِل ‎ServOrbit‎ أي نسخ احتياطي تلقائي لخوادم ‎VPS‎ الخاصة بك: تُطلَق اللقطات (snapshots) والنسخ الاحتياطية عند الطلب من منطقة العميل، حسب خطتك — اللقطات ابتداءً من باقة VPS Power، والنسخ الاحتياطية مع مساحة النسخ الاحتياطي المضمّنة في VPS Business أو كخيار إضافي. تتوفر استعادة لقطة أو نسخة احتياطية بالخدمة الذاتية من منطقة العميل في بضع نقرات. للحصول على حماية معززة، يُنصح بدمج هذه الأدوات مع نسخ احتياطي خارجي على مستوى التطبيق تُجدوِله من جهتك (مثل ‎Borg Backup‎ أو ‎Restic‎ نحو تخزين كائني). تبقى اللقطات على التخزين نفسه الذي يعمل عليه الخادم؛ أما النسخ الاحتياطية وحدها فتُخزَّن على تخزين منفصل لتصمد أمام الأعطال المادية.

الطريقة الموصى بها هي استخدام سكريبت ‎cron‎ يُشغّل الأمر `docker run --rm -v <volume>:/data -v /backup:/backup alpine tar czf /backup/<volume>-$(date +%F).tar.gz /data`، ثم ينقل الأرشيف إلى تخزين بعيد (‎S3‎، ‎SFTP‎). أدوات كـ‎Restic‎ أو ‎Duplicati‎ يمكنها أتمتة هذه الدورة مع التشفير والاحتفاظ المُهيَّأ. تحقق من الاستعادة بانتظام: النسخة الاحتياطية غير المختبرة ليست نسخة احتياطية. يمكنك فتح تذكرة دعم للحصول على توصيات مُكيَّفة مع بنيتك التقنية.

تعتمد مدة الاستعادة على حجم البيانات ونوع النسخة الاحتياطية المستخدمة: تستغرق استعادة حساب ‎cPanel‎ خفيف (بضع مئات من الميجابايت) عبر ‎JetBackup‎ عادةً أقل من 30 دقيقة من فضاء العميل، بالخدمة الذاتية. وبالنسبة للحسابات الأكبر حجماً أو الاستعادات الجزئية (ملف واحد أو قاعدة بيانات واحدة)، تكون المدة مماثلة. وفي حال وقوع كارثة كبرى تستدعي تدخّل فريقنا، افتح تذكرة ذات أولوية عاجلة من فضاء العميل مع وصف التأثير؛ ويتكفّل فريقنا بالطلب ضمن آجال اتفاقية مستوى الخدمة (‎99.9‎ % من التوفّر). وللحدّ قدر الإمكان من خطر فقدان البيانات، اختر خطة يناسبك تواتر نسخها الاحتياطي: تتضمّن ‎Business‎ نسخة احتياطية أسبوعية، و‎Pro‎ نسخة احتياطية يومية.

نعم، يمنحك VPS الخاص بـServOrbit وصولًا كاملًا بصلاحيات الجذر: يمكنك تثبيت rclone أو Restic وإعداد نسخ احتياطي تلقائي إلى أي تخزين كائنات متوافق مع S3 مثل AWS S3 أو Backblaze B2 أو Wasabi. يُنصح بجدولة النسخ الاحتياطي عبر مؤقت systemd أو crontab، وتشفير الأرشيفات (يشفّر Restic بشكل افتراضي)، واختبار الاستعادة الكاملة بانتظام. أما على الاستضافة المشتركة، فتتم النسخ الاحتياطية عبر JetBackup المدمج في cPanel: وتتوقف النسخ المشمولة على العرض (أسبوعية في Business، ويومية في Pro، ولا شيء في Start)، وتستعيدها بنفسك من قائمة JetBackup في cPanel.

في واجهة ‎Backrest‎، استخدم وظيفة «Restore» باختيار لقطة حديثة وهدف مؤقت (مثلاً ‎`/tmp/restore-test`‎). تحقّق بعدها من وجود الملفات الأساسية وإمكانية قراءتها. جدوِل هذا الاختبار شهرياً بإضافة مهمة آلية في ‎Backrest‎ أو ‎cron‎ مخصص — نسخة احتياطية غير مختبَرة لا تُغني عن سياسة استرداد حقيقية.

نعم، يتيح ‎Backrest‎ تعريف مستودعات (repos) متعددة في إعداداته، كلٌّ منها يشير إلى ‎backend‎ مختلف (‎S3‎، ‎Backblaze B2‎، ‎SFTP‎، محلي…). يمكنك بذلك نسخ نسخك الاحتياطية إلى ‎bucket S3‎ منفصلَين أو الجمع بين تخزين محلي وتخزين كائنات بعيد. لكل مستودع جدولته الخاصة وسياسة الاحتفاظ به.

لا: لا تتضمّن الخوادم المخصّصة من ‎ServOrbit‎ نسخاً احتياطية تلقائية ولا لقطات (‎snapshots‎) — فالخادم الفعلي لا يوفّر هذه الوظائف، واستراتيجية النسخ الاحتياطي تقع على عاتقك (نسخ منتظمة إلى مساحة تخزين خارجية مستقلة). في حال وقوع كارثة، تتم الاستعادة انطلاقاً من نسخك الاحتياطية الخاصة؛ وإذا لزم إعادة تثبيت النظام، يُقدَّم الطلب إلى فريق الدعم، علماً أن إعادة التثبيت تمسح القرص. لأي سؤال حول الاستراتيجية الواجب اعتمادها، تواصل مع ‎[email protected]‎.

‏يُشفّر ‏Infisical‏ أسراره في قاعدة البيانات باستخدام مفتاح تشفير رئيسي (‏`ENCRYPTION_KEY`‏) منفصل عن بيانات ‏PostgreSQL‏. أفضل ممارسة هي نسخ قاعدة بيانات ‏PostgreSQL‏ احتياطيًا (‏dump‏ مشفَّر باستخدام ‏Restic‏ أو ‏pg_dump + gpg‏) وتخزين ‏`ENCRYPTION_KEY`‏ بشكل منفصل — في مدير أسرار غير متصل بالشبكة أو خزنة خارجية — لا في نفس الأرشيف ولا على نفس الخادم. هكذا، حتى إذا تعرّضت نسخة قاعدة البيانات للاختراق، تبقى الأسرار غير قابلة للقراءة بدون المفتاح. اختبر الاستعادة الكاملة (قاعدة البيانات + المفتاح) بانتظام في بيئة معزولة.

اتصل بـ VPS الخاص بك عبر SSH ونفّذ الأمر `mysqldump -u root -p اسم_قاعدة_البيانات > backup.sql` لتصدير قاعدة البيانات إلى ملف SQL قابل للقراءة. لأتمتة هذه العملية، أضف الأمر إلى مهمة cron (`crontab -e`) وانقل الملف إلى تخزين بعيد (SFTP أو S3 أو Backblaze B2) باستخدام `rsync` أو `rclone`. تقدم ServOrbit أيضاً لقطات VPS تُنشأ عند الطلب من منطقة العميل، تكملةً للنسخ الاحتياطية على مستوى التطبيق.

تتمثّل الطريقة الموصى بها في تشغيل ‪`pg_dump`‬ عبر مؤقّت ‪systemd‬ أو مهمة ‪cron‬، ثم إرسال الأرشيف المُشفَّر إلى تخزين بعيد (متوافق مع S3 أو SFTP) باستخدام أداة مثل ‪Restic‬ أو ‪Rclone‬. دورة الحد الأدنى: نسخ احتياطية يومية تُحتفظ بها 7 أيام ونسخ أسبوعية تُحتفظ بها 4 أسابيع. اختبر الاستعادة بانتظام على مجلد مؤقت — الأرشيف غير المختبر ليس نسخة احتياطية. يمكن لفريق الدعم لدينا توجيهك من خلال ساحة عملائك.

قبل الترقية، أنشئ لقطة (snapshot) إن كانت خطتك تتيحها (VPS Power وVPS Business)، ثم نسخة احتياطية من لوحة التحكم (الحسابات والمواقع وقواعد البيانات وصناديق البريد) تُنسخ إلى خارج الخادم، فاللقطة تُخزَّن على البنية نفسها. احتفظ أيضًا بنسخة من إعدادات اللوحة ومهامك المجدولة. جرّب استعادة موقع واحد قبل البدء، وإن فشلت الترقية فإعادة تثبيت النظام من منطقة العميل تمسح القرص: وبدون هذه النسخة الخارجية لن يبقى ما يمكن استرجاعه.

استعيدوها في مكان آخر غير خادم الإنتاج: في مجلد مؤقت أو على خادم ‎VPS‎ ثانٍ يُحذف بعد الاختبار. تحققوا من أن الملفات الأساسية تُفتح، وأن قاعدة البيانات تعمل من جديد ببياناتها، وأن التطبيق يستجيب، ثم دوّنوا المدة الكاملة التي استغرقتها العملية. كرّروا هذا الاختبار بانتظام وبعد كل تغيير مهم في إعداداتكم: وحدها استعادة ناجحة تثبت أن النسخة الاحتياطية مفيدة.

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

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