Проблемы с резервным копированием multisite на S3 — резервные копии хранятся в корне

Поддержка Самостоятельное хостинг
1

У меня есть экземпляр с несколькими сайтами на AWS EC2. Настройки резервного копирования выглядят так:

DISCOURSE_S3_BACKUP_BUCKET: lc-sitename
DISCOURSE_S3_SECRET_ACCESS_KEY: secret-key
DISCOURSE_S3_ACCESS_KEY_ID: key-id
DISCOURSE_BACKUP_LOCATION: s3

Резервные копии для экземпляров с несколькими сайтами сохраняются в корневой директории бакета, но не отображаются в списке в интерфейсе. Резервные копии для основного сайта, как и ожидалось, сохраняются в папке default. Это означает, что резервные копии не видны при восстановлении и не удаляются в соответствии с настройками.

Конфигурация для нескольких сайтов выглядит так:

        site:
           adapter: postgresql
           database: site
           pool: 25
           timeout: 5000
           host: data
           password: secret
           host_names:
             - community.site.org

Возможно ли, что если переменная DISCOURSE_USE_S3 не установлена, резервные копии попадают в неправильное место? (Я пробовал установить use_s3 в файле discourse.conf, но не перезапускал unicorn, а вместо этого выполнил команду резервного копирования из командной строки, и оно всё равно сохранилось в корневой директории, а не в папке с именем подсайта).

Ранее была проблема с загрузками в S3 (возможно, из-за неправильной конфигурации бакета), поэтому S3 используется только для резервного копирования.

2

Я потратил на это ещё полтора часа.

Один из сайтов в мультисайте правильно помещает свои загрузки резервные копии в нужную директорию, а два других — нет.

Те, которые сохраняются не в то место, были восстановлены из односайтового экземпляра, поэтому я предполагаю, что в базе данных есть что-то, что заставляет резервную копию сохраняться в корень папки резервных копий, а не в папку с именем сайта (или в папку по умолчанию для сайта по умолчанию).

@gerhard, извините за беспокойство, но не могли бы вы быстро взглянуть, нет ли чего-то очевидного, что я упускаю?

3

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

      was_multisite = BackupMetadata.value_for("multisite") == "t"
      upload_path = "/#{Discourse.store.upload_path}/"
      uploads_folder = was_multisite ? "/" : upload_path

Но речь ведь шла о том, куда помещаются резервные копии, а не о том, куда восстанавливаются изображения?

4

Да.

Это верно.

Но, ой:

Как я (правильно) говорил ранее, этот экземпляр (на данный момент?) использует S3 только для резервных копий, а не для загрузок.

Резервные копии для 2 из 3 подсайтов помещаются в корень бакета для резервных копий. Основной сайт отправляет их в default, как и ожидалось, и один из экземпляров мультисайта отправляет их в директорию sitename.

5

Хм, это странное поведение. Вы имеете в виду резервные копии, загружаемые через браузер, или созданные системой?

Я не вижу причин, по которым резервные копии, созданные системой, оказались бы не в том месте. Код выглядит довольно прямолинейно.

s3_helper настроен с правильным именем бакета и мультисайта.

6

Я имею в виду, что создание резервной копии как через веб-интерфейс, так и через задачу rake для двух из трёх хостов мультисайта (которые были мигрированы с другого сервера) загружает резервную копию в корень бакета S3 для резервных копий, а не в sitename/backupname.

Мне это тоже кажется странным.

Я попробую добавить несколько puts в эти функции, чтобы попытаться отследить проблему.

Кажется, я выводил через puts source_path, и он содержал правильный полный путь в ОС, но при загрузке в S3 имя сайта исчезает из пути.

Я ещё раз внимательно изучу это на следующей неделе. Резервные копии на месте, просто они не там, где Discourse их найдёт.