in reply to Incremental Backup

IMO, the short answer is - you don't want to do it like that.

Incremental backup means that only files which are new or modified since the previous backup will be included in the backup.

Incremental backup needs reference full backups in case a full system restore is needed. These are usually weekly to avoid too many increments to restore and some kind of historical archiving is a good idea.

Backup should take place when the system is disabled from users to avoid the kind of synchronisation issues you are talking about.

If the system has to be up all the time, the best trick is to use shadow-recorded volumes which can be taken out of normal use so that backup can occur in single user mode on a per-volume basis and still occur in parallel with multi-user operability. When backed up, the shadow volume can be brought back into service as a shadow of the new state of its master volume. The idea of a directory containing files is itself not the right format for this type of backup - a tar file, which can be zipped and archived off, is more like it.

As far as I can see, there is no reliable alternative that involves folder synchronisation in the way you describe it, because any files modified on the volume being backed up will acquire an unknown backup status (you lose whether they were backed up before or after creation/modification) - a post-hoc synchronisation run only adds an extra quickie layer of the same problem and removes you even further from where you want to be. Morevoer, the delete you are talking about, can more safely be just left as it is, if you are doing the backup according to the definition above, because the file won't appear in the next increment nor in the next full backup.

One world, one people