(Note : I made a correction regarding using dxdisp in my comments earlier. In an offline dump, we need not run dxdisp, because of the process).
One things which is a definite "YES", is that when we are syncing manually we should have zero downtime for end users / clients connecting to CA Directory. Therefore we should have the core services still up and running. In the example I provided above DSA1 is still running, hence will be available for business continuity whilst we work on DSA2 and DSA3. Hence architecturally how CA Directory is built / setup within Geo's / across Geo's, play a key role. Also how client definitions are defined. Example : In Policy Server, what is defined? Is DSA1 defined as primary PStore OR is there a RouterDSA defined. If DSA1 is defined as primary then unless DSA1 goes down, all updates / reads are performed against DSA1. Thus in a way DSA1 is what is going to replicate to DSA2/3, because most of the time PS is running against DSA1 which is primary. Thus there won't be any muti-write queues in DSA2/3 contains data to be written. But in DSA1 there'd be MultiWrite Queues.
The second thing we need to take care is the amount of update that occurs. We can easily stack it up. Policy Store updates are minimal, because updates are via WAMUI or XPSTools & reads are from only Policy Servers. Session Store updates are with every authentication and validation, hence the frequency of updates are 3x or 5x times when it is Session Store. User Store updates and reads are 10x times because it is not only SiteMinder which uses a User Store but there are other capabilities too trying to connect and consume user information. Thus consider the time we take a backup (either using offline i.e. .db or online method i.e. .zdb) from DSA1, transfer the .db (or.zdb) to DSA2 / 3 and update DSA 2 / 3. The longer the time gap, the longer the number of updates / replication queue grows from DSA1 (after the backup was taken from DSA1 and DSA2/3 get running post manual sync).
The third thing, should we take an offline dump i.e. copy the .db file OR should we take an online dump i.e. copy .zdb. Here is a comparison.
Here is an approach to build the mindset.
https://docops.ca.com/ca-directory/12-6/en/administrating/set-up-replication/multiwrite-groups-hubs/sample-topology-and-disaster-recovery (Keep MW-Groups in the doc link aside for a moment; but it conceptually gives us a birds eye view of how we can manually sync. Refer the Steps under "Multiwrite Group Peer Recovery" for taking an online dump and syncing another DSA).
We definitely need not rebuild schema, if that is the case, then there is something way wrong in the dsa (where the schema was rebuilt), than just being out of sync.