Discourse لا تحذف النسخ الاحتياطية المحلية المؤقتة بعد تحميلها إلى S3

تثبيت
,
1

تشغيل 3.2.0.beta4-dev ( 86da47f58d ) ولكن هذه المشكلة موجودة لدينا منذ فترة الآن.

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

root@forum:/var/discourse/shared/standalone/tmp/backups/default# du -sh
57G     .
root@forum:/var/discourse/shared/standalone/tmp/backups/default# du -k
7073520 ./2023-12-28-063845
8040176 ./2023-12-29-063923
8521220 ./2024-01-08-063857
4909616 ./2023-12-24-064434
4918056 ./2024-01-07-064325
7079136 ./2024-01-03-064430
7077984 ./2024-01-02-063855
2949660 ./2024-01-09-063708
59088404        .
root@forum:/var/discourse/shared/standalone/tmp/backups/default# rm -Rf *

هل يمكن أن تكون هذه مشكلة في الأذونات على الدليل، ربما؟ بالتأكيد لم أقم بتغييرها.

root@forum:/var/discourse/shared/standalone/tmp/backups# ls -la
total 12
drwxr-xr-x 3 mas www-data 4096 Nov 23 06:44 .
drwxr-xr-x 4 mas www-data 4096 Nov 22 04:57 ..
drwxr-xr-x 2 mas www-data 4096 Jan  9 15:35 default

الغريب هو أنه من قائمة ملفات tmp، نرى أن يناير 2 و 3 و 7 و 8 و 9 تستهلك مساحة. من قائمة النسخ الاحتياطية في Discourse في واجهة المسؤول، أرى فقط 4 يناير. لذا ربما يأخذ Discourse تلك النسخ الاحتياطية ولكنه لا يقوم بتحميلها بشكل صحيح إلى S3؟ المشكلة في هذه النظرية هي أن “تردد النسخ الاحتياطي” تم تعيينه على 3 في تكوين المسؤول، لذلك لا ينبغي أن يحاول النسخ الاحتياطي كل يوم على أي حال. لاحظ أن سجلات النسخ الاحتياطي في واجهة المسؤول فارغة، لا توجد سجلات هناك.

image
image819×108 5.76 KB

Untitled
Untitled1198×243 29.9 KB

2

أفضل تفسير لدي هو أن الخادم يعيد التشغيل أحيانًا قبل أن يتمكن من حذف ملف النسخ الاحتياطي المحلي.

قائمة النسخ الاحتياطي تعرض ما هو موجود على S3، وليس على محرك الأقراص المحلي الخاص بك.

هل يقوم شخص ما بتشغيل نسخة احتياطية يدويًا؟

3

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

لا توجد نسخ احتياطية يدوية مني، وبالتأكيد ليست واحدة كل يوم. لا شيء في cron وما إلى ذلك أيضًا.

root@forum:/# uptime
 17:20:56 up 90 days,  1:52,  4 users,  load average: 0.81, 1.71, 1.81
root@forum:/# docker ps
CONTAINER ID   IMAGE                 COMMAND        CREATED       STATUS       PORTS                                                                      NAMES
d8bc34250454   local_discourse/app   \"/sbin/boot\"   6 weeks ago   Up 6 weeks   0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp   app
إعجاب واحد (1)
4

ما زال يحدث، تنهد. أعتقد أنني سأقوم بجدولة أمر find -mtime +2 -delete. أوقات جيدة.

root@forum:/var/discourse/shared/standalone/tmp/backups/default# du -sh
14G     .
root@forum:/var/discourse/shared/standalone/tmp/backups/default# ls -la
total 16
drwxr-xr-x 4 mas www-data 4096 Jan 16 06:56 .
drwxr-xr-x 3 mas www-data 4096 Nov 23 06:44 ..
drwxr-xr-x 2 mas www-data 4096 Jan 14 06:38 2024-01-14-063807
drwxr-xr-x 2 mas www-data 4096 Jan 15 06:43 2024-01-15-064337
إعجاب واحد (1)
5

تباً. كان هذا أفضل تخمين لدي.

نعم. قد يكون هذا هو ما يجب فعله.

6

تم. ليس الحل الأكثر أناقة أو إرضاءً، لكنني أعتقد أن المشكلة حُلت.

إعجاب واحد (1)
7

نعم. أعتقد أن هذا ما سأفعله في المرة القادمة التي أواجه فيها هذه المشكلة.

إعجابَين (2)