You're kind of missing a better way, even though you keep hinting at it.
NTFS has a change journal specifically for use by backup software. It tracks all the files that have changed sequentially, in a circular log. Thus if you are backup software and you know that you backed up all the changes on this filesystem last time up to change number 1234, then all you need to pick up this time (presuming an incremental backup) is the changes marked higher than number 1234. You don't need to scan the whole tree, even if you haven't been running for weeks, and you don't have to take shortcuts (the way we commonly do with rsync) like looking only at file mod time instead of file contents.
The limitation of a change journal approach is that your change journal has to be large enough to track all the changes between your two backups, or the backup software will have to resort to older approaches. In practice with NTFS it's not uncommon (especially for fileservers with large numbers of small files and a high change rate) to have to increase the change journal from its default size -- however, it's not that big to start with, this doesn't take a lot of space.
If you really have a big file tree and you want to do the same approach with inotify+rsync, just re-invent the NTFS change journal by having a small script listen for inotify events and log them to a circular log, and then feed that to rsync instead of having it walk the trees.