كيفية إعداد النسخ الاحتياطي التلقائي لقاعدة البيانات لخادم ownCloud

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

يُقدّم هذا الدليل طريقة عملية لأتمتة نسخ قواعد بيانات ownCloud احتياطيًا على نظام Linux، بدءًا من النسخ اليدوي وانتهاءً بمهمة مجدولة ومُدققة. تُركّز الأمثلة على MySQL/MariaDB لأن ownCloud تُوصي باستخدام هذه المحركات، كما يتضمن الدليل نسخةً من PostgreSQL. تتوافق الأوامر مع وثائق إدارة خادم ownCloud 11.0 الحالية، مع الإشارة إلى اختلاف الأوامر في عمليات التثبيت التقليدية غير القائمة على Docker.

أولاً، افهم ما لا يغطيه النسخ الاحتياطي لقاعدة البيانات

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

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

الخطوة 1: تأكد من قاعدة البيانات التي يستخدمها ownCloud

قبل كتابة أمر النسخ الاحتياطي، حدد نوع قاعدة البيانات، والمضيف، واسم قاعدة البيانات، والمستخدم. في تثبيت ownCloud التقليدي، تتوفر هذه القيم عادةً في ملف config/config.php. يمكنك أيضًا فحص إعدادات النظام باستخدام أداة سطر أوامر ownCloud. على سبيل المثال، من دليل ownCloud:

sudo -u www-data ./occ config:list system

في عملية نشر Docker Compose، تستخدم الوثائق الحالية أوامر مثل:

docker compose exec owncloud occ config:list system

ابحث عن قيم مثل dbtype، dbhost، dbname، و dbuser. يدعم خادم ownCloud 11.0 رسميًا MySQL/MariaDB و PostgreSQL، مع التوصية باستخدام MySQL أو MariaDB لعمليات النشر العادية.

الخطوة الثانية: إنشاء موقع نسخ احتياطي محمي

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

sudo mkdir -p /var/backups/owncloud-db
sudo chown root:root /var/backups/owncloud-db
sudo chmod 700 /var/backups/owncloud-db

تحقق من المساحة الحرة باستخدام أداة التحقق df -h /var/backups/owncloud-db. قد تتسبب عملية النسخ الاحتياطي التي تملأ قرص النظام بصمت في حدوث انقطاع ثانٍ أثناء محاولة الحماية من الانقطاع الأول.

الخطوة 3: تجنب إدخال بيانات اعتماد قاعدة البيانات في أمر cron

لا تُضِف كلمة مرور قاعدة البيانات مباشرةً في سطر crontab. بالنسبة إلى MySQL أو MariaDB، يُعد ملف خيارات العميل الذي يمكن قراءته بواسطة المستخدم الجذر بسيطًا ويعمل بكفاءة مع المهام غير المراقبة. إنشاء /etc/owncloud/db-backup.cnf:

[client]
user=ownclouduser
password=REPLACE_WITH_DATABASE_PASSWORD
host=localhost

ثم قم بتقييده:

sudo chown root:root /etc/owncloud/db-backup.cnf
sudo chmod 600 /etc/owncloud/db-backup.cnf

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

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

تنص إجراءات النسخ الاحتياطي الرسمية لـ ownCloud على منع الوصول العادي ووضع المثيل في وضع الصيانة قبل إجراء النسخ الاحتياطي لقاعدة البيانات. بالنسبة لنشر Docker Compose:

docker compose exec owncloud occ maintenance:mode --on

للتثبيت التقليدي من دليل ownCloud:

sudo -u www-data ./occ maintenance:mode --on

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

بالنسبة لـ MySQL أو MariaDB، اختبر عملية النسخ الاحتياطي اليدوي:

sudo mysqldump   --defaults-extra-file=/etc/owncloud/db-backup.cnf   --single-transaction   --quick   owncloud   | gzip -c > /var/backups/owncloud-db/owncloud-db-$(date +%Y%m%d-%H%M%S).sql.gz

تستخدم وثائق ownCloud أداة mysqldump. يشرح مرجع mysqldumpmysqldump --single-transaction الخاص بـ MySQL أن هذه الأداة تُنشئ لقطة متسقة للجداول المعاملاتية مثل InnoDB دون حجز أقفال الجداول طوال مدة عملية النسخ الاحتياطي. يقوم هذا الخيار ببث الصفوف بدلاً من تخزين جدول كبير مؤقتًا في الذاكرة.--single-transaction--quick

عند اكتمال النسخ الاحتياطي اليدوي، قم بإيقاف تشغيل وضع الصيانة باستخدام الأمر المطابق:

docker compose exec owncloud occ maintenance:mode --off

أو:

sudo -u www-data ./occ maintenance:mode --off

الخطوة 5: ضع منطق النسخ الاحتياطي في نص برمجي مقاوم للأعطال

يجب أن يتوقف البرنامج النصي عند حدوث أخطاء، ويسجل طابعًا زمنيًا، ويُفعّل وضع الصيانة، ويُنشئ نسخة احتياطية، ويتحقق من الملف المضغوط، ويُطبّق نظام الاحتفاظ بالبيانات، ويضمن تعطيل وضع الصيانة عند الخروج. يفترض المثال التالي تثبيتًا تقليديًا في المسار /var/www/owncloudالمحدد وقاعدة بيانات MySQL/MariaDB باسم owncloud:

#!/bin/bash
set -Eeuo pipefail

OC_ROOT="/var/www/owncloud"
BACKUP_DIR="/var/backups/owncloud-db"
DB_NAME="owncloud"
MYSQL_CNF="/etc/owncloud/db-backup.cnf"
STAMP="$(date +%Y%m%d-%H%M%S)"
OUT="$BACKUP_DIR/owncloud-db-$STAMP.sql.gz"

