Read below to learn how sync works.
Below is a basic overview of how sync functions.
When sync begins, it looks through tracking tables in the local database and compares the date modified to the receiving database's tracking tables. Then, the Ektron Window Service begins to batch the database in parts to prepare it to move over.
When files are moved over, such as Assets, PrivateAssets, UploadedFiles, UploadedImages, and AssetLibrary, the sync process uses encrypted knowledge files to compare the sending and receiving servers of files that have been updated or moved over previously. Then, it'll move the files over.
At the end of the process, sync checks sync certificates to make sure they are valid.
A more detailed explanation
When sync begins, it uses the Ektron Window Service over the port 8732 to look through the tracking tables within the local database and compares to the receiving database's tracking tables. The purpose of tracking tables is as you might expect, to track actions taken on content for the purposes of eSync. This information in the tracking tables allows eSync to make decisions about whether to move, delete, or update content to on the receiving end of a sync.
You can see when a row was last changed by the last_changed_datetime field. This is helpful when you want to see when a row was changed in comparison to the corresponding row of the database you are syncing to. This can show which side the content was edited on most recently which can explain why a particular row isn't syncing as expected.
Another helpful field in the tracking tables is the sync_row_is_tombstone. This tells you if content had been deleted at one point. If you see sync_row_is_tombstone set to 1 that indicates the content was deleted and cannot be recreated which explains why you cannot use sync as a restore method.
Then, the Ektron Window Service and database stored procedures begin to batch the database in parts to prepare it to move over. The batch size depends on the listing in the Sync Settings within the workarea/database. Ektron Support does not recommend changing the batch size without consulting Support.
The tracking knowledge first begins when sync is used for the first time between two databases; specifically when the sync relationship is first created. The knowledge grows over time and must match properly between the two databases. If one restores the database to a prior version, the other database must be restored as well or the knowledge will no longer match.
The tracking knowledge is fragile and has a history. Because of this it is best to start sync knowledge with a strong foundation by syncing to a min database or using backup and restore synchronization steps(see documentation). Creating a new relationship between two previously populated databases often causes knowledge issues in the future.
When files are moved over, such as Assets, PrivateAssets, UploadedFiles, UploadedImages, and AssetLibrary, the Ektron Window Service and Microsoft Sync File Watcher look to the encrypted knowledge files to compare the sending and receiving servers of files that have been updated or moved over previously. Then, those processes move the files over using the 8732 port and Ektron Window Service to communicate as the files are being transferred. Those files are placed as temp files in the temp file directory on the receiving server, then shuffled into where they should be placed as the process continues.
At the end of the process, sync checks the sync certificates to make sure that they are valid.