Understanding how deletes are processed with a multi-mirror Rule

This article discusses how SureSync processes file and folder deletes when a Job is configured with a multi-mirror Rule.

In a multi-mirror Rule file additions, modifications, and deletions that occur on one path will be performed on the other paths defined in the Job.

The first time a new multi-mirror is run, no deletes are performed. A full scan will be performed and any differences in the data set will be resolved. If a file exists on one machine and not on the others, the file will be added to the other paths. If a file is newer on one machine, the file will be synchronized to the other machines. Once processing is complete, all paths will have matching data sets.

At that point, deletions will be enabled. For a delete to occur, a folder scan or a Change Journal event (part of the NTFS file system) must indicate that a file was removed on one of the paths. SureSync will then look at the file history in the SureSync database. The file history tells SureSync the last time the file was synchronized to each path. For a delete to be processed, file history must exist, showing that the file was synchronized on all paths successfully in the past. If the file history is present, the deletion will be processed to the other paths in the Job.

Determining the Source of a Delete Event

To determine the source of a delete event, you will want to consult the Job Log. The Job Log includes a record of every action taken by SureSync. To access the Job Log, right-click on the Schedule or Real-Time Monitor in question and select "Log View for Schedule/Monitor." This will launch the Log Viewer and load the most recent log for the selected Schedule or Real-Time Monitor.

You can search for the specific file by clicking on Filter Details. You will find that there are delete events logged for all but one path. For example, if your Real-time Monitor has 4 paths, you will see deletes for 3 paths. The path not listed in the Job Log is the source of the delete. A user or process on that machine was the source of the delete event.