As far as I can tell, this guide is lots of words around:
- back up
- create a completely new discourse instance, with more words but the same results as just running
discourse_setup 2container - restore
Why wouldn’t you just move or copy /var/discourse/shared/standalone/{postgres,redis}* into /var/discourse/shared/data after a clean shutdown and before starting up two new containers from separate containers/*.yml files? A backup/restore seems like a really heavy-weight way to move all that data across, adding hours unnecessarily to the process. Am I missing something obvious here?
I just tested this process on my test discourse, and split out redis too as long as I was at it, just to make sure I was covering all the bases. Edit: I’ve moved the description to a new topic:
The site seems to be functioning fine without a backup/restore cycle. Is there something non-obvious I should be checking for?
I did the same process for a relatively large discourse and it’s working fine. I decided that in production I would name my new web_only container app so that my fingers will keep normally doing the right thing. After I wrote the new container/*.yml files, the downtime for the entire migration was 12 minutes, far faster than it would have been for a backup/restore cycle.