OK, I found the email from one of our developers. Since color is key, I switched to HTML. This is supposed to illustrate how shadow copies work--I hope it makes sense. As you can see, this is not in any way related to traditional incremental/differential/full backups. By using this technology known as VSS (volume shadow copy service), Complete PC Backup can minimize the size of the incremental backups. Since there is a finite amount of space on the disk, you can't keep infinite # of Complete PC incrementals. Eventually the oldest will be purged to make room for newer ones.
Also, I don't think that Complete PC Backup is keying off the registry to decide what to do. I will double-check this though.
(3) The shadow copy storage area does not contain whole copies, and the snapshots don't work at file level. The snapshots don't even have way to know about files. They are below the file system. The only case when something is copied to the shadow copy storage area (sometimes called diff area) is when it was used (not free space) at the time the snapshot was created, now is changed, and it was not copied already to the storage area for this or another snapshot. This is done at 16k units granularity, so if you change something small in your .pst, you will end up with 16k-32k diff generated.
Let me give an example.
Let's say the live volume is like this:
Live volume: |a|a|b|b| | |
Then we create snapshot
Live volume: |a|a|b|b| | |
Snapshot1 : |_|_|_|_| []**
Using the brackets next to ** I am trying to represent that the snapshot does not contain the free space, and the reads go directly to the data on the original volume (this is represented with underscores). The diff area is empty.
Now let's change the 1st a to be a (a lot of programs overwrite with the same data).
a
|
Live volume: |a|a|b|b| | |
Snapshot1 : |_|_|_|_| []
As a result nothing changes.
Now let's change the 2nd a to c.
c
|
Live volume: |a|c|b|b| | |
Snapshot1 : |_|a|_|_| [a]
The live volume will contain the c, the snapshot will a, the diff are will contain a.
Now let's write d in the 1st free space
d
|
Live volume: |a|c|b|b|d| |
Snapshot1 : |_|a|_|_| [a]
Nothing changes on the snapshot and nothing is added to the diff area. This is VERY important moment. Free space is not copied. Downloading new mp3 in free space has no additional cost.
Now let's create one more snapshot
Live volume: |a|c|b|b|d| |
Snapshot1 : |_|a|_|_| [a]
Snapshot2 : |_|_|_|_|_| []
Again everything read from the 2nd snapshot goes to the live volume. The newly added data d is protected in the 2nd snapshot, but not in the 1st.
Now let's change the 1st b to e
e
|
Live volume: |a|c|e|b|d| |
Snapshot1 : |_|a|b|_| [a]
Snapshot2 : |_|_|b|_|_|
It appears in both snapshots as expected as b, but it is copied ONLY once in the most recent diff area.
Now let's change the e to f
f
|
Live volume: |a|c|f|b|d| |
Snapshot1 : |_|a|b|_| [a]
Snapshot2 : |_|_|b|_|_|
Nothing changes in the snapshots nor anything is added to the diff area, because the block is already there.
So if you count, we did 5 writes to the volume, but we copied only 2 blocks and we still have 2 snapshots of the volume.
Shadow copies are made at the block level, not file level. Somewhere