Trying to figure how AB actually works - file backup - incremental

Incremental backup for files compares changes by blocks too - if some bytes inside a file are changed but the remainder is not 'shifted' , only changed regions will be put to the incremental backup. The file may be physically moved to other sectors of the disk - it doesn't matter.

Thank you!

Well, I'm a little confused again. Turns out my file backup (I forgot to mention) is a .LNK / mount point. When looking into the archive, I can see where about 7gb/day went in to each incremental - so despite the small size incrementals I showed above, it at least recorded and amount that matches what I'd expect to be altered each day. Still not sure how it puts 7gb of data in a 30mb file though. Perhaps the 30mb file is just an index into the 10Gb 'full' backup file???

I decided to try a full restore to an alternate location - this time Recover without full path UNchecked. All it did in a few seconds was to create the same mount point structure in a different location, no data was restored. The only way I can pull a file from this backup into a different location is to make sure Recover without full path CHECKED. Then I end up with two separate files and not two pointers to the same file.

I'm glad I noticed this and didn't just delete the "restored" files, otherwise all of my files in that mount point would have been lost.

From reading the help, I don't think the Mount Points option applies here because my "file" backup job includes the mount points base folder and everything beneath it.

Any ideas how to restore this backup to the original folder structure on a "different" drive?

'Mount points' options controls only mount points to volumes. Junctions are always stored as junctions and its folder structure is not traversed. If the original file is not backed up, warning is logged. .LNK (Windows shortcut) is just a regular file and is backed up as such. I'm not sure what is expected behavior in case when you try to recover the junction from the archive where both junction and the target file are stored. I suggest to contact Acronis support if find the current behavior incorrect.

Well, the .LNK was probably not the correct nomenclature to use. The folder "type" as displayed in the explorer properties dialog is a Mounted Volume. It's a folder/path that is a mount point to a PGP volume. Rather than restoring the data to a separate location, ABR is just re-creating another Mounted Volume in the alternate location I specified. So no data is actually restored.

The restore fails right away if the PGP volume is not mounted. So in a case where I'm on another machine I suspect the data would not be recoverable unless I elect to restore all files to a single path. Unchecking that to have the original folder structure created would just fail.

Other not so sophisticated backup programs just see the folder as a folder, backs up the files in it, and can restore them all to any location.

What happens if you select data (to recover) immediately under the mount point (instead of mount point itself)?

The mount point is C:\Users\User name\Documents\data.

I chose a single file named foo in the root folder named data and restored it to an alternate path on an external drive, F:\data.

ABR recreated a new mount point at f:\Data\Drive(C)\Users\User name\Documents\data. No files were restored. The new mount point points to the same thing that C:\Users\User name\Documents\data points to.

The only safe way to get rid of this newly created mount point is to unmount my PGP volume then delete the folder. Otherwise I would be actually deleting the entire contents of the PGP volume.

If I leave "Recover without full path" CHECKED, then foo is restored to F:\data.

I guess ABR is technically restoring ALL the attributes of the original path when Recover without full path is UNchecked, causing a new Mount Point to be created instead of actually restoring the data.