Спасибо за помощь.
Да, но для простого восстановления через веб-интерфейс и по стандартной процедуре вам потребуется свободное место, превышающее размер файла резервной копии в 4 раза.
Вот как это происходит:
- Загрузите файл резервной копии (или выполните rsync в
/var/discourse/shared/standalone/backups/default)
- После инициализации восстановления файл backup file.gz копируется в
/var/discourse/shared/standalone/tmp/restores/
- В процессе восстановления файл резервной копии в папке
/var/discourse/shared/standalone/tmp/restores/ распаковывается
- Из временной папки файлы загружаются через 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';\""
Это позволило мне отслеживать прогресс восстановления базы данных и убедиться, что процесс ещё работает.