Backup notifies failure on sidekiq restart, but backup succeeds

Product Support

AI-generated summary

A user reports that their Discourse site is notifying an admin of backup failure, but the backup actually succeeds. The logs show that Sidekiq is restarting during the backup process, causing an exception. However, the exception is caught, and the backup completes successfully. The user speculates that this is an improvement over previous behavior where backups would be left on local storage, potentially filling up the disk. They plan to increase Sidekiq’s memory allocation during the next container rebuild.

1

I’ve got a site that’s notifying an admin of backup failure, but the backup succeeds. Here’s the logs:

[2025-09-23 09:40:31] Removing tmp '/var/www/discourse/tmp/backups/default/2025-09-23-093005' directory...
[2025-09-23 09:40:31] Uploading archive...
[2025-09-23 09:41:37] EXCEPTION: Sidekiq::Shutdown
[2025-09-23 09:41:37] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/multipart_file_uploader.rb:199:in `value'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/multipart_file_uploader.rb:199:in `map'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/multipart_file_uploader.rb:199:in

So it looks like sidekiq is restarting, so it generates the error, but it’s caught, so the backup actually succeeds. I’m guessing (withtout looking at commits) that this is an improvement over the previous behavior when these backups would get left on local storage and eventually fill up the disk.

I’m going to increase memory for sidekiq next time the container gets rebuilt.

1 Like