Esto ha estado sucediendo durante mucho tiempo; tengo un recordatorio mensual en mi calendario para eliminar estos archivos sobrantes. Los registros de copias de seguridad están vacíos: “Aún no hay registros…” y nada en los registros de errores apunta a problemas con Amazon S3.
Discourse se actualiza regularmente y actualmente es la versión 2.9.0.beta14.
Esta es una instalación estándar, ¿verdad? ¿Existe la posibilidad de que el sistema operativo (o algo más) esté interrumpiendo el proceso de copia de seguridad durante la carga? Porque incluso cuando hay un error de copia de seguridad, el archivo local debería eliminarse al final del proceso.
Usé un servicio compatible con S3 durante un tiempo que a veces dejaba copias de seguridad en el disco local, pero era intermitente.
Mirarías en /var/discourse/shared/standalone/logs/rails/production.log. Simplemente ejecutaría una copia de seguridad desde la línea de comandos y vería si tiene el comportamiento de “and”.
Los registros de producción solo se remontan a una semana, por lo que las copias de seguridad más antiguas “no eliminadas” quedan fuera de ese rango, pero vigilaré las futuras. La única entrada de error de copia de seguridad fue esta en el registro del 30/11:
Started GET \"/.env.backup\" for 3.236.147.46 at 2022-11-29 19:15:57 +0000
ActionController::RoutingError (No route matches [GET] \"/.env.backup\")
Veo una nueva copia de seguridad no eliminada en /var/discourse/shared/standalone/backups/default, pero nada en production.log. Tampoco hay nada en production_errors.log. ¿Dónde más podría buscar?
P.D. Ejecuté una copia de seguridad desde la línea de comandos y la copia de seguridad se eliminó correctamente. Intentaré eso unas cuantas veces más para ver si obtengo un error allí.
No tengo éxito reproduciendo la copia de seguridad local no eliminada a través de la CLI, pero sigue ocurriendo una o dos veces por semana durante la copia de seguridad nocturna. Tampoco veo ninguna salida del registro de copia de seguridad en production.log. ¿Está seguro de que ahí es donde está escrito, @pfaffman?
Creo que debería ser así. Cuando tuve un problema similar con algún otro servicio S3, no pude encontrar errores ni en Discourse ni en su servicio. Y me di por vencido y cambié a otra cosa. Pero tú usas AWS, S3, el verdadero negocio, así que estoy bastante sorprendido.
He intentado buscar así: grep -r "Output file is stored on S3" /var/discourse
ya que esa frase es la última línea de la salida de la copia de seguridad de la CLI, pero no se encuentra nada.
¿Hay alguna posibilidad de que el servidor se reinicie debido a actualizaciones automáticas del sistema operativo anfitrión? Podrían ocurrir mientras la carga a S3 está en progreso. ¿Hay algo en los registros de su sistema operativo? Quizás restablecer la configuración del sitio backup_time_of_day al valor predeterminado o a una hora diferente y ver si el problema desaparece.
No, el tiempo de actividad actual es de 36 días. Había sospechado que la copia de seguridad de la instancia de DigitalOcean que se ejecutaba simultáneamente podría haber sido la causa, pero eso ocurre una vez por semana y mis copias de seguridad no eliminadas ocurren con más frecuencia que eso.
Probaré con un backup_time_of_day diferente. Estaba configurado a las 2:00 UTC, así que veremos si las 3:30 UTC predeterminadas marcan alguna diferencia.
¡¡¡OOOOH! Esa es buena. Eso lo explicaría. Apuesto a que es eso. Y la mitad de la noche es un buen momento tanto para las copias de seguridad como para los reinicios. No explica del todo por qué el problema desapareció cuando cambié a un servicio diferente, pero tal vez mi suerte simplemente cambió, o lo que sea que cambié era más rápido o algo así.
Dieciséis días después, parece que esta fue la solución: no más copias de seguridad no eliminadas. No sé qué estaba causando el conflicto, pero ya no importa.
