Насколько я понимаю, эта инструкция содержит много словесных оборотов вокруг:
- резервного копирования
- создания совершенно нового экземпляра Discourse с большим количеством слов, но теми же результатами, что и просто запуск
discourse_setup 2container - восстановления
Поч бы не просто переместить или скопировать /var/discourse/shared/standalone/{postgres,redis}* в /var/discourse/shared/data после корректного завершения работы и перед запуском двух новых контейнеров из отдельных файлов containers/*.yml? Резервное копирование и восстановление кажутся чрезмерно громоздким способом переноса всех этих данных, необоснованно увеличивая процесс на несколько часов. Не упускаю ли я что-то очевидное?
Я только что протестировал этот процесс на своём тестовом экземпляре Discourse и, раз уж зашёл так далеко, также разделил Redis, чтобы убедиться, что учтены все аспекты. Редакция: Я перенёс описание в новую тему:
Сайт, похоже, функционирует нормально без цикла резервного копирования и восстановления. Есть ли что-то неочевидное, что мне следует проверить?
Я провёл тот же процесс для относительно крупного экземпляра Discourse, и он работает исправно. Я решил, что в продакшн-среде назову свой новый контейнер web_only как app, чтобы мои пальцы автоматически выполняли нужные действия. После написания новых файлов container/*.yml время простоя при всей миграции составило 12 минут — значительно быстрее, чем при цикле резервного копирования и восстановления.