Резервные копии S3 (не AWS) перестали работать, вероятно, после обновления

Поддержка
1

У меня настроено ведро, но, похоже, система пытается использовать ведро по умолчанию?

Я использую GarageHQ как легковесную альтернативу MinIO.

Версия: 3.6.0.beta1-dev
( ed6beea336 )

[2025-09-14 10:40:34] Удаление временной директории ‘/var/www/discourse/tmp/backups/default/2025-09-14-104012’…
[2025-09-14 10:40:34] Загрузка архива…
[2025-09-14 10:40:35] ИСКЛЮЧЕНИЕ: Ведро не найдено: default

[2025-09-14 10:40:35] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/dualstack.rb:21:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/accelerate.rb:43:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/checksum_algorithm.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:16:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/invocation_id.rb:16:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/seahorse/client/plugins/request_callback.rb:89:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/seahorse/client/plugins/response_target.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/telemetry.rb:39:in `block in call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/telemetry/no_op.rb:29:in `in_span'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/telemetry.rb:53:in `span_wrapper'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/telemetry.rb:39:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/seahorse/client/request.rb:72:in `send_request'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/client.rb:3710:in `create_multipart_upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/multipart_file_uploader.rb:67:in `initiate_upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/multipart_file_uploader.rb:58:in `upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/file_uploader.rb:42:in `block in upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/user_agent.rb:90:in `metric'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/file_uploader.rb:40:in `upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/customizations/object.rb:477:in `block in upload_file'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/user_agent.rb:90:in `metric'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/customizations/object.rb:476:in `upload_file'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:48:in `upload_file'
/var/www/discourse/lib/backup_restore/backuper.rb:351:in `upload_archive'
/var/www/discourse/lib/backup_restore/backuper.rb:41:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:9:in `backup'
/var/www/discourse/script/spawn_backup_restore.rb:31:in `block in <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'

Последняя резервная копия была создана вчера, но теперь она больше не работает. Другие службы всё ещё могут создавать резервные копии на моём локальном S3 без проблем.

Кто-нибудь знает, как это исправить?

2

Да. AWS сломал библиотеку S3 для множества других сервисов.

Вот несколько обходных путей: Can't rebuild due to AWS SDK gem bump and new AWS Data Integrity Protections

Я создал этот файл aws-revert-template.yml, чтобы откатиться к более старой версии. Не знаю, работает ли он до сих пор; мой файл датирован 2025-08-06T05:00:00Z

3

Хм, я не до конца убеждён, что это проблема, хотя

image
image917×583 24.7 KB

если я не ошибаюсь, я был на версии 3.6 дольше двух дней, а резервная копия была создана два и десять дней назад.

4

Не намного больше. Мне кажется, вы ошибаетесь.

Вот коммит, на котором вы находитесь:
UX: control event display through a site setting (#34795) · discourse/discourse@ed6beea · GitHub

image
image268×122 6.42 KB

Также:

Ваше ведро называется “default”?

5

Да, сейчас я на коммите. Изначально, когда я создал эту задачу, я не был на нём. Я обновился, чтобы исключить ошибку. Когда я создавал эту задачу, я был на версии 3.5.

6

нет, как указано в исходном сообщении, именно поэтому я не считаю, что речь идет об той же проблеме, о которой вы упоминаете. Мой бакет указан явно — я пробовал и в настройках UI раздела резервного копирования, и через переменные окружения в yaml, но он всё равно пытается использовать default.

чтобы прояснить: со стороны Discourse или Garage ничего не менялось с момента, когда всё перестало работать, кроме обновления до версии 3.5, а затем до 3.6.

7

Может, кто-то с реальным S3 проверит, правильно ли выбирается бакет? То же самое для других сторонних сервисов, таких как Backblaze, R2 и т. д.?

8

Итак, я создал бакет с именем “default”, и он работает как положено, так что да, он неправильно подхватывает имя бакета, которое я ему указываю.

image
image1111×339 11.5 KB

Похоже, это баг в Discourse.

9

Однако, если бы это было так, тысячи пользователей и хостинг CDCK тоже бы пострадали, но этого не происходит. Скорее всего, вы случайно удалили или добавили символ в строку вашего файла app.yml.

Вы можете выполнить такие команды:

grep -i S3 /var/discourse/containers/*

docker exec -it app bash -c 'grep s3 /var/www/discourse/config/discourse.conf'

Если вы настроили S3 через настройки, а не через переменные окружения, вы можете посмотреть статью Настройка совместимого с S3 провайдера объектного хранилища для загрузок, чтобы узнать, как это выглядит.

10

С моим окружением всё в порядке, ничего не менялось, кроме обновления Discourse. Я пробовал конфигурацию в YAML и через UI, в настройках UI буквально отображается «cyanlabs-community», но резервная копия всё равно пытается сохраниться в «default».

Screenshot_2025-09-18-21-47-29-55_3aea4af51f236e4932235fdada7d1643
Screenshot_2025-09-18-21-47-29-55_3aea4af51f236e4932235fdada7d16431115×259 74.2 KB

Несмотря на то, что S3 настроен в UI, файл discourse.conf не содержит никаких ссылок на S3, как указано в вашей второй команде.

Screenshot_2025-09-18-21-57-49-03_3aea4af51f236e4932235fdada7d1643
Screenshot_2025-09-18-21-57-49-03_3aea4af51f236e4932235fdada7d16431637×447 76.9 KB

11

Это означает, что ведра нет. Можете ли вы попробовать создать новое ведро и учетные данные, чтобы проверить, работает ли загрузка туда?

12

Спасибо, но у меня такое чувство, что я ходжу по кругу.

Бакет по умолчанию не существовал в начале этого обсуждения. Позже я создал его, и система использует его, несмотря на то, что в настройках указан бакет cyanlabs-community.

И cyanlabs-community, и default существуют в экземпляре S3, но Discourse не использует cyanlabs-community, что бы я ни пробовал.

Новый бакет cyanlabsdiscourse

image
image822×106 10.2 KB

Результат резервного копирования:

[2025-09-22 15:14:59] Завершение резервного копирования...
[2025-09-22 15:14:59] Завершение файла дампа базы данных: cyanlabs-official-community-2025-09-22-151437-v20250916082012.sql.gz
[2025-09-22 15:14:59] Удаление временной директории '/var/www/discourse/tmp/backups/default/2025-09-22-151437'...
[2025-09-22 15:14:59] Загрузка архива...
[2025-09-22 15:15:37] Выполнение after_create_hook для резервной копии...
[2025-09-22 15:15:37] Удаление старых резервных копий...
[2025-09-22 15:15:37] Очистка временных файлов...
[2025-09-22 15:15:37] Удаление архива из локального хранилища...
[2025-09-22 15:15:37] Удаление остатков '.tar'...
[2025-09-22 15:15:37] Пометка резервной копии как завершенной...
[2025-09-22 15:15:37] Обновление статистики диска...
[2025-09-22 15:15:37] Уведомление 'CyanLabs' об окончании резервного копирования...
[2025-09-22 15:15:40] Готово!

Бакет cyanlabsdiscourse

image
image1122×661 12 KB

Бакет default

image
image1049×543 23.5 KB

Интересно, что система всё ещё пытается установить соединение по адресу bucketname.s3.domain.tld, например cyanlabsdiscourse.s3.domain.tld. Без добавления DNS-записи это не сработало бы на таком под-поддомене. Значит, настройка учитывается при формировании URL, но, похоже, игнорируется при выборе бакета.

13

Мне кажется, я перепробовал всё, так что пока, думаю, буду использовать бакет по умолчанию.

14

AWS может быть загадочным! Жаль, что вам не удалось использовать желаемое имя бакета. Без возможности воспроизвести проблему трудно помочь, так что, похоже, вам придется смириться с использованием имени бакета по умолчанию.