Did a restore and all the internal links have the test URL domain, breaking all the links and I am not sure why it did not take up the correct site URL, without going into the code/db to do a mass find & replace any solutions on how to do this another way?
I was thinking do a Re-Restore?
You’ll need to go into the db and do a mass search/replace.
There is a tool for that:
RAILS_ENV=production discourse remap //old.domain //new.domain
You can fix it as described, but that shouldn’t happen.
Did you make and restore the backup using /admin/backups?
Do both systems have the hostname set correctly?
Thanks. That looked easy enough. I entered the app and I ran that but it seems not to have changed the instances of the URLs in the posts.
This was the remap:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
This ran and competed on the “default” DB it took a few mins and then reported “done” with no error.
I looked at a few choice posts and nothing seemed to have changed on any posts URLs link.
I rebuilt some to test where I saw the dev.domain.com instead of the live domain.com in the links, but they remain the same.
Then I ran the same but sans the https:// and got this error
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
I’m guessing there is a chat message in the DB that’s causing it to stop but not sure why. I suppose I need to somehow see that in the DB, as you can tell no my usual foray in managing discourse is never in the DB.
Finally, I re-ran the original remap, it took a few mins and reported as “done” with no errors:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
Maybe I need to rebake posts to see the fruits?
I thought a post rebuild was the same action on but on a post by post basis.
Or rebuild the app?
That should be
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
The reason for // is that it matches http://, https:// and protocol-less URLs, and it does not match e-mail address domains.
What happens when you do that?
Yea ok, then same error again:
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
So at least I’m using the right write command, things are looking up! 
No further ideas?
Apart from this rails remap impasse I thought maybe if I backup the db and do a restore again it might remap the Link-urls correctly during the restore process?
The error I am still hitting seems to be the repeat or very similar to the stop error here that needed a fix:
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=...
When trying the remap:
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
Maybe @david might have an insight here?
Does this look more like a bug?
That table has links with both of those domains, so when you try to remap them you get a duplicate key. It’s not a bug. You’re trying to create a duplicate key.
You could remove the items from that table that have the apex domain. A better idea is to use www instead of the apex domain.
Thanks. My only concern is this discourse deployment suffers the non-www / SSL issue too, for e.g. How to add ssl to non-www domain? but I will try the remap you suggest and if it works it will force me to solve the non-www issue too! 
The remap rethink worked as suggested by @pfaffman but was actually the catalyst for the solution, not not the solution per se, it helped me figured out what I was doing wrong, it remapped me eyes!
If I had read the error properly i.e. paid attention. I would have solved this a long time ago as I would have seen the key information was in the error message.
All I had to do was included the post number flagged by the stop error …/p/123456789 in the url to navigate directly and fix each post manually.
This occurred for the majority in a second remap run to convert the www from the first remap to the apex non-www url as was the original need.
Now internal URL’s should only include apex links.
This solves some of the www SSL re-direciton where there were many legacy www internal links. It does not solve a user typing in www into the address bar or linkbakc out on teh WWW itself for not but it should tackle all the internally generated ones. Waiting to see how it affects google indexing before doing anything more on this issue.
Perhaps of interest. To devs.
I found a lot of stops on duplicate key value violates unique constraint “unique_post_links”, these occurred when a post was moved and discourse included the “Continued from …. “ with hotlink, but if the split posts included quoted blocks to the same spot then it woudl stop the remap.
This caused the majority of stops errors.
The solution was remove one of the duplicate internal linkbacks or code bracket (did not always work) them and the remap would move on once re-run.
Other stops were caused by users creating the same on post conditions manually by re-posting the same link back to a post not realising the Quote also linked back, perhaps historical habits, styles etc come into play here indicating many users still do not realise how much discourse handles links to make life easier, oh the irony!
After the remap I could have reverted the edits but it was not that many to make a difference and there was still one correct link back to the internal discourse source of the post or quite.
Hopefully this reverses the bulk of google de-indexing 10’s of 1000’s of pages into un-indexed grey limbo.
A little knowledge is a dangerous thing! 