Incremental backup of NAS always size of full backup

Its just this week that I'm testing ext3 storage on a NAS. Thus far I can say there is nothing magical about target which would cause the total size of the backup to be about the size of a full. The culprit almost always akin to your drive actually changing that much with the typical villian being a defrag program which has been configured to be allowed free reign 24x7 access to re-arrange any file on the drive as it sees fit.
If a defrag program moves any cluster of a file then the entire file will be marked as dirty. So even though you physically may not have even touched your PC today, an OS such as vista or a defrag program such as diskeeper might have touch it and because of that defrag action acronis thinks it has several gig to backup.

Thanks oracledba.
I'm running XP with no auto defrag program attached to it.
The NAS box runs a modified Linux system on it as far as I know. I'm not a Linux expert, but I was under the impression that ext3 does not need defraging.
The file modified dates seem to remain unchanged between backups, but this is obviously only one of many variables that True Image would be looking at to determine whether a file has been changed or not.
Is there a tool or log file that would tell me what it is with each affected file that causes True Image to think that the file has changed since the previous backup?

oracledba wrote:

Thus far I can say there is nothing magical about target which would cause the total size of the backup to be about the size of a full

It seems that OP backs up the NAS itself, not to the NAS. May be it reports file change date incorrectly. (or how else are changed files detected for incremental backup?)

chemoul,

Does the same thing happen if you backup some files from a standard Windows share?

I just checked my NAS ext3 device. As I said before this week is my first backups to this device. I can report there there is a full with two incr files on it. The full is 57g the first incr is 7 gig the last incr is a few hundred meg.
all of these are normal/reasonable values and reflect my original device and the amount of work I did on that pc between backup attempts.

There is an acronis white paper that describes what acronis does to determine if a file has changed (or not), I don't recall the exact details but the basic take away its makes a hash of several inputs including date, size, and sectors if the resultant hash is different the file is different. The implication is acronis reads the last .tib file created to get the prior MFT/FAT to obtain the prior hash values and then compares that to your current devices MFT/FAT hash values any new hash values are what goes into the INCR.

Though I do not have a solution for you, I can say that for me acronis behaves the same regardless of the target device being ext3 or ntfs.

Please confirm the panel found under "backup method" is a radio button of incremental. also on this panel confirm there is nothing unusual in "create new" full after xx incr that might explain the behavior.

oracledba,

What happens if you map the NAS share to a drive letter and then use TI to backup files from the mapped drive to another location (a USB drive for example)? Do Incremental backups get created correctly?

can do this test later tonight (apx 16 hours from now).

Test performed, not sure why we are doing the test other than the intellectual interest of if acronis can make INCR backups of a NAS/ext3 source drive.
Here is what I did and the results:
Within the ATI-2010 panel "backup type" one can only choose "disk and Partition" for locally mounted drives this fact precludes one using this backup type for the NAS/ext3 device as it is not local (this not being local is true even if one has a mapped network drive to that NAS device)

However one CAN choose the backup type of "data" (which I did).
From there I defined a job and set check marks such that the drive "z" drive and Just the entire "z" drive is selected for backup.
this "z" drive is the mapped drive letter for the NAS/Ext3 device.

I used a local folder of my C:\ drive as the target location for the resultant ".tib" file of this backup job. (the C:\ drive is NTFS).

As for the backup job itself under "options" I selected backup method "incremental"
I then saved and ran this job.

Now it helps to know that my drive "z" pretty much only contains ".tib" files.
As you know ".tib" files are excluded from full backups by default.
However I did have about 45 Meg real user data files on that drive as well.

I then ran the backup for the 1st time, this was my "full" and sure enough the resultant .tib file was 4 gig.
I was actually rather shocked about this 4 gig as I can only account for a 300 meg of files certainly not 4 gig of junk.
I then immediately ran the backup again.
This would be my 1st incr file of this chain.
The result .tib file was 1k (actually shockingly small) I was expecting more overhead that that.
I then renamed an existing .jpeg file on the "z" drive this file was about 3 meg in size.
I then ran the backup again, the resultant .tib file was apx 3 meg.
I then immediately ran the backup again the resultant .tib file was 2kb in size (not 1) but still shockingly small.

So in conclusion, Yes Acronis CAN perform an INCR backup of files residing on NAS/ext3 filesystem.
After the initial full, each subsequent incr .tib file of the chain contained what one expected an INCR would contain ( just changes)

I was curious about the test because it duplicates more closely what chemoul was doing: Creating a backup from the NAS (Ext3) mapped drive to a local drive (USB, in that case). Your first backup tests were to the NAS.

Did you find out why the Full backup was 4GB? That seems really odd with only 300MB of data.

The 4gb does seem odd, I haven't researched why this is true. Thanks for making me do the test, I read the original post too quickly and got source/target confused and thought what I happened to be doing here anyway was a close match to his situation. We still haven't solved the original posters issue other than to learn the bad behavior experienced is unique to his pc as compared to similiar hardware here. At this point I don't know what else I can suggest for a resolution. As for why the 1st backup was 4gb instead of a the predicted 300MB, time constraints force me to drop the issue.

Thanks for your replies and sorry for the delayed response, I was away.

Just to clarify, I back from a NAS to a USB drive, via my PC with True Image installed.
The NAS is mapped as a network drive, but "My Documents" folder also points to the NAS. I checked my backup settings and it backs up from "My Documents", rather than from the network share.
I haven't tested backing up from another windows share yet, but may select the mapped drive rather than the My Documents folder to see whether I get a different behaviour.

Also, I noticed that if I complete a backup and then run another incremental backup a few hours later, the backup is only a few 100MBs, which is more in line with an incremental backup (although no files have changed really).

If I wait for a week or so, the incremental backup then has the essentially the same size as the original full backup.

I'm not an expert. But reading over this it makes me wonder if the NAS is doing something periodically that causes it to be "re-recognized" by ATI, and is thus causing ATI to run a full backup instead of an incremental (sort of like defragging would do). The fact that oracledba did not have this problem could be due to a) using a different brand/version of NAS, or b) not waiting long enough for whatever the trigger is that causes the misidentification. A NAS isn't just a dumb drive. Depending on the model, It can have the equivalent of it's own little OS running, which may include periodic maintenance or network events. It may be hard to track down, but I'd try to figure out what the NAS is doing. Again, I could be wrong. I'm just throwing an idea out there.