كيفية نسخ احتياطي واستعادة مجلد تطبيق /var/discourse بالكامل؟

كيفية نسخ مجلد /var/discourse بالكامل واستعادته؟

بسبب مشاكل في عملية النسخ الاحتياطي والاستعادة المعتادة، تساءلت عما إذا كان بإمكاني نسخ مجلد /var/discourse بالكامل وإعادة استخدامه على خادم آخر. هذا ما فعلته…

على خادم الإنتاج:

rsync_opts="\
   --recursive \
   --links \
   --hard-links \
   --safe-links \
   --owner \
   --group \
   --perms \
   --times \
   --delete \
   --sparse \
   --compress \
   --partial \
   --rsh=ssh
"
dir=/var/discourse
rsync  $rsync_opts "$dir/" root@xx.xx.xx.xx:"/var/production-backup/$dir"

على خادم الاختبار:

تثبيت Docker.

rsync --recursive --links --hard-links --safe-links --owner --group --perms --times --delete --sparse --compress --partial /var/production-backup/var/discourse/ /var/discourse

لكنني أحصل على 502 Bad Gateway.

أحاول التحقيق.

cd /var/discourse

./launcher start app

root@whonix-app:/var/www/discourse# service postgresql status
12/main (port 5432): down
root@whonix-app:/var/www/discourse# service postgresql start
[....] Starting PostgreSQL 12 database server: main[....] Error: The cluster is owned [FAILoup id 116 which does not exist ... failed!
 failed!

أفترض بعض الإصلاحات:

chown -R postgres.postgres /etc/postgresql
chown -R postgres.postgres /shared/postgres_*
chown -R postgres.postgres /var/lib/postgresql
chown -R postgres.postgres /var/log/postgresql
chown -R redis.redis /etc/redis/redis.conf
chown -R redis.redis /shared/redis_data
chown -R redis.redis /var/run/redis
chown -R redis.redis /var/lib/redis
chown -R redis.redis /var/log/redis
chgrp -R ssl-cert /etc/ssl/private

لكنها لم تساعد.

root@whonix-app:/var/www/discourse# service postgresql start
[....] Starting PostgreSQL 12 database server: main[....] Error: /usr/lib/postgresql/12/bin/pg_ctl /usr/lib/postgresql/12/bin/pg_ctl start -D /shared/postgres_data -l /var/log/postgresql/postgresql-12-main.log -s -o -c config_file="/etc/postgresql/12/main/postgresql.conf" exited with status 1: 2020-05-25 10:20:10.501 UTC [603] FATAL: database files are incompatible with server 2020-05-25 10:20:10.501 UTC [603] DETAIL: The data directory was initialized by PostgreSQL version 10, which is not compatible with this version 12.2 (Debian 12.2-2.pgdg100+1). pg_ctl: could not start server Examine the lo[FAILput. ... failed!
 failed!

لماذا تظهر مشاكل أذونات الملفات هذه؟

لماذا يتم تحديث PostgreSQL من الإصدار 10 إلى الإصدار 12 بمجرد نسخ المجلد بالكامل من خادم إلى آخر؟ يجب أن أكون أقوم بشيء خاطئ.

هل يمكنك من فضلك مشاركة تعليمات حول كيفية نسخ تطبيق Discourse بالكامل على خادم واحد ونقله إلى خادم آخر؟

هل لا يستخدم Discourse Phabricator؟

خطأ إملائي. كنت أقصد discourse. تم تصحيح الخطأ الإملائي. السؤال الأصلي يبقى كما هو.

هذا لا ينقل مجلد /var/discourse بالكامل. أنا على دراية بهذه التعليمات، لكن هذه لا تعمل بالنسبة لي. لذلك، أردت طريقة “نسخة صلبة” كاملة 1to1 أكثر شمولاً للنسخ الاحتياطي.

يمكنك إيقاف تشغيل الحاوية ونسخها بالكامل إلى خادم جديد، باستثناء مجلدات tmp و backup و cache (وأعتقد مجلدًا آخر؟). يجب أن يعمل ذلك. لقد قمت بذلك مؤخرًا، أعتقد لسبب مشابه.

لكنك ما زلت بحاجة حقًا إلى حل مشكلة فهرس التالف.

أعتقد أن إصدار Docker هو ما يُحدث الاختلافات (مما يؤدي بعد ذلك إلى الفشل).

الخادم الأصلي
docker-engine 17.05.0~ce-0~debian-stretch

مقارنةً بالخادم الأحدث (المرحلة التجريبية)
docker-engine 17.05.0~ce-0~debian-stretch

وهذا يؤدي إلى احتواء الخادم الأصلي على إصدار PostgreSQL 10 بينما يحتوي الخادم الأحدث (المرحلة التجريبية) على PostgreSQL 12 بالفعل.

هل هذا إلزامي؟ هل توجد طريقة أسهل؟ ولماذا يُشترط عدم نسخ الكل كما هو واستعادته؟

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

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

لا يمكنك ببساطة "ضغط مجلد /var/discourse ونقله إلى جهاز آخر، ثم فك ضغطه وتشغيل تطبيق Discourse.

أحد الأسباب الرئيسية هو أنه عند بناء / تهيئة Discourse، يقوم (أداة التشغيل كما أتذكر من رأسه) بالتحقق مما إذا كان حاوية Discourse الأساسية (صورة) موجودة، وسحب صورة Docker الأساسية لـ Discourse (إذا لم تكن موجودة)، ثم تشغيل هذه الصورة الأساسية داخل حاوية.

بعد سحب git الأساسي، ستقوم عملية البناء ببناء صورة Docker أخرى (التطبيق).

كلا هاتين الصورتين (الصورة الأساسية وصورة التطبيق) لا توجدان داخل /var/discourse. لذا، فإن ضغط /var/discourse هو مجرد “حل” جزئي (باستخدام هذا المصطلح بمرونة).

تم بناء صور Docker هذه كصور Docker وكجزء من Docker؛ فهي لا “تعيش” في /var/discourse، بل يتم بناؤها هناك ثم نقلها إلى Docker كصور Docker.

قد يكون من الممكن تعديل ملف yml الخاص بالحاوية وإعادة البناء من الصفر، ولكن الطريقة الأكثر تقليدية هي حفظ:

  • ملف (ملفات) yml الخاص بالحاوية
  • النسخة الاحتياطية الكاملة مع الملفات المرفقة

ثم تعديل ملف yml الخاص بالحاوية، واستنساخ مستودع discourse-docker وإعادة البناء.

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

استخدام GitHub كمستودع هو حل أنظف من الطريقة القديمة “unixy” المتمثلة في “ضغط كل شيء” و"نقل كل شيء" إلى خادم آخر. ومع ذلك، حتى مع “الطريقة القديمة لنظام Unix”، فإن هذه الطريقة غالبًا ما لا توفر حلاً كاملاً لأن هناك مكتبات مشتركة في النظام، ومجلدات المستخدمين المشتركة، وأكثر من ذلك، والتي ليست جزءًا من دليل التوزيع، وهناك ملفات etc ليست في الجذر الرئيسي للتوزيع، إلخ.

لذلك، حتى على معظم أنظمة Linux الحديثة، نستخدم apt (على سبيل المثال في Ubuntu) لسحب المستودع. في حالة Docker لـ Discourse، تقوم بسحب (وبناء) discourse-docker لإعداد الحاوية الأساسية، ومستودع آخر لـ Discourse لبناء التطبيق. لذا، فإن /var/discourse هو “مكان للبناء” (الصور) و"مكان للمشاركة" (البيانات، النسخ الاحتياطية، الملفات الثابتة العامة، إلخ).

أتمنى أن يكون هذا الملخص مفيدًا بطريقة ما.

بالتأكيد، يمكنك نسخها بالكامل باستخدام rsync -rav.

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

يمكنك نقل المجلد، فهو يعمل بشكل جيد. إنه ببساطة ليس المسار المفضل لأنه يتجاوز discourse-setup وأي من عمليات الضبط أو الاختبارات التي يتم إجراؤها على طول الطريق.

لم ينجح الأمر في حالتي لأن ترقية Docker أدت إلى إصدار أحدث من PostgreSQL داخل حاوية Docker، مما أدى بعد ذلك إلى ظهور منتدى غير قابل للاستخدام بسبب مشكلات ترحيل PostgreSQL. كان عليّ التبديل من قالب postgres إلى PostgreSQL 10.

تشرح هذه الصفحة التفاصيل بشكل جيد: How to backup and restore a whole /var/discourse app folder? - #8 by neounix

أعتقد أنني سأضطر إلى عمل نسخة احتياطية واستعادة مجلد /var/docker أيضًا. لكن حتى ذلك قد يفشل بسبب ما يلي:

أنت تسير في نفق مسدود.
لو كنتُ مكانك لركّزتُ على حل مشكلتك الأصلية المتعلقة بالنسخ الاحتياطي والاستعادة.

ربما حتى حفرة :rat: :rat: :rat:.

أتفق تمامًا… بالتأكيد…

@adrelanos

لا توجد “مشكلات” في عملية النسخ الاحتياطي والاستعادة. راجع هذا “الإشادة” التي كتبها شخصي أنا @neounix قبل بضعة أشهر حول هذا الموضوع:

عزيزي @adrelanos،

بالعودة إلى سؤالك الأصلي في المشاركة رقم 1 أعلاه، وبسبب فضولي الطبيعي، لم أكن راضيًا حقًا عن ردّي السابق، وقمت ببعض الاختبارات اليوم.

باختصار، لقد تأكدت من أنه يمكننا استخدام أمر docker save (لحاويات الأساس والتطبيق) و tar لمجلد /var/discourse، وبالتالي يمكننا حفظ ونقل (نسخ احتياطي) واستعادة التطبيق بالكامل بهذه الطريقة.

أنا متأكد بنسبة كبيرة (99.99%) أن هذه الطريقة غير مدعومة رسميًا, لكنك تستحق إجابة، لذا قمت باختبارها من أجلك:

بشكل أساسي، إليك الخطوات ملخصة:

  1. احفظ الحاويات الخاصة بك باستخدام docker save.

على سبيل المثال، إذا كنت تشغل تطبيقًا مستقلاً، يمكنك حفظ حاوية الأساس وحاوية التطبيق، كما يلي (بناءً على إعداداتك):

docker save -o /tmp/my.discourse.docker.app.tar  discourse/base:2.0.20200512-1735

وأيضًا:

docker save -o /tmp/my.discourse.docker.app.tar local_discourse/app:latest  
  1. يمكنك أيضًا ضغط مجلد /var/discourse باستخدام tar، كما ذكرت:
cd /var/
tar -cvzf /tmp/my.var.discourse.tar.gz discourse

ثم قم بضغط ملفات tar الخاصة بـ docker إذا رغبت في ذلك وأضفها إلى الأرشيف:

gzip /tmp/my.discourse.docker*.tar
  1. … ويمكنك نقل هذه الملفات إلى خادم آخر، أو أرشفتها على نفس الخادم، أو أي شيء آخر تريده، ثم عكس الخطوات، وبدء تطبيق Discourse دون أي مشكلة.

لقد تأكدت من ذلك عن طريق “تنفيذه فعليًا”، وحذف جميع صور الحاويات ومجلد /var/discourse. باختصار، محوت كل شيء وأعدت التشغيل (لا حاجة لإعادة البناء لأن النطاق لم يتغير، وما إلى ذلك) من النسخ الاحتياطية.

على سبيل المثال، للاستعادة، يمكنك تحميل صور docker المحفوظة أعلاه، مثل:

gzip -d /tmp/my.discourse.docker.app.tar.gz
docker load -i /tmp/my.discourse.docker.app.tar

gzip -d /tmp/my.discourse.docker.base.tar.gz
docker load -i /tmp/my.discourse.docker.base.tar
  1. ثم قم بفك ضغط مجلد /var/discourse الأصلي
cd /var
tar -xvzf /tmp/my.var.discourse.tar.gz
  1. بعد ذلك، تحتاج إلى فحص صورك للتأكد من أنها مسماة بشكل صحيح:
docker images
  1. وإذا لم تكن الصور مسماة بشكل صحيح، فتأكد من تسميتها بشكل صحيح، على سبيل المثال لصورة التطبيق الخاصة بك:
docker tag 58ffc74989af local_discourse/app:latest
  1. ثم قم فقط بما يلي:
cd /var/discourse
./launcher start app

وسيعمل بشكل ممتاز. لقد اختبرت ذلك (مرتين).

أتمنى أن يكون هذا مفيدًا.

ملاحظة جانبية: جربت هذه الطريقة بطريقتين مختلفتين، عن طريق تنفيذ طريقة النسخ الاحتياطي المذكورة أعلاه، ومحو جميع حاويات docker وصورها ومجلد /var/discourse (تدمير كل شيء بالكامل في كل مرة).

في كل حالة، تمكنت من تحميل صور docker المحفوظة، وفك ضغط مجلد /var/discourse، وتشغيل ./launcher start app، وقد بدأ Discourse بسلاسة، ولإثبات ذلك، تمكنت من إجراء نسخ احتياطي عادي من واجهة المستخدم، مما يثبت أن كل شيء على ما يرام.

لا أعرف ما إذا كان هذا يجيب على سؤالك (ولم أشارك في ترقية أو مناقشات Postgres من الإصدار 10 إلى 12)؛ ولكن فيما يتعلق بسؤالك حول مجرد ضغط التطبيق كنسخة احتياطية واستعادته، فإن الإجابة هي نعم، ولكن يجب عليك ليس فقط أرشفة مجلد /var/discourse، بل يجب عليك أيضًا docker save لصورك.

المشكلة الرئيسية هي الحفاظ على اسم مستودع الصور وعلاماتها (tags) بشكل صحيح، وستكون على ما يرام.

أتمنى أن يجيب هذا على سؤالك، ولو بشكل بسيط، حول:

كيفية عمل نسخة احتياطية واستعادة مجلد تطبيق /var/discourse بالكامل؟

الإجابة هي أنه يجب عليك أرشفة كل من مجلدك وصور docker الخاصة بك (كما في المثال أعلاه) باستخدام docker save للصور (لعمل نسخة احتياطية)، و docker load للاستعادة.

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

ملاحظة 1:

قد ترغب في نقل جميع النسخ الاحتياطية من مجلد backups/default (خارج شجرة المجلدات) قبل ضغط كل شيء في /var/discourse/ والاحتفاظ بتلك النسخ الاحتياطية (بشكل منفصل) لأن هذه الملفات ضخمة جدًا…

ملاحظة 2:

هذا النوع من النسخ الاحتياطي غير مدعوم، وبالتالي لا يُنصح به لمعظم مديري أنظمة Discourse. أنصح المستخدمين باتباع طريقة النسخ الاحتياطي والاستعادة الموصى بها ( والمدعومة رسميًا) من Discourse.

ابق فضوليًا!

اعتنِ بنفسك.


لمزيد من التفاصيل بما في ذلك لقطات الشاشة، يرجى الاطلاع على مشاركتي الكاملة هنا:

هذه طريقة ممتازة! شكرًا لك!

هناك مشكلة في خادم الاستعادة.

./launcher logs app

2020-06-18 13:33:56.434 UTC [127] FATAL: data directory “/shared/postgres_data” has wrong ownership
2020-06-18 13:33:56.434 UTC [127] HINT: The server must be started by the user that owns the data directory.
./run: 3: echo: echo: I/O error
2020-06-18 13:33:57.448 GMT [128] LOG: skipping missing configuration file “/shared/postgres_data/postgresql.auto.conf”


قد يكون ذلك بسبب بعض خيارات tar المفقودة؟ أضفت -p و -s أثناء الاستخراج لكن ذلك لم يُجدِ نفعًا.

الخادم الأصلي (خارج docker):

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 4096 May 25 13:16 base

الخادم الأصلي (داخل docker (./launcher enter app)):

ls -la /var/lib/postgresql/10/main/

drwx------ 5 root postgres 4096 May 25 23:28 base


خادم الاستعادة خارج docker:

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 71 May 25 11:16 base

خادم الاستعادة داخل docker:

drwx------ 5 root postgres 41 May 25 23:28 base


./launcher rebuild app سيُصلح المشكلة لكن هذا ليس جوهر الموضوع.

هل لديك أي فكرة؟

أظن أنك تقصد docker save -o /tmp/my.discourse.docker.base.tar discourse/base:2.0.20200512-1735، بناءً على عملية الاستعادة التي ذكرتها. وعلى أي حال، شرح رائع!

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

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

https://meta.discourse.org/t/postgresql-12-update/151236/298?u=lucasbasquerotto

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

طريقة استخدمتها لا تتضمن docker save أو عملية نقل شاملة لـ tar+untar لمجلد /var/discourse: