Problem with incremental/differential backups of True Image Home (v11)
I'm using now for about 11 months Acronis True Image Home (v 11.8082 Dutch). But I'm still struggling with the problem that sometimes (but too often) the file size of an incremental image backup is unexpectedly and unexplainable large. Of course, that is a large frustration and I'm very disappointed about this mysterious and unreliable behaviour of this nice and important option.
But maybe I've found the reason now. After a restore of a full image and no major (user initiated) modifications of the OS-partition, the file size of the next incremental backup was (again) nearly as large as the size of the full backup. That let me thinking on information of Norton Ghost (but I'm not sure if I remember that correctly) that during an image restore the clusters were 'reordered' (so, restoring was defragmentation at the same time).
Note. To prevent unnecessary changes on the drive, I use as less as possible all kind of actions/processes that works in the background and certainly not a drive defragmentation program. I try to run such a process only when the next image backup will be a full one.
My question is if perhaps ATIH is doing something like that during restoring. But it seems to be not possible (anymore) to ask this to Acronis Support or Customer Service.
So, I've done some troubleshooting to find the answer on the question myself.
To exclude the influence of the Windows OS (XP Pro, SP3), I run the following sequence of operations from the Rescue Disc (without rebooting):
1. full image backup
2. diff. backup
3. restore of full image
4. diff. backup again
The processing times of both diff backups were extremely different (a few seconds versus about 6 minutes) and so where the file sizes (1 MB versus 1407 MB; full size 2408 MB). This is, in my opinion, a hard proof of restructuring the drive content during a restore.
Note. Using the sector-by-sector approach option is not an appreciated solution for this problem (large full image file sizes).
Maybe it looks a smart idea of the developer, but for image backups restructuring during restore has a catastrophic impact on the incremental and differential feature. After a restore it's not the "True Image" anymore.
Note. At page 16 of TrueImage11_ug.en.pdf there is the following statement: "Further, it does not back up swap file information (pagefile.sys ...". That is only true if you enter every time that filename manually at the File Exclusions screen.

- Log in to post comments

bodgy wrote:Has a defragging utility run between making images, as this will almost certainly make the next incremental image as large or larger than the original full.
Hi Colin, please read the first Note (To prevent unnecessary ...)
And a few lines below: To exclude the influence of the Windows OS ....
- Log in to post comments

Hi Chris
Yes, but that still doesn't preclude the possibility that a defrag has been run. Do you have any other software that might cause this over aggressive Windows Indexing, bit locker, compressed disks, enabling or disabling of hibernate option, page file optimisation program?
How often are you restoring your system? I missed that in my first read of your post, as you surmise when restoring the sectors don't go back in the same place (that would be cloning) so your next image would be as large as a full because the sectors are different.
I'm obviously missing the point you are trying to make, why is this a problem, or is this just an observation ?
- Log in to post comments

I assume that the Acronis Rescue Disk don't include an unwanted (and hidden) defrag program. :-)
Restoring is very irregularly, But when there is something wrong (or a little "strange"), I restore nearly always a previous situation (image backup).
It is a problem as well as an observation. Knowing this is already important, because I now can predict when a incremental or differential image backup will be (too) large. So, after every restore I have to make a new full image backup and that reduces very much (depending on restoring) the advantage of the "additional" backup.
Note. When I restored a full image, I'm "lucky" (and other users too) because I make (from now on and immediately after the restore) a new full image backup that replaces the used image backup. But when it is the first (or later) incremental, I have to do the same. However, this time the "additional" feature is useless.
And to the developer(s): restore should have a choice whether or not restructuring is allowed. OR (when currently the sector location is normally not saved), there should be a third backup option: sector-by-sector approach of only the used sectors.
Note. I have not yet tried a sector-by-sector based image backup, but I assume that unused sectors/clusters are saved too. I will at short hand test this (by looking at the resulting file size).
- Log in to post comments

Only a few month ago, I discovered that the "re-ordering" of sectors during a restore, can be prevented by selecting the 'Sector-by-sector' option at the 'Type Selection' screen.
Looking back, it's a pity that:
- nobody has responded to this topic nearly a year ago to tell me that.
- the explanation in the manual (TrueImage11_ug.en.pdf at page 50) is not clear: "The program will restore both used and unused sectors of disks or partitions".
- the 'Sector-by-sector' option is not selected by default (at least not when using the Rescue Disk) as it should be when restoring.
- I "forgot" to test this a year ago.
But if the description of that option would have been something like "Restore sectors to original location", I would have known what to select without looking at the manual.
Note. The current situation of the backup options together with the explanation at the screen and in the manual, is in v11 and in v2010 (at least for me) very clear.
Note. Restoring with v2010 is always with the sector-by-sector method, because the other selection (with "re-ordering") is no longer available. That means that restoring can sometimes be impossible, even when there are enough sectors available. See also this topic at reply 2010-07-31.
- Log in to post comments