cleanup() {
  cd "$OC_ROOT"
  sudo -u www-data ./occ maintenance:mode --off || true
}
trap cleanup EXIT

mkdir -p "$BACKUP_DIR"
cd "$OC_ROOT"
sudo -u www-data ./occ maintenance:mode --on

mysqldump   --defaults-extra-file="$MYSQL_CNF"   --single-transaction   --quick   "$DB_NAME" | gzip -c > "$OUT"

test -s "$OUT"
gzip -t "$OUT"

find "$BACKUP_DIR"   -type f   -name 'owncloud-db-*.sql.gz'   -mtime +14   -delete

احفظ الملف باسم /usr/local/sbin/owncloud-db-backup.sh، واجعله قابلاً للتنفيذ باستخدام chmod 700، ثم قم بتشغيله يدويًا. إذا كانت خدمة ownCloud الخاصة بك تعمل في حاوية، فاستبدل السطرين occبأوامر وضع الصيانة في Docker Compose التي تتوافق مع عملية النشر الخاصة بك.

الخطوة 6: جدولة المهمة باستخدام cron

بعد نجاح التشغيل اليدوي، قم بجدولة البرنامج النصي. افتح ملف crontab الخاص بالمستخدم الجذر:

sudo crontab -e

للجري اليومي في الساعة 2:15 صباحاً:

15 2 * * * /usr/local/sbin/owncloud-db-backup.sh >> /var/log/owncloud-db-backup.log 2>&1

اختر وقتًا يتناسب مع نمط استخدامك الفعلي. إذا كانت قاعدة البيانات كبيرة، فقم أولًا بقياس المدة التي يستغرقها التشغيل اليدوي لأن وضع الصيانة يُسبب انقطاعًا ملحوظًا في الخدمة. تأكد أيضًا من أن بيئة cron قابلة للتنبؤ: استخدم المسارات المطلقة في البرنامج النصي إذا لم تكن الأوامر المطلوبة موجودة في المسار الافتراضي لـ cron PATH.

الخطوة 7: تحقق من كل نسخة احتياطية بدلاً من الاعتماد على الطابع الزمني

لا يُعدّ وجود ملف بتاريخ اليوم دليلاً على إمكانية استعادة النسخة الاحتياطية. على الأقل، تأكد من أن الملف غير فارغ، وأن برنامج gzip لا يُبلغ عن أي تلف، وأن سجل العمليات لا يحتوي على أي أخطاء في عملية التفريغ.

ls -lh /var/backups/owncloud-db/
gzip -t /var/backups/owncloud-db/owncloud-db-YYYYMMDD-HHMMSS.sql.gz
tail -n 100 /var/log/owncloud-db-backup.log

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

الخطوة 8: التأكد من عودة ownCloud إلى التشغيل الطبيعي

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

ما الذي يتغير إذا استخدمت PostgreSQL؟

تستخدم وثائق النسخ الاحتياطي الخاصة بـ ownCloud pg_dumpتنسيق أرشيف لـ PostgreSQL. وتشير وثائق pg_dump الرسميةpg_dump لـ PostgreSQL إلى أنها تُنشئ نسخة تصدير متسقة حتى أثناء استخدام قاعدة البيانات. كما يُفرّق فصل النسخ الاحتياطي والاستعادة الأوسع نطاقًا في PostgreSQL بين النسخ المنطقية ونسخ نظام الملفات والأرشفة المستمرة.

أحد الأوامر البسيطة الموجهة إلى ownCloud هو:

PGPASSWORD="REPLACE_WITH_PASSWORD" pg_dump owncloud   -h localhost   -U ownclouduser   -F tar   -f /var/backups/owncloud-db/owncloud-db-$(date +%Y%m%d-%H%M%S).tar

لأغراض الأتمتة، يُفضّل استخدام آلية ملفات كلمات المرور المدعومة في PostgreSQL بدلاً من تضمينها PGPASSWORDفي البرنامج النصي. مع الحفاظ على نفس مبادئ وضع الصيانة، والاحتفاظ بالبيانات، والتسجيل، واختبار الاستعادة.

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

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

التقييم الذاتي النهائي

لا يكون النسخ الاحتياطي التلقائي لقاعدة البيانات جاهزًا إلا عندما تكون جميع هذه العبارات صحيحة:

• أنت تعرف ما إذا كان الخادم يستخدم MySQL/MariaDB أو PostgreSQL وقد تحققت من اسم قاعدة البيانات والمضيف الصحيحين.
• مجلد النسخ الاحتياطي محمي ويحتوي على مساحة خالية كافية.
• لا يتم عرض بيانات الاعتماد في أمر crontab.
• يتم إكمال النسخ الاحتياطي اليدوي بنجاح قبل تفعيل خاصية الجدولة.
• يخرج البرنامج النصي دائمًا من وضع الصيانة، بما في ذلك بعد فشل عملية التفريغ.
• تقوم المهمة المجدولة بكتابة سجل وإنشاء نسخة احتياطية غير فارغة في الوقت المحدد.
• تتم إزالة النفايات القديمة وفقًا لسياسة الاحتفاظ المتعمدة.
• تمت استعادة نسخة احتياطية حديثة بنجاح إلى قاعدة بيانات غير إنتاجية.
• يتم إقران النسخ الاحتياطي لقاعدة البيانات بنسخ احتياطية من بيانات ownCloud والتكوين والمجلدات الأخرى المطلوبة.

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