Hi, I trust that by now you have realised that I did not know your (and all others') replies to my appends to the mailing list existed. That discovery came as an embarrassing and regrettable shock to me this morning. Now, I imagine, everybody on this particular mailing list regards me as a useless old duffer, who doesn't read what people have spent their time to write, or who is just plain rude. The only accurate part of that characterisation is the word 'old'. Anyway, thanks for this explanation, which I follow/understand. I had been somewhat misled by reviews, by others, on the internet, that BIT is indeed an implementation of the incremental back-up model - and their claim is wrong. Indeed the implementation of BIT has advantages over both the incremental and differential backup models, so I am quite enthused about it. I suppose that what I would really like is a backup service that continuously keeps my backup up-to-date, mirroring CRUD (Create, Read, Update, Delete) activity on the source into the backup, on the fly a bit like a RAID 1, couple with a journaling file system. This makes restore the simplest it can be. Up to now I have implemented a crude, manual, equivalent to this process using FreeFileSync. It is quite effective, but a huge consumer of my time and has one fatal flaw: updates to the source are lost if a disaster occurs between an update and the next running of FreeFileSync. BIT is of course subject to the same 'hole' in the resiliency of my overall disaster recovery strategy. I just need to be aware of this.