True Image, archive bits and incremental backups

I have True Image 8.0.937 and am looking for some answers I have not seen
addressed. When I create an image (full) of the drive, my understanding is
it is a sector by sector of the used portion of the drive. I suspect this does
NOT clear any archive bits on any files. Incremental/Differential backups if
I understand correctly pick up any modified sectors since the original main
backup. Therefore, if I defrag the disk, any incremental/differential backup
would be big since things have moved around (even though the files have
not changed themselves). Is this correct ?? Am I missing something ??

What I would like to do is an image of the drive, clear all the archive bits
then be able to only pick up files that have changed (with NTBackup etc)
for my incremental backups. I don't want defrag to "flag" all sorts of stuff
that it has been changed when in reality it only moved. Anyone familiar
with a utility to clear all the archive bits after doing an image so that only
changed files are now found with utilities like NTBackup etc ??

Win XP Pro
Thanks
mikey (who is NOT ready for ATI ver 9 yet based on the comments !)

 

"Is this correct ?? Am I missing something ??"
From what I know - Yes , No

As for the archive bit - don't most file backup apps that allow for incremental/differential backups clear the bit after a Full B/U? Or you can always use the ATTRIB command to clear the bit, but that could take awhile.

ADDED - If you image the drive, clear the bits, move and modify a file, then do an incremental based on the bit ... the image restore would put the unchanged file back where it started and then the file restore would put another copy in the new location.

 

Mikey: After doing some more googling around, I found an interesting article
on why NOT to rely on the "Archive Bit" for backups. Often users may have
their own utility of some sort to save copies of their files - and these can
reset the archive bit (or they may do it just so the files don't get backed
up for some reason). The better backup system uses the archive bit, the
file creation time and the file modification time to determine if a file should be
backed up in an "incremental" type backup. (see "The windows archive bit is
evil and must be stopped" in computer world, March 28, 2005 for the article).

I agree that if a file is moved to a different location after the image was
built, then the new AND old copy may end up restored it you rebuild, but that
is better than NO copy of the file ! I do have a utility that is supposed to do
what I want for incremental that I purchased a while back (BackupXpress Pro), but it is a little quirky and the docs are not overly helpful. I just found
(in experimenting with it) how to tell it when the last backup was for the
purpose of doing differential or incremental backups. It had looked like I had
to do a full image with it before doing the incremental, but there is a
undocumented way apparently and then it looks for files since that date.

mikey

 

I had an anti-virus prog years ago I had to dump because it set the archive bit on every .exe and .dll files it scanned. Wreaked havoc with my backup scheme.

 

Thanks for the feedback -- that helps confirm what the article was saying
about other things modifying the archive bit (I have seen others also).
I will investigate other utilities that will find/backup files based on their
creation/modification time in specified directories (I will still use the full
image backups to restore a system normally).

mikey

 

That is by far the safest way and probably just as fast in the long run.

 

I'm a little unclear on what you are trying to achieve.
If you use TI to create a full image and then later create incremental images should you need to restore a system to it's state either as it was when the original image was taken or when any of the incrementals was taken then TI can easily and safely do this. It does this by storing information on changes to the disk sectors.
As you point out a defrag will cause sectors to move and consequently any TI incremental created after a defrag will probably be quite large.
I get the impression you are trying to avoid the effects of these moved sectors by modifying archive bits and looking at file dates. The consequences of this might be that should you restore from a TI full image and subsequently restore other files from your other (non TI) file backups not only would you get any moved files twice (once in original position and once in new position) but any files which had been deleted after the original TI image was created would be restored by TI and your file date modification scheme would not be able to detect this and delete the file again.
This would seem to be a highly dangerous scheme for backups.
Stick with the TI approach - it works!