Приостановить оптимизацию изображений при восстановлении на новом экземпляре сервера

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

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

Так я смогу проверить, прошло ли восстановление успешно, и удалить файл резервной копии.

Мой файл резервной копии занимает около 200 ГБ, при этом в настройках не отмечена опция «Включать сгенерированные миниатюры в резервные копии». Отключение этой опции уменьшит размер резервных копий, но потребует повторной обработки всех сообщений после восстановления.

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

Если вам нужно больше места, значит, вам нужно больше места.

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

Спасибо за попытку помочь.

Я попробовал, но теперь я вполне уверен, почему восстановление прошло неудачно.

Моя главная проблема в том, что мой старый экземпляр застрял на версии PostgreSQL 12, и я не нашел способа его обновить, чтобы перейти на новый чистый экземпляр.

Вы знаете, возможно ли восстановить только базу данных на чистой установке?

Когда я пробовал, экземпляр просто начинал возвращать код ошибки 500, и мне приходилось начинать всё сначала.

Я бы поступил так: последовал бы инструкции Перенос сайта Discourse на другой VPS с помощью rsync, но не копировал бы файлы PostgreSQL.

Затем сделал бы резервную копию только базы данных и восстановил её. Резервную копию также нужно передать через rsync и восстановить из командной строки.

Это, я так понимаю, очень старая версия? Выглядит ли восстановление завершенным успешно?

Спасибо за помощь.

Да, но для простого восстановления через веб-интерфейс и по стандартной процедуре вам потребуется свободное место, превышающее размер файла резервной копии в 4 раза.

Вот как это происходит:

  1. Загрузите файл резервной копии (или выполните rsync в /var/discourse/shared/standalone/backups/default)
  2. После инициализации восстановления файл backup file.gz копируется в /var/discourse/shared/standalone/tmp/restores/
  3. В процессе восстановления файл резервной копии в папке /var/discourse/shared/standalone/tmp/restores/ распаковывается
  4. Из временной папки файлы загружаются через rsync в постоянное место, а дамп SQL импортируется в базу данных PostgreSQL.

Как мне удалось успешно восстановить систему.

В процессе восстановления, когда Discourse скопировал файл из папки восстановления во временную, я удалил исходный файл резервной копии, загруженный по SSH.

Ещё раз, когда Discourse завершил вставку данных из SQL и начал rsync распакованных файлов из временной папки в /var/discourse/shared/standalone/uploads/, я вручную удалил файл bakupxxx.tar.gz во временной папке через SSH, не прерывая процесс восстановления.

Как только мой экземпляр стал доступен и rsync завершился, я выполнил:

rm -rf /var/discourse/shared/standalone/tmp/restores/default/*

Если вы делаете резервную копию большого размера, процесс восстановления может показаться зависшим, и экземпляр через веб-интерфейс начинает возвращать ошибку 500 (со мной такое случалось дважды). В таком случае вы можете проверить процесс восстановления, войдя в приложение:

cd /var/discourse
./launcher enter app

ps aux | grep restore


Также, поскольку восстановление моей базы данных заняло много времени, мне помогло следующее:

cd /var/discourse
./launcher enter app
watch -n 10 "sudo -u postgres psql discourse -c \"SELECT now(), state, query FROM pg_stat_activity WHERE state != 'idle';\""

Это позволило мне отслеживать прогресс восстановления базы данных и убедиться, что процесс ещё работает.

Отличное решение! Если кто-то ещё это найдёт, я думаю, что восстановление только базы данных сработало бы и было бы немного проще, но рад, что вы всё решили!