У меня есть сайт, который отправляет резервную копию объёмом 20 ГБ в Wasabi S3. Это работает. В большинстве случаев.
Но иногда загрузка в S3 не удаётся, и локальный файл .tar.gz остаётся на месте. В итоге диск заполняется, и у меня остаётся полный диск, несжатый файл .tar (так как места не хватило даже для сжатой версии), а вскоре сайт ломается из-за нехватки места на диске.
Прежде чем отказаться от Wasabi, я хочу попробовать найти какие-либо подсказки.
Я проверил production.log, production.errors и логи sidekiq и unicorn, но нигде не нашёл упоминаний “acku” ни в день сбоя резервного копирования, ни в день успешного выполнения. Не должно ли где-то быть логирование?
Если возникнет ошибка, вам должно прийти личное сообщение с выводом лога. Оно отправляется напрямую вам, если резервное копирование выполняется вручную через интерфейс, или группе администраторов, если это автоматическое резервное копирование.
Исключение во время резервного копирования также должно отображаться в /logs и, как я полагаю, в одном из файлов логов. Попробуйте поискать EXCEPTION:.
Однако тот факт, что временные файлы не удаляются, заставляет задуматься, не происходит ли перезапуск Sidekiq, Docker или даже хоста во время резервного копирования. Это могло бы объяснить, почему очистка не выполняется и почему вы не получаете личное сообщение.
Правильно. Это очень странно. Я не получил уведомления об ошибке, даже для случая, когда был только файл .tar и диск был почти заполнен (это актуальный сайт на tests-passed).
Как будто в те дни просто изменилось backup location, но в логах ничего нет. В сообщениях администратора я вижу уведомления об «успешном» выполнении резервного копирования, инициированного через веб-интерфейс, но нет уведомлений об ошибках. Я перенёс backup_location в переменную окружения.