Differential Backup - How is it done?

The speed of the differential backup is clearly too fast for TrueImage to have actually read and compared all the sectors stored in the full backup to the current sectors on the disk.

Also if I boot into Linux and directly change a sector within a file. Then reboot into Windows and run a TrueImage differential backup, the changed is NOT detected.

I would like to know the technique used to detect the changes that the differential backup backs up.

I am speculating that it uses the file modified timestamps and compares them to the timestamps on the files in the full backup?

It is important to know how it detects the changes so I know what trouble I may get into when, for instance:

1. booting into different operating systems
2. Using TrueImage to back up a removeable or external drive that may be plugged into several different computers.

Anyone have the inside skinny?

Thanks!

 

As far as I know, TI just checks the saved sector "map" with the new one. It probably processes it in blocks as it looks for changes. It generally takes several seconds to several minutes.

Can you describe in detail what you did?
What version and build of TI did you use?
Were you testing an image backup or a files & folders type backup?

I don't think the timestamps are used.

 

Reportedly it does not use file date/timestamps nor file-attribute archive bits.

 

This is an interesting question and there could well be a difference between images and Files and Folders backups which tend to use the PCs file system much more extensively. As imaging now allows file excludes it also must deal with the file system a bit more than previously.

I could see where using a disk editor to directly change a sector in a file could leave no impact on the in-use bitmap. However, when you modify a file in normal usage, a new file is written to a different location and then the old file is deleted. This will change the in-use sector bitmap.

Does anybody know if Windows has its own in-use bitmap? I have worked on other OSs whose file systems operated with a bitmap mechanism.

One would hope that using a different OS to manipulate the contents of a disk would keep the file structure pure. After all, Acronis does it with Linux!!!!!

 

Thank you for your replies.

I was doing image backups.

My little bit of experimentation seems to show that even though I am doing image backups NOT "files and folders" backup, that TI uses time stamps to decide whether a change has occurred or not. I guess this is reasonable. And seems to make sense based on the time TI takes to do the differential.

(In the descriptions below when I say "directly change", I mean I booted into linux and used the "dd" command to directly copy, edit, then copy back sectors on the disk, whether in the test data file, or the directory)

1. If I just directly changed the data in a few sectors within the test file. Those changed sectors did NOT get picked up by a differential. (As you noted this would not change the in-use bitmap, nor the timestamps.)

2. If I then directly edited the directory entry of the test file to change the "modified date" (I changed it to an EARLIER date), the file's data was picked up as changed. Note it seems the differential was smart enough not to rebackup the entire file, just (more or less) the modified section.

Note that step 2 would NOT change the in-use sector bitmap.

I wouldn't be surprised if the program used more than one method. Certainly seems like it would be important to compare the in-use bitmap as the primary or backup method.

(Note my tests were done on a tiny FAT12 partition.)

I would like an option to FORCE a Differential backup that used a sector by sector compare of used sectors. Even though I realize that would take a long time.

I would really love if all backup software explained HOW they did things like differentials. It does make a difference to users how it is done.

For instance I changed the date and that caused the differential to pick up the data change. I didn't test what would happen if I only changed the modified time by say one second? Does TI compare the entire timestamp or just the date?

Anyway, I'm always for more info.

Thanks, again.

 

It has been stated more than once on this forum that TI does not use time-stamps or the archive bit for determining changed files. OTOH, any change in a directory entry might trigger TI to look more closely at a given file. All of this is speculation, of course, and the only people who know are the TI writers - who may consider this proprietary info.

If you don't care about the time and can do the same about the space, a Full always catches everything. I personally only do Fulls. But I only image my OS/APP partition, not data. I use SyncBack for data since I like data files in their native format not stuffed into a proprietary container.

 

I did see a post or two that made that assertion, but they seemed to be just users (as versus company reps) that were going on the assumption (that I too originally assumed) that the differential backup was exactly what one would assume it was. A used sector by used sector compare, and saving only the differences.

I repeated my experiment, and it is clearly NOT the case.

Direct sector modification of the data within a file was NOT picked up.

This time however I was able to trigger the changed data being picked up by direct sector modification of the directory entry to change the read-only attribute to ON.

So it seems that TrueImage probably does it's differential backups by comparing directory entries and some (all?) changes in directory entries will trigger a differential backup of the file in question (as you suggested).

Note that of course in normal usage, most of the time this essentially amounts to using the timestamps to create the differential.

I appreciated your comments, and also your suggestions about full backups and SyncBack.

Sigh, unfortunately every strategy has it's drawbacks, whether size, speed, proprietary containers (as you mentioned), etc. That last one is a bummer. I wish all the vendors would spell out their container specs so if they ever go belly up we can still get our data out.

Thanks again for your input.

P.S. I became suspicious that the differential did not do a used sector by used sector compare as that would require at the minimum reading all the currently used sectors on the disk being backed up, and the differential backups were not taking nearly enough time to accomodate that. Reading all the data in the stored full backup is not strictly necessary, if one is willing to accept use of something like checksums to "describe" blocks of data. I surmised from study of another vendor's product that they are probably doing that. Of course, statistically, a checksum is unlikely to be fooled, but can be occasionally. Ah, another drawback.

 

If you directly edit a sctor, there is no updating to the MFT is there?

 

My experiments have been with a tiny FAT test partition.
But I would agree with you that if you directly edit a sector within the data area of a file on a NTFS partition the MFT would not get modified.
(And I am wildly guessing here, but I am pretty sure the modified sector would not get picked up by a differential.)

 

Hello mtmp04 and everyone interested,

Thank you for choosing Acronis Disk Backup Software.

We are sorry for delayed response.

That is certainly an interesting observation. I have forwarded your question to our experts, and will let you know their answer.

Thank you.
--
Marat Setdikov