Если вам нужна помощь в выявлении коренной причины подобных проблем, пожалуйста, дайте мне знать. Я с радостью помогу.
Итак, я попытался восстановить резервную копию размером 2,2 ГБ и получил следующее сообщение об ошибке: восстановление не удалось:
ИСКЛЮЧЕНИЕ: 44 сообщения не были переназначены на новый URL загрузки S3. Миграция S3 не удалась для базы данных ‘default’.
Я использую версию 2.6b6, то есть довольно свежую. Сам сайт старый, создан в 2016 году.
Время от времени мы сталкиваемся с резервными копиями, где автоматическое переназначение и миграция в S3 не удаются по разным причинам.
Это старая тема, поэтому есть ли какие-либо рекомендации по исправлению ситуации? Наличие резервной копии, которую я не могу использовать для восстановления, вызывает у меня беспокойство.
Редактирование: Я только что понял, что, возможно, оказался не в той ветке, так как это похоже на ту же проблему
Я снова попробовал, но всё ещё получаю ошибку «restore to the 44 posts are not remapped».
Временное отключение загрузки в S3 перед резервным копированием (предложенное @RGJ) не решает проблему, и в данный момент у меня нет рабочей схемы резервного копирования, что довольно серьёзно.
Есть ли какие-либо предложения, что можно попробовать?
Ладно, это самый странный случай, с которым я сталкивался на данный момент. Я наткнулся на этот пост.
https://meta.discourse.org/t/using-object-storage-for-uploads-s3-clones/148916/160?u=ljpp
После того как я уже потратил на это часы, я для интереса определил DISCOURSE_CDN_URL — функцию, которую мой сайт не использует. Резервная копия была восстановлена успешно.
Каково значение этого параметра в данной ситуации? @Falco @pfaffman
РЕДАКТИРОВАНИЕ:
Я передумал. После успешного теста я сделал свежую резервную копию с продакшена и снова начал миграцию на новый сервер. Сбой повторился, но сообщение об ошибке изменилось.
ИСКЛЮЧЕНИЕ: rake posts:missing_uploads выявил 3 проблемы. Миграция S3 не удалась для базы данных «default».
РЕДАКТИРОВАНИЕ 2:
Итак, я продолжил копаться в базе данных и нашёл эти 3 поста.
- Два были очень старыми изображениями, которые сначала были опубликованы, но затем модератор заменил их на модифицированные версии. Они датированы 2016 и 2018 годами.
- Но последний был странным. Это был очень свежий пост, опубликованный мной всего пару недель назад, содержащий oneboxed https:// ссылку на сервер разработки, который больше не существует. Таким образом, битая ссылка нарушает процесс восстановления.
Я просто удалил эти посты вручную.
Теперь, снова, тестовый запуск показывает, что резервное копирование может на самом деле завершиться успешно. Посмотрим.
@ljpp Похоже, я столкнулся с похожей ситуацией: восстановление завершается ошибкой
EXCEPTION: 1 пост не переназначен на новый URL загрузки S3. Миграция S3 для базы данных ‘default’ не удалась.
Можете подробнее рассказать, как вы нашли и удалили проблемные посты? Какие команды использовались?
Он удалил спорные посты.
Но ты переустановил систему, так что ты не можешь этого сделать, верно?
У меня эта проблема при восстановлении базы данных. Как вы нашли проблемные посты?
Кажется, код, который выполняет проверку, находится здесь:
Так что, думаю, это:
prefix = @migrate_to_multisite ? "uploads/#{@current_db}/original/" : "original/"
base_url = File.join(SiteSetting.Upload.s3_base_url, prefix)
bad = Upload.by_users.where("url NOT LIKE '#{base_url}%'")
А для уверенности:
good = Upload.by_users.where("url LIKE '#{base_url}%'")
Дайте знать, если это сработает для вас, и я займусь созданием темы.
discourse(prod)> prefix = @migrate_to_multisite ? “uploads/#{RailsMultisite::ConnectionManagement.current_db}/original/” : “original/”
discourse(prod)> base_url = File.join(SiteSetting.Upload.s3_base_url, prefix)
discourse(prod)> bad_uploads = Upload.by_users.where(“url NOT LIKE ‘#{base_url}%’”)
discourse(prod)> bad_uploads.count
=> 0
Эта проверка дала мне 0 ошибок
Вы сделали это на оригинальном сервере? Или нужно выполнить это после восстановления базы данных, до проведения этой проверки, используя флаг --pause
Я делал это на старом сервере.
При восстановлении я получил ту же ошибку:
[2026-01-16 13:45:52] EXCEPTION: 3 поста не перенаправлены на новый URL загрузки S3. Миграция S3 не удалась для базы данных «default».
[2026-01-16 13:45:52] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log’
Ну, чёрт. Не знаю, что ещё тебе сказать.
Нашла ли команда good твои загрузки?
Я бы, наверное, просто использовал переключатель --pause и остановил восстановление до того, как она выполнит эту проверку.
Сделай то, что сказал Ричард.
Я не уверен в вашей конкретной ситуации, но, возможно, вам стоит просто отключить загрузку в S3, создать резервную копию, восстановить данные и снова включить её. Это спасало меня множество раз.
Значит, мне нужно отключить эту опцию, верно?
Верно.
- Снимите галочку с пункта «Включить загрузки S3».
- Создайте резервную копию или скачайте данные.
- Загрузите или восстановите данные.
- Установите галочку в пункте «Включить загрузки S3».
Я не говорю по-итальянски, если речь не о еде… Может, вы сможете сделать нам всем одолжение и скопировать/вставить это в Google Translate 
Извините.
Включить загрузку в S3
Хранение загруженных файлов на дисковом пространстве Amazon S3. ВАЖНО: необходимо предоставить действительные учетные данные S3 (как идентификатор ключа доступа, так и секретный ключ доступа).
Вы не можете включить загрузку в S3, так как она уже включена глобально. Включение загрузки в S3 на уровне сайта может вызвать критические проблемы с загрузкой файлов.
Я предполагаю, что вы уже сделали это в app.yml.
Загрузка (новых) файлов работает корректно? Если да, то проблем нет.
В app.yml у меня настроен S3, верно.
Так что мне нужно сделать для безопасного резервного копирования и восстановления без проверки загрузок?
Просто снять галочку «включить загрузку в S3» не помогает