Я пробую несколько вариантов с Cloudflare и в будущем планирую отказаться от R2. Именно поэтому, когда я проверял резервные копии, обнаружил, что установки не включены, и возникла ошибка. При ручном создании резервной копии та же ошибка появляется в логах транзакций. Локальные изображения и файлы резервируются, но изображения, хранящиеся в Cloudflare R2, не резервируются.
Пример кода ошибки:
Failed to download original/1X/4b8754c367e54bc5271454a09b8bd4c1a8b882d5.png because Aws::S3::Errors::Http501Error
/var/www/discourse/lib/s3_helper.rb:280:in `rescue in download_file'
/var/www/discourse/lib/s3_helper.rb:277:in `download_file'
/var/www/discourse/lib/file_store/s3_store.rb:338:in `download_file'
/var/www/discourse/lib/backup_restore/backuper.rb:321:in `block in add_remote_uploads_to_archive'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.0.8.4/lib/active_record/relation/batches.rb:71:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.0.8.4/lib/active_record/relation/batches.rb:71:in `block in find_each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.0.8.4/lib/active_record/relation/batches.rb:138:in `block in find_in_batches'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.0.8.4/lib/active_record/relation/batches.rb:245:in `block in in_batches'
<internal:kernel>:187:in `loop'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.0.8.4/lib/active_record/relation/batches.rb:229:in `in_batches'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.0.8.4/lib/active_record/relation/batches.rb:137:in `find_in_batches'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.0.8.4/lib/active_record/relation/batches.rb:70:in `find_each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.0.8.4/lib/active_record/querying.rb:22:in `find_each'
/var/www/discourse/lib/backup_restore/backuper.rb:315:in `add_remote_uploads_to_archive'
/var/www/discourse/lib/backup_restore/backuper.rb:248:in `create_archive'
/var/www/discourse/lib/backup_restore/backuper.rb:40: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/R2, что вам не нужно делать резервные копии этих данных. Однако есть скрытая настройка, которая скачивает все изображения из S3 и добавляет их в резервную копию.
О, но у вас включено DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true.
Возможно, R2 работает не так, как предполагалось изначально. Мне казалось, что я тестировал и всё работало, но я не проверял скачивание изображений в резервную копию и, скорее всего, не пробовал выполнять восстановление или скачивать файл резервной копии.
Это, вероятно, стоит обсудить в той другой теме, так как это, похоже, противоречит гипотезе «возможно, это работает», изложенной там.
Эта настройка активна, но, к сожалению, при создании резервной копии изображения из R2 не импортируются. Это можно увидеть в логе при выполнении ручной резервной копии.
Я ещё не решил и думаю отказаться от CDN в пользу локального хранилища. На самом деле это ожидаемое поведение, на случай, если мнения изменятся.
Я снова подниму этот вопрос, но с каждым автоматическим резервным копированием файл заполняется кодами ошибок. Если файл не был скопирован, думаю, лучше не запрашивать файлы в S3, чтобы не тратить время. Таким образом, мы не будем заполнять файл ненужными кодами ошибок.
Мой прогноз: загрузка не позволит, так как система пытается защитить вас от кражи всех ваших изображений. Похоже, это ещё один случай несовместимости R2 с Discourse.
Я на R2 уже давно. Всё выглядит хорошо, есть лишь несколько проблем (как выше), но их можно исправить. Со временем сообщество займётся этой проблемой, а пока удачи вам
Это интересно! Я видел, как вы жаловались только на то, что не работало. Мои быстрые тесты показывали, что всё работает, но я не проводил их в полном объёме.
Мое лучшее предположение — какое-то ограничение скорости при загрузке для резервного копирования, хотя, по логике, должны были быть ошибки?
После ваших тестов мы запустили R2, и вот какие проблемы с R2 у меня возникли:
Когда я отключил S3, соединения превратились в странные R2-соединения (то, что я видел при просмотре в Docker). Когда я попытался исправить это и перекомпилировать, изображения на сайте стали «летать» и искажаться. После нескольких попыток я настроил R2 только для загрузки и использую его. Пока я не нашёл способа полностью от него избавиться (или не смог).
Ещё была проблема: при создании резервной копии выводилось сообщение об ошибке. Учитывая, что у нас 10 тысяч изображений, это зря заполняет логи ошибок. Из-за этого мы иногда можем упустить важные проблемы. (Возможно, лучше было бы не выводить сообщение об ошибке, но при этом стоит отметить, что данные из S3 не будут добавлены в резервную копию).
Насколько я помню, других проблем не было. Если мне нужно сделать резервную копию файлов на R2, я могу подключиться через WinSCP и скачать их на свой компьютер. Если кто-то столкнётся с этим, давайте оставим заметку здесь
Только что до меня дошло, что пользователи S3 могут отключить эту настройку «резервное копирование при загрузке». Так что мы можем избавиться от сообщения об ошибке. Почему я раньше об этом не подумал…
