Резервные копии постоянно выводят форум из строя

[piffy]

Я постоянно сталкиваюсь с циклами, когда создание резервной копии выводит мой сайт из строя из-за нехватки места.

Я настроил систему так, что для хранения резервных копий и загруженных файлов использую отдельный том DO. Объем тома составляет 300 ГБ.

Мои настройки резервного копирования:

Проблема повторяется уже несколько месяцев. Я получаю сообщения о сбоях резервного копирования во входящих администратора (см. ниже).

Нет места на устройстве

[2024-02-14 03:43:34] Завершение создания резервной копии...
[2024-02-14 03:43:34] Создание архива: elite-fourum-2024-02-14-033845-v20240204204532.tar.gz
[2024-02-14 03:43:34] Проверка существования архива...
[2024-02-14 03:43:34] Создание пустого архива...
[2024-02-14 03:43:34] Архивирование дампа данных...
[2024-02-14 03:43:58] Архивирование загруженных файлов...
[2024-02-14 03:55:03] Удаление временной директории '/var/www/discourse/tmp/backups/default/2024-02-14-033845'...
[2024-02-14 03:55:03] Сжатие архива в gzip, это может занять время...
[2024-02-14 04:25:38] ИСКЛЮЧЕНИЕ: /var/www/discourse/lib/discourse.rb:138:in `exec': Не удалось сжать архив в gzip.

gzip: /var/www/discourse/public/backups/default/elite-fourum-2024-02-14-033845-v20240204204532.tar.gz: Нет места на устройстве

[2024-02-14 04:25:38] /var/www/discourse/lib/discourse.rb:172:in `execute_command'
/var/www/discourse/lib/discourse.rb:138:in `exec'
/var/www/discourse/lib/discourse.rb:34:in `execute_command'
/var/www/discourse/lib/backup_restore/backuper.rb:253:in `create_archive'
/var/www/discourse/lib/backup_restore/backuper.rb:40:in `run'
/var/www/discourse/lib/backup_restore.rb:13:in `backup!'
/var/www/discourse/app/jobs/regular/create_backup.rb:10:in `execute'
/var/www/discourse/app/jobs/base.rb:297:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-5.0.0/lib/rails_multisite/connection_management.rb:82:in `with_connection'
/var/www/discourse/app/jobs/base.rb:284:in `block in perform'
/var/www/discourse/app/jobs/base.rb:280:in `each'
/var/www/discourse/app/jobs/base.rb:280:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:132:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq.rb:44:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'
[2024-02-14 04:25:38] Удаление старых резервных копий...
[2024-02-14 04:25:38] Очистка временных файлов...
[2024-02-14 04:25:38] Удаление остатков '.tar'...
[2024-02-14 04:25:39] Пометка резервной копии как завершенной...
[2024-02-14 04:25:39] Уведомление 'system' о завершении резервного копирования...

Однако затем происходит следующее: у меня накапливается серия частично (?) завершенных резервных копий, о которых, насколько я знаю, мне не приходит уведомлений. Они накапливаются до тех пор, пока система не попытается создать новую резервную копию каждый день, и в этот момент мой сайт снова падает.

Мне приходится вручную подключаться по SSH и удалять их, так как они не отображаются на странице /admin/backups.

Я понимаю, что воспроизвести эту проблему сложно, а значит, и исправить её непросто, но хотел бы узнать, не совершаю ли я очевидную ошибку или сталкиваются ли с этой проблемой другие пользователи?

[Ed_S]

Первое, что стоит попробовать после удаления файлов, которые не являются сжатыми резервными копиями, — уменьшить максимальное количество резервных копий до двух.

В любом случае, я считаю, что лучше иметь способ переноса этих резервных копий в другое место, например, на ваш домашний компьютер. Если у вас возникнут проблемы с хостинг-провайдером и он удалит ваш аккаунт, вы останетесь ни с чем. Аналогично, если ваш аккаунт будет скомпрометирован, или, например, если у провайдера случится пожар.

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

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

Также вы можете разместить свои резервные копии в блочном хранилище, причём у другого провайдера. В этом случае вероятность потери как вашей установки, так и резервных копий будет значительно ниже.

Полагаю, есть давно назревшая работа, которая позволила бы обойтись без хранения одновременно и резервной копии, и временно сжатого файла резервной копии, но ждать этого не стоит. Тем временем вам нужно место для N хранимых резервных копий, плюс 1 для создаваемой в несжатом виде копии, плюс 1 для сжатой копии, которая нужна кратко до удаления самой старой из N копий.

Вам требуется дисковое пространство для N+2 резервных копий, и если резервное копирование завершится ошибкой, вам нужно будет удалить лишние фрагменты.

[pfaffman (Jay Pfaffman)]

@piffy

/var/www/discourse/tmp/

Вам нужно убедиться, что вы также разместили эту директорию на вашем разделе в 300 ГБ. Именно он заполняет диск.

Также можно рассмотреть возможность переноса загрузок на этот раздел.

[piffy]

Вы сразу знаете, как это сделать? Есть ли настройка в YAML или что-то, что мне нужно изменить?

У меня также настроен статический экран офлайн-режима при пересборке, поэтому не знаю, усложняет ли это ситуацию.

[pfaffman (Jay Pfaffman)]

Что-то вроде

volumes:
  - volume:
      host: /your/big/partition/tmp
      guest: /var/www/discourse/tmp

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

@piffy

У меня также настроен статический экран офлайн-режима при пересборке, так что не знаю, усложняет ли это дело.

Это усложняет. Скорее всего, это не проблема, если только проблема не в том, что статическая страница офлайн-режима продолжает отображаться, даже когда Discourse уже запущен.

[piffy]

Я узнал об этом уже после создания этой темы: при расширении тома DigitalOcean необходимо выполнить команду в консоли. Таким образом, я фактически не использовал все свои 300 ГБ.

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

В следующий раз я попробую стратегию, обсуждавшуюся выше.

Но я хотел сказать вот что: было бы здорово иметь индикатор в административном интерфейсе, сообщающий о неудачных резервных копиях. Или, возможно, удалять любые файлы *.tar при запуске нового процесса резервного копирования? В моём случае было 90 ГБ распакованных резервных копий, которые невозможно было увидеть в административном интерфейсе. Также не пришло ни одного сообщения «резервное копирование не удалось» ни от кого.

[gerhard (Gerhard Schlager)]

Как обстоят дела с использованием памяти на вашем дроплете? Процесс резервного копирования должен запускать процедуры очистки и отправлять уведомление администраторам в случае сбоя. Однако этого не произойдет, если процесс будет завершен убийцей процессов из-за нехватки памяти (OOM killer).

[pfaffman (Jay Pfaffman)]

@Герхард Шлагер

Это не произойдет, если процесс будет завершен убийцей из-за нехватки памяти (OOM killer).

Возможно, именно это и происходит! Я сталкивался с такой ситуацией, когда «прерванные резервные копии оставляют частичные файлы, заполняющие диск», на нескольких сайтах. Лучшим объяснением мне казалось перезагрузка ОС в середине процесса резервного копирования, но я видел это и без перезагрузок ОС.

Прерывание процесса резервного копирования из-за нехватки памяти кажется правдоподобным объяснением, которое достаточно сложно воспроизвести, чтобы объяснить эту проблему.

. . . .

Ох, черт. Один сайт, на котором я помню эту проблему, имеет 16 ГБ оперативной памяти, так что это, вероятно, не объясняет ситуацию. На этом сайте проблема в том, что раз в неделю или около того резервная копия остается на локальном диске после того, как она (или, возможно, не) была выгружена в S3. У них также более 100 ГБ свободного места на диске, поэтому проблема накапливается месяцами, прежде чем диск заполнится настолько, что это станет большой проблемой.

Вот набор файлов, которые я только что удалил:

forum-2024-03-11-123904-v20240202052058.tar.gz
forum-2024-03-09-123159-v20240202052058.tar.gz                           
forum-2024-03-07-123727-v20240202052058.tar.gz                           
forum-2024-03-05-123019-v20240202052058.tar.gz
forum-2024-03-03-123934-v20240202052058.tar.gz  

[Firepup650 (Firepup Sixfifty)]

+1 к этому. Форум, который я помогаю администрировать, случайно оставляет резервные копии на сервере вместо их выгрузки в S3, что уже приводило к падению форума как минимум один раз.

[piffy]

Не уверен, поможет ли это, но вот метрики от DO:

7 дней

24 часа

Увеличить