Replicas are copies of a Primary database running on another AM server or instance, a specific server, so the only way replicas remain when you restore from backup is when you restore that backup to the original primary from where the replicas were deployed or created from. Original AM 8.x spec was to only allow a database backup restore into the same Primary that it came from, but our customers complained that they could not get copies of their Prod DB into a Dev site. So now you can, but you have to deploy replicas after the DB restore.
This would affect TCP based agent too.
Actually since what you did is a Backup and a restore on a different server, the IP addresses are probably different so if this is true the replicas do not have a relation to the instance You just recovered. At this point what you have to do is just try to sync the two replicas, if that is an issue, well no problem if you do not have replicas registred in your new primary instance, create them, and review the system health of each replica so that they are healthy.
Now I have a curiosity, Why would you backup a primary 8.2 instance and recover it on another 8.2? What were you trying to do? I ask this so i can understand what you need.
An AM Server is identified by its SSL Cert, which includes IP and Name, but also has private and public key, so you cannot just assume the identity of an AM server. Problem shows itself more clearly when you look at connections to the AM Primary, replicas as you noted, but this also would affect trusted realm connections to other AM primaries, and the new TCP 5500 agents.
So in short, when you restore an AM 8.x backup, you get the replicas that were in that 'from' primary, and lose any replicas you had configured on the 'to' primary. You are overwriting the existing database.
Retrieving data ...