Это происходит уже давно — у меня в календаре стоит ежемесячное напоминание удалять эти оставшиеся файлы. Логи резервного копирования пусты: «Логи пока отсутствуют…», и в логах ошибок нет указаний на проблемы с Amazon S3.
Discourse обновляется регулярно и сейчас находится на версии 2.9.0.beta14.
Это стандартная установка, верно? Есть ли вероятность, что ОС (или что-то другое) прерывает процесс резервного копирования во время загрузки? Ведь даже при сбое резервного копирования локальный файл должен удаляться в конце процесса.
Я какое-то время использовал совместимый с S3 сервис, из-за чего иногда на локальном диске оставались резервные копии, но это происходило нерегулярно.
Проверьте /var/discourse/shared/standalone/logs/rails/production.log. Просто запустите команду резервного копирования через командную строку и посмотрите, сохраняется ли это поведение.
Логи производства хранятся только за последнюю неделю, поэтому более старые «неудаленные» резервные копии выпадают из этого диапазона, но я буду следить за будущими. Единственная запись об ошибке резервного копирования в логе от 30.11 была следующей:
Started GET "/.env.backup" for 3.236.147.46 at 2022-11-29 19:15:57 +0000
ActionController::RoutingError (No route matches [GET] "/.env.backup")
Я вижу новую неотменённую резервную копию в /var/discourse/shared/standalone/backups/default, но в production.log ничего нет. В production_errors.log тоже пусто. Где ещё можно посмотреть?
P.S. Я запустил резервное копирование из CLI, и резервная копия была успешно удалена — я попробую это ещё несколько раз, чтобы проверить, не появится ли ошибка.
Мне не удалось воспроизвести восстановление локальной резервной копии через CLI, но это продолжает происходить один или два раза в неделю во время ночного резервного копирования. Я также не вижу никакого вывода журнала резервного копирования в production.log. Вы уверены, что он записывается именно туда, @pfaffman?
Должно быть, да. Когда у меня была похожая проблема с каким-то другим сервисом S3, я не смог найти ошибок ни в Discourse, ни в их сервисе. В итоге я сдался и перешёл на что-то другое. Но раз ты используешь AWS, S3 — настоящий продукт, — то я довольно удивлён.
Я пробовал искать так: grep -r "Output file is stored on S3" /var/discourse
поскольку эта фраза является последней строкой вывода CLI-резервного копирования, но ничего не найдено.
Есть ли вероятность, что сервер перезагрузится из-за автоматических обновлений операционной системы хоста? Они могут произойти во время загрузки в S3. Есть ли что-то в логах вашей ОС? Попробуйте сбросить параметр сайта backup_time_of_day к значению по умолчанию или установить другое время и посмотрите, исчезнет ли проблема.
Нет, текущее время безотказной работы составляет 36 дней. Я подозревал, что причиной мог быть резервный копирование droplet от DigitalOcean, выполняющееся одновременно, но оно запускается раз в неделю, а мои резервные копии, которые не были удалены, создаются чаще этого.
Я попробую изменить backup_time_of_day. Оно было установлено на 2:00 UTC, так что посмотрим, изменит ли что-то значение по умолчанию — 3:30 UTC.
ОООО! Отличная мысль. Это всё объясняет. Я уверен, что именно так и есть. А полночь — отличное время как для резервного копирования, так и для перезагрузки. Это не совсем объясняет, почему проблема исчезла после перехода на другой сервис, но, возможно, мне просто повезло, или новый сервис оказался быстрее, или что-то в этом роде.
Спустя шестнадцать дней кажется, что это было решением — больше нет несброшенных резервных копий. Я не знаю, что вызывало конфликт, но теперь это уже не имеет значения.
