Large increment backups - why?

Using True Image Home v11.0 (build 8,053) I performed a full image backup (not sector based) of the computer to an external harddrive. Ths backup was 66Gbytes. I also run a nightly incremental backup, which is averaging at approx 1.2Gbytes per backup.

The machine (running Windows XP SP2) has a fairly low usage and I do not use an automated disk defragmentation program.

Can someone explain why these incrementals are so high please.

Is there any logging that can be enabled to see which files are being backed up?

Thanks,
Andrew

 

Can anyone help here please?

Can I even generate a detailed log of what has been backed up?

Andrew

 

If the images are .tib files you can use Mount Image or Explore Backup Archive to see what has been included.

 

I do not believe there is any way to tell what files were included in a DIFF or INC image.
The PC I’m at now creates a 10 GB FULL image file with the INC running between 300 to 700 MB in size, with the majority in the 300-400 range.
Windows can do all sorts of things in the background that can affect the file/sector structure. Restore Points for one, and this taken from http://www.extremetech.com/article2/0,1697,1148808,00.asp
"Windows XP Boot Loading Optimizations
Beyond support for the Simple Boot Flag, new techniques in Windows XP to optimize the boot process push beyond previous versions of Windows. The Windows XP boot loader has been rewritten to incorporate parallel pre-fetching of drivers, boot code, and Registry items. It also loads larger chunks of memory and rearranging files on disk for more efficient file access."

 

Let's call the base image x.tib and the differential X2.tib.

1. Mount each volume in the X.tib archive, and save a list of the files on each volume to a single file, call this x.txt.

2. Dismount all the mounted volumes., then mount each volume in the X2.tib archive, and sabe the lists in x2.txt.

3. Use your favorite file comparison tool to compare X2.txt wit X.txt.

A similar procedure can be used with incremental updates.

 

OK, I do not believe there is any way WITHIN TI to tell what files were included in a DIFF or INC image.
I'm sure there are many convoluted other ways to do so.

 

While that might show any NEW files, how will this indicate CHANGED files?

 

When comparing the two list, deleted files will be missing from the 2nd list, new files will have been added to the second list, and the filesize/timestamps will have changed for changed files.

 

Your incremental files are not really all that large compared to the data on the disk. Windows handles a lot of files in the simple process of booting and running a bit, and then closing down. It makes restore points, and keeps data on your usage to optimize the disk during defrag. In many programs if you open it, look at the data (eg Money, etc) and close it without doing anything at all, it will create a few megs of data that will be seen as changed by Acronis, because it was rewritten.

You could probably use the time you are spending on this better other ways. There is little liklihood you can reduce them dramatically. Good luck.

 

I took the earlier advise of the file list compare, and found that the list of changed (or new) files summed to approx 500Mbytes (quite a bit was Outlook Express DBX files). I suppose there is always going to be an overhead in the archive, so perhaps an extra 400-500M is to be expected.

Thanks all for your comments.
Andrew

 

Out of curiosity, just how many files were in a 66 GB backup? Must have taken a long time to do the file compare.

 

Mea culpa, mea culpa!

I had an off day.

When I suggested that the file compare be done, I forgot to mention the easiest way to do this.

See GetFileTypeDistribution

and CompareDrives

 

I actually mounted 2 consecutive incremental backups, and ran 'dir /a /s' on each, then compared the results using winmerge. I then extracted the list of changes, and used Excel to sum them (after removing some 'junk' lines with 'find' first). Yes, it was rather tedious.

 

Using CompareDrives is easier and more accurate.