أفترض أنه ليس من الضروري تمامًا تنزيله. معظم الناس يشغلون مثيلاً سحابيًا واحدًا، قد يكون لديهم أو لا يكون لديهم حاوية S3 احتياطية. سيكون تنزيل النسخة الاحتياطية هو الطريقة الوحيدة لهذه المجموعة لإنشاء نسخة احتياطية خارج الموقع، كما ذكرت.
حتى أنني سأذهب إلى حد إنشاء نظام نسخ احتياطي إضافي على موفر مختلف تمامًا أيضًا، خاصة بعد ما حدث مؤخرًا لـ هذا المطور مفتوح المصدر. بغض النظر عن صحته، فهو تحذير رائع للحصول على نسخة احتياطية أسبوعية أو شهرية في موقع تخزين / موفر منفصل تمامًا.
شكرًا @pfaffman لإضافة هذا، الأمر سهل حقًا الآن! (باستثناء استعادة نسخة احتياطية كبيرة والتي غالبًا ما تكون فترة انتظار متوترة وطويلة بغض النظر عن الإعداد).
بالمناسبة، أعتقد أن هذا المسار غير صحيح: يجب أن يكون web-only (بشكل افتراضي) على ما أعتقد؟:
volumes:
- volume:
host: /var/discourse/shared/web-only
guest: /shared
- volume:
host: /var/discourse/shared/web-only/log/var-log
guest: /var/log
ملاحظة: لقد قمت بتعديل المنشور الأصلي وفقًا لذلك
نعم. web-only وهذا مربك بعض الشيء عندما يكون في كل سياق آخر web_only. ولكن ربما عندما يكون شيء ما دليلًا أو حاوية-ما-هو-شيء مختلف.
ماذا أعرف… لقد أضعت 4 ساعات في القتال مع SearXNG وكان يجب أن تكون مهمة 5 دقائق (أنا حقًا أكره أشياء docker)
تعديل وخارج الموضوع
حقًا 
هل هو و ck كلمة محظورة؟ لقد تم تعليمنا في المدرسة على أنها كلمة غير مسيئة. لذا، لقد كانوا مخطئين، من الواضح 
أعتقد أنه ربما تمت إضافتها عندما كانت الكلمات الخاضعة للمراقبة قيد الاختبار ولم تتم إزالتها مطلقًا.
نعم. غالبًا ما أجد صعوبة في فهم ذلك. في الواقع، أعتقد أن هذا ربما هو السبب في أنني في مرة حاولت فيها فقط إعادة تسمية الأشياء للتبديل من حاوية واحدة إلى حاوية مزدوجة، أخطأت في استخدام الشرطة السفلية/الشرطة وتركت الأمر يفشل.
والأسوأ من ذلك، أنا متأكد من أن الخطأ مني. لقد واجهت بعض الأخطاء عندما أنشأت خيار الحاوية المزدوجة في discourse-setup (ربما لا يمكن أن تحتوي الحاويات على شرطات سفلية؟) تحب Ruby الشرطات السفلية في أسماء الملفات، لذا ربما لهذا السبب استخدمت شرطة سفلية هناك؟ أعتقد أن هذا هو السبب - وأعتقد أن web_only لا يمكن أن تعمل كاسم حاوية Docker لأنها تحتاج أيضًا إلى أن تكون أسماء مضيف صالحة.
أفضل الشرطات في مسارات الدليل، لذا كل شيء على ما يرام كما هو، والشرطة السفلية في اسم الحاوية بصراحة، منطقية، لذا اتركها كما هي.
بالمناسبة، أعتقد أنه يجب أن يكون هناك عنوان أو شارة معتمدة ذاتيًا على ميتا لأولئك الذين يستخدمون إعداد الحاوية المزدوجة 
بمجرد أن تقضي عامًا هنا، أعتقد أنه يجب أن يكون ترحيل عمليات التثبيت القياسية الخاصة بك إلزاميًا. 
لو لم يكن هناك الكثير من الوثائق الحالية حول إعداد الحاوية الواحدة، لكنت تقريباً أجادلت بأنه يجب أن يكون هو الإعداد الافتراضي، على الرغم من أنه ستكون هناك حاجة إلى بعض الأدوات لإعلام الأشخاص بأن قاعدة البيانات قد تحتاج إلى اهتمام، أو شيء من هذا القبيل.
غالباً ما أرى الكثير من الأشخاص غير الراضين والخائفين من عمليات تثبيت الحاويتين. (مؤخراً، أراد شخص ما نقل تثبيت الحاويتين الذي أنشأته عند إجراء التثبيت الخاص به إلى حاوية واحدة، على سبيل المثال.) نادراً ما يكون ذلك مشكلة، وفي المرة الوحيدة التي يسبب فيها مشاكل، فإنه في الواقع يوفر بعض المتاعب لأنه يسهل تأجيل ترقية Postgres حتى تكون مستعداً للقيام بذلك. يمكنك عادةً تأجيل ترقية PG لفترة طويلة (باستثناء عندما تمت إضافة المكون الإضافي للذكاء الاصطناعي إلى النواة وتطلب هذا الامتداد).
بدأت النسخ الاحتياطية الخاصة بي في الفشل بعد هذا:
[2025-09-09 09:34:50] Creating archive: blah-forum-2025-09-09-093246-v20250828181952.tar.gz
[2025-09-09 09:34:50] Making sure archive does not already exist...
[2025-09-09 09:34:50] Creating empty archive...
[2025-09-09 09:34:50] EXCEPTION: tar --create --file /var/www/discourse/public/backups/default/blah-forum-2025-09-09-093246-v20250828181952.tar --files-from /dev/null
tar: /var/www/discourse/public/backups/default/mvertigo-org-vestibular-disorders-support-forum-2025-09-09-093246-v20250828181952.tar: Cannot open: Permission denied
tar: Error is not recoverable: exiting now
بالنظر إلى الأذونات من داخل حاوية web_only:
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 root root 4096 Sep 6 12:37 default
إذا نظرت إلى مثيل آخر، فإن الملكية مختلفة:
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 discourse www-data 4096 Sep 9 03:46 default
ما الذي حدث خطأ هنا وماذا يجب أن أغير في هذا الدليل لحاوية web_only - هل يجب أن يكون هو نفسه للتثبيت القياسي؟
باختصار، ربما جرب
docker exec -it web_only bash
chown -R discourse:www-data /shared/backups
والمزيد من الكلمات.
بدون النظر، سأحاول بعد ذلك إعادة بناء حاوية البيانات، على أمل أن يكون أي تغيير تم إجراؤه قد تم إجراؤه أيضًا على حاوية البيانات (أو يؤثر عليها).
الإجابة السيئة هي جعل ...backups/default قابلة للكتابة من قبل الجميع ورؤية ملكية النسخة الاحتياطية.
لذلك أعتقد أن ما تريد القيام به هو تغيير ملكية default إلى discourse.www-data في حاوية الويب (وهي الحاوية التي تقوم بعمل النسخ الاحتياطي).
إليك حاوية واحدة حديثة:
root@forum.mbse-capella.org(app):~$ docker exec -it app bash
root@new-app:/# grep www /etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
root@new-app:/# grep discourse /etc/passwd
discourse:x:1000:1000::/home/discourse:/bin/bash
في بعض الأوقات في الماضي، كانت عملية البناء تقوم بتغيير ملكية جميع الملفات، ولكنها قد تستغرق وقتًا طويلاً جدًا، لذلك أعتقد أنه ربما تم إزالتها في وقت ما (هذا أكثر من مجرد شعور بدلاً من أي شيء يعتمد على الانتباه إلى الالتزامات).
هل هذا يعادل ./launcher enter web_only؟
في الغالب. ./launcher سيقوم بسحب git (على الأقل كنت أعتقد ذلك، ولكن ربما لا؟) أولاً ومن المرجح أن يكون لديك إكمال تلقائي لـ docker أكثر من ./launcher.
كما أنه يضعك في الجذر، بينما يضعك المشغل في دليل الخطاب
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 discourse www-data 4096 Sep 6 12:37 default
يبدو أن هذا يُحدث التعديل الصحيح، لذا دعنا نرى كيف ستسير الأمور مع النسخ الاحتياطي التالي، شكرًا!
يمكنك الآن تشغيل واحد من سطر الأوامر أو واجهة المستخدم الرسومية لمعرفة ما إذا كان قد نجح.
أيضًا، لو كنت أكثر ذكاءً:
docker exec -it web_only bash -c "chown -R discourse:www-data /shared/backups"
كنت صبورًا وانتظرت المهمة المجدولة (ولكن توثيق ذلك مفيد جدًا!) ويبدو أن ذلك قد نجح، لذا شكرًا جزيلاً على مساعدتك @pfaffman
هذه هي الطريقة التي نختلف بها.
نعم. كان هناك chown يعمل في كل إعادة بناء، أنا متأكد. يمكن أن يستغرق الأمر بعض الوقت، وهو دائمًا غير ضروري تقريبًا (إلا عندما لا يكون كذلك). ليس له علاقة بالحاويات الواحدة مقابل الحاويتين. أعتقد أن الأمر يتعلق بالانتقال من إصدار واحد من Debian للصورة الأساسية إلى إصدار آخر، والإصدار الجديد لديه تعيينات مستخدمين مختلفة عن الإصدار القديم.
هل المكون الإضافي docker_manager غير مفيد في هذا الإعداد - فهو يخبرني دائمًا بإعادة بناء التطبيق!
لست متأكدًا مما يعنيه “هذا” ولكن كلا الموضوعين والموضوع الذي أشير إليه مخصصان للتثبيت القياسي، لذا يعمل docker_manager كالمعتاد.
لا يرتبط Docker_manager بعملية الانتقال إلى خادم آخر، حيث يتعين عليك بناء حاوية جديدة.
يجب أن يجبرك على بناء تطبيق جديد عند حدوث تغيير في الصورة الأساسية، وهو ما أعتقد أنه كان يحدث كثيرًا مؤخرًا. بصراحة، لم أفهم تمامًا الآليات التي تعمل هناك.
كانت الطريقة التي اكتشفت بها ذلك بعد تهيئة web_only واستبدال (destroy, start) ، ثم ذهبت للتحديث بعد تغيير مكون إضافي واحد فقط، ليتم مطالبتي بإعادة بناء التطبيق!