Las copias de seguridad en S3 han estado funcionando durante varios años. Desde hace un mes, a menudo recibo varias notificaciones de que la copia de seguridad falló. Luego intenta de nuevo, y aproximadamente una hora después falla otra vez, por lo que recibo una segunda notificación, y a menudo hasta seis notificaciones en un día antes de que finalmente tenga éxito.
El registro de la notificación dice que no puede subir el archivo tar comprimido a S3. No puedo encontrar ningún error en mi cuenta de S3.
4etalles5e
3resumen5e
La primera parte del registro parece normal, luego:
[2025-05-20 07:11:38] Finalizando copia de seguridad…
[2025-05-20 07:11:38] Creando archivo: 506-investor-group-2025-05-20-070428-v20250513161753.tar.gz
[2025-05-20 07:11:38] Asegurándose de que el archivo no exista ya…
[2025-05-20 07:11:38] Creando archivo vacío…
[2025-05-20 07:11:38] Archivando volcado de datos…
[2025-05-20 07:12:17] Archivando cargas…
[2025-05-20 07:15:48] Eliminando directorio tmp ‘/var/www/discourse/tmp/backups/default/2025-05-20-070428’…
[2025-05-20 07:15:48] Compressed archive, esto puede tomar un tiempo…
[2025-05-20 07:32:51] Subiendo archivo…
¿Podría quedarse sin memoria? Esa excepción me hace pensar que Sidekiq (que ejecuta las copias de seguridad automáticas) está siendo eliminado por el sistema operativo o se bloquea por alguna otra razón.
¿Intentaste reconstruir el contenedor de Docker (./launcher rebuild app) para ver si eso lo soluciona?
No lo creo. El servidor es excesivo para nuestra comunidad con 16 GB de RAM. top muestra 11 GB de memoria libre, y eso apenas cambia si activo manualmente una copia de seguridad.
Revisaré /var/log/syslog mañana en busca de algo sobre memoria, kill u OOM. (No puedo revisarlo hoy porque tuve un registro detallado no relacionado y el evento de copia de seguridad se sale del búfer de syslog).
Sí, me actualicé a 3.5.0.beta5-dev hace unos días y el problema persiste.
Tengo esto en /logs. Esta advertencia en particular no coincidió con la copia de seguridad; lo comprobaré por la mañana (las copias de seguridad se hacen por la noche). Pero no me di cuenta de que Discourse tuviera su propia verificación de memoria; pensé que te referías al OOM killer. ¿Puedo aumentar el tamaño de memoria permitido para Sidekiq?
Mensaje
Sidekiq está consumiendo demasiada memoria (usando: 547.87M) para ‘ip-172-26-9-xxx-app’, reiniciando
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in block in warn' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in block in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in each' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in dispatch’
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in warn' /var/www/discourse/lib/demon/sidekiq.rb:59:in block in rss_memory_check’
/var/www/discourse/lib/demon/sidekiq.rb:53:in each' /var/www/discourse/lib/demon/sidekiq.rb:53:in rss_memory_check’
config/unicorn.conf.rb:132:in `block (2 levels) in reload’