securityjm,  There is another thread with some more information around how the "when-source-modified" functions which may help answer some questions around that. Along with some things to think about with RPO and RTO. Re: what is minimum Isilon's minimum RTO, and can snapshot be supported? Which also has a link to the white paper: [URL]  Being in support and working with snapshots, on a continuous bases, I have seen large backups of pending snapshots deletes due to "when-source-modified" (400k+ pending deletes) This is incredibly dependent on the type of work flow. As Burhan Halilov said, if this is done on a very busy directory, say home directories for thousands of users, the cluster may have a hard time (pending hardware configuration) keeping up with the 100k+ snapshots (files being modified) a day. So something to keep in mind is the type of work flow in the directory that when-source-modified is going to be utilized on. Being mindful of the amount of changes on files within the directory.
Does anyone have any advice on using the schedule "when-source-modified" for SyncIQ. On one hand it seems that this schedule setting would serve to replicate data as soon as it is changed, (Assuming that most of the writes are not overwrites) The total amount of change data replicated would be similar to using a set schedule. In this manner it would act similar to recoverpoint as a continuous asynchronous replication. Does this setting have any sort of underlying implications that I am missing?  Does anyone have any real world experience with this setting? I can’t seem to locate anything specifically mentioned about this and when it should/shouldn’t’ be used. I would imagine that this setting would be a no brainer for archive storage, but my question is more focused around its use as general array replication setting. 
SyncIQ & when-source-modified