Эта тема с 4-го поста переросла в «Восстановление с ошибками», что сейчас является основной проблемой. Вы можете проигнорировать первые 4 поста.
Я настраивал загрузку в AWS S3 несколько лет назад, в самом начале.
Даже когда я (насколько мне известно) никогда не включал опцию включения загрузок S3 в резервные копии, вчера, когда я выбрал включение «Загрузок» в резервные копии, в моём логе появилось следующее:
Это вызывает несколько любопытных несоответствий, которые меня сбивают с толку:
Вчера вечером я включил опцию в настройках администратора для включения «Загрузок» в резервные копии. Затем, когда я просмотрел мою локальную папку «Общие загрузки» через WinSCP, там оказалось менее 100 файлов только в одной папке (других папок 2x, 3x там не существует; при необходимости могу предоставить скриншот). Так почему же в логе резервного копирования указано, что было загружено около 3 тысяч файлов? («Не удалось загрузить» — это ещё одна проблема в этих логах, но это отдельный вопрос). Если файлы загружаются из локального хранилища, то где находятся все эти файлы? А если они загружаются из S3, то почему? Ведь я никогда не менял эту опцию в консоли Rails для включения данных S3 в резервные копии, и также не создавал подобных опций в секции Env моего yml-файла.
Сегодня я изменил эту опцию в консоли Rails на «True». Теперь, при запуске задачи резервного копирования, было показано, что загружено около 3,2 тысяч файлов, и около 100 «Не удалось загрузить». Однако при проверке моего бакета AWS S3 оказалось, что там почти в 10 раз больше файлов — около 32 тысяч файлов общим объёмом около 3 ГБ. Так почему же не загружаются все эти файлы?
Неужели нет способа сверить/синхронизировать все эти данные и, возможно, узнать, какие несоответствия возникают и где?
Сейчас я очень растерян и не знаю, что делать. Моя конечная цель — перенести моё (слишком дорогое) хранилище AWS на более дешёвый вариант (сам Hetzner, где работает мой VPS, очень и очень недорогой, поэтому я могу увеличить объём хранилища и на основном сервере).
Спасибо. Пожалуйста, подскажите, в каком направлении двигаться.
Даже когда моя папка ‘Uploads’ (в бакете AWS S3) превышает 3 ГБ (3,2 тыс. файлов), почему резервные копии составляют чуть меньше 1 ГБ (с загруженными в резервную копию всего 2,9 тыс. файлов), даже после включения опции ‘include_s3_uploads_in_backup’ через rails console?
Эта настройка загружает файлы во временный каталог и включает их в резервную копию. Она не помещает их в каталог загрузок. Чтобы они оказались в каталоге загрузок, необходимо восстановить резервную копию. Я бы сделал это на новом сервере, чтобы в случае возникновения проблем ваш исходный сервер остался нетронутым.
Похоже, что некоторые файлы могут отсутствовать. Есть ли у вас сообщения с отсутствующими изображениями? Другой возможной причиной является то, что таблица загрузок содержит записи о файлах, на которые больше нет ссылок в сообщениях, поэтому отсутствие этих изображений не имеет значения.
Если их всего около 100, то, скорее всего, это не такая уж большая проблема.
Или же, возможно, какая-то ошибка в прошлом очистила (удалила) файлы, которые следовало сохранить.
Чтобы увидеть загруженные файлы, вам нужно скачать файл резервной копии и проверить, что в него включено. Восстановите резервную копию на новом сервере, чтобы посмотреть, как это работает.
Но главный вопрос в том, почему резервная копия весит чуть меньше 1 ГБ (содержит всего 3100 файлов), даже если папка S3 ‘Uploads’ занимает 3,2 ГБ и содержит 32 тысячи файлов. (В логах резервного копирования чётко указано, что было загружено лишь около 10%, то есть 3 тысячи файлов).
[Мне довольно неудобно создавать новую установку Discourse на другом домене для проверки этого, хотя я считаю, что создать снимок и, при необходимости, откатить свой, не слишком загруженный, сайт обратно за 5 минут без лишних хлопот — это очень просто].
Что ж, я подумал, что даже после изменения опции в Rails C, не помешает добавить эту строку и в yml: DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true, думая, что, возможно, это заставит систему подтянуть все мои загрузки из AWS S3.
Однако, после изменения этой опции в yml, пересборки контейнера и запуска резервного копирования, я обнаружил те же строки в логах резервного копирования (3000 загрузок медиафайлов и около 100 сбоев).
А когда я попытался восстановить (я ещё не менял настройки загрузок/S3 в своих административных настройках), возникла ошибка.
Полный лог:
```
Итак, я отключил загрузку в S3, а затем попытался восстановить мою резервную копию размером 1 ГБ (сама резервная копия всё ещё находится в AWS S3), но снова произошла ошибка. Что может пойти не так в этой ситуации?
Кроме того, после неудачной попытки восстановления я был разлогинен, а при повторном входе увидел баннер с сообщением о том, что все адреса электронной почты, не принадлежащие сотрудникам, отключены. Когда я попытался получить доступ к логу по ссылке, полученной на почту, файл не был найден/недоступен (отобразилась моя настроенная страница ошибок).
Во время попытки восстановления, непосредственно перед разлогиниванием, я видел следующие сообщения в логе:
[2024-08-19 04:12:58] 'Bathinda_Helper' начал восстановление!
[2024-08-19 04:12:58] Пометка восстановления как запущенного...
[2024-08-19 04:12:58] Проверка существования /var/www/discourse/tmp/restores/default/2024-08-19-041258...
[2024-08-19 04:12:59] Загрузка архива во временный каталог...
При следующей попытке «FAILED-restore» мне удалось нажать на ссылку к логу непосредственно перед выходом из системы. Вот она: log- failed restore.txt (98.9 KB)
Я провёл некоторые эксперименты и подтвердил, что новые загрузки действительно создаются на моём локальном сервере Ubuntu. Однако восстановление их из S3 на локальный сервер не удаётся. Но дело в том, что в нескольких проверенных мной постах изображения из S3 всё ещё отображаются (они не пропали).
Помогите, пожалуйста. Восстановление снова и снова не удаётся.
Кроме того, после «Неудачного восстановления», даже при входе в систему с тем же администратором, я не могу получить доступ к вложению «Log.txt». Вместо этого отображается страница «Страница недоступна» или страница ошибки моей настройки.
На самом деле я пытался сделать ровно то же самое, что показано на ваших скриншотах в посте, на который вы ссылаетесь выше. В любом случае, сейчас я ограничусь только «восстановлением Discourse».
Как я понял (и надеюсь, что так и есть), мне не нужно указывать путь к файлу резервной копии (.tz), где бы он ни лежал; система автоматически найдет его в папке резервных копий на моем локальном сервере.
