OK, here's something I don't understand. As I mentioned in another message, I did a complete restore of my server yesterday. My next backup was this morning. I was surprised to notice that QRecall clamed to have captured *everything* this time, even though the vast majority of the files had not changed since the previous restore.

To explain further, here's the size and the item count for the backup layers in this archive:

1. 4.25 GB -- 96,437 items (Initial backup)
2. 189.7 MB -- 2,921 items
3. 83.5 MB -- 964 items
4. 71.8 MB -- 624 items
5. 818.3 MB -- 4,981 items (last backup before restore)
(full restore occurred here)
6. 4.37 GB -- 97,308 items (first backup after restore)
7. 258.6 MB -- 1,958 items

Layer number 6 is the one that surprised me. I did notice, however, that the monitor window said "99% duplicate" as it ran.

I just checked the size of the archive file, and it's 4.24 GB. So I'm relieved to see that whatever QRecall did, it didn't actually capture every item in its entirety, or the archive size would have been about 8.5 GB.

By the way, my archive settings were shifted quanta to the max (far right on the slider) and all compression off (far left on the sliders).

QRecall is very conservative in the criteria is uses to determine when a file or directory might have changed and needs to be recaptured. In this case, all of the files on the volume are new (since they were all rewritten when you restored the volume). It's only logical that QRecall would see them as new files and capture them again.

Since all of the files contained the same data as the previously captured items, no new data was added to the archive ? thus, the 99% duplicate message.

As for the exact mechanics involved, the likely suspect is the attributeModDate property of each file. This property is changed whenever any file metadata is set or changed. Recalling a file sets the metadata of that file to its recalled state, which subsequently changes its attributeModDate. The next time the file is captured, the file's new attributeModDate doesn't match the attributeModDate of the previously captured item, so QRecall recaptures it.