Move a Discourse site to another VPS with rsync

[pfaffman (Jay Pfaffman)]

@icculus

I just want to reiterate that --numeric-ids is 100% mandatory when rsync’ing to a new server.

I’m not sure that’s true or sure that it always works. At some point, I think, the user and or group IDs inside the docker container changed. I’m willing to give –numberic-ids a try, though.

For the new server migrations I do, I’ve been skipping postgres files like this:

cd /var/discourse
rsync -rav --numeric-ids =old_ip=:/var/discourse/containers/ /var/discourse/containers/
rsync -rav --numeric-ids =old_ip=:/var/discourse/shared/ /var/discourse/shared/ --exclude log --exclude postgres_* --exclude redis_data --exclude log --exclude tmp --exclude state

and restoring a backup to the new machine.

@icculus

I do worry for all the admins out there that think the automatic backup from Discourse will save them in a disaster and are going to be scratching their heads about corrupt SQL indexes,

Yeah. The corrupt index issue can be a real bear. I don’t think I’ve seen one in a good while, though.

@icculus

In theory, SQL indexes are just for speeding up queries, right? So it’s possible that the rsync’d system is just disregarding it and something is suboptimal in some small way that we haven’t noticed. I really don’t know.

Yes, but (I think) they also see that things are unique and the corrupt index will let you have multiple records with what is supposed to be a unique value. It’s for stuff like tracking link clicks, so it’s not especially critical if it’s wrong.

@icculus

Chatter on other threads suggests that some version of Postgres broke things, and a later version fixed it, but I don’t know the specific technical details of what went wrong.

I think I’ve paid closer attention to this than you have and the above pretty much sums up my understanding as well. Maybe the problem was with PG12? That could explain why I haven’t seen the problem in a long while, but I don’t pretend to remember, if I ever knew for sure.