Differential sizes

I am testing the "new" method from another thread on managaing backup locations and full / differential backups. I am now concerned on a new topic.

Some differentials are smaller in size than the previous. How can this possibly be? If a differential is all that has changed since the last full backup, it seems to me that it can NEVER be smaller than the previous.

Does anyone else see this? And can anyone explain how this can be?

I could easily understand this if it were an incremental, but not a differential. I fear differentials may not be working properly in ATI 10, most current build.

~Bob

 

Not sure I understand your question.

A differential is effectively the same as the first incremental. In other words it represents all the changes since the full backup. If there are very few changes, the differential will be small.

F.

 

Yes, but then the next differential should be all the changes since the full. If you have a full and 3 differentials, they might look like:


2GB
100KB
900KB
1,273 KB

What I am seeing is:

2GB
100KB
900KB
640KB
1,273KB
etc.

As far as I can tell, that 640KB should never happen. Each successive Differential (NOT incremental) should be larger than the last. At least, no smaller.

~Bob

 

What level of compression are you using ?

F.

 

Normal.

Why would that make a difference? A more recent differential should never be smaller than a previous differential.

~Bob

 

Not necessarily. Compression algorithms are sensitive to patterns in the data. It is possible that changes to data make it easier to compress on subsequent backups.

There is a known bug with differentials, but this is not it.

F.

 

Interesting.

If others can confirm they see this, then it will ease my mind a bit.

And can you share the known differential bug?

Thanks.

~Bob

 

It also depends on what actions you have taken between full and differntials...

Say you use CCleaner prior to the first full backup. After browsing and mail, etc you will see the first differential with all the new information - cache, etc. If CCleaner is run prior to the second differential, the cache and other files (say a couple of dump files as well) could be removed and the next differential could be smaller than the previous but larger than the full depending on the sectors changed.

Edit: the differential bug is that if you remove a differential in the middle of a set, the later differentials will not validate but can still be used for restoring the disk.

 

Interesting.

In my case, I am testing the limit of backups to the backup location which has never worked for me, but I have new information from another thread worth testing. So I am running 9 differentials with little in between. Not "nothing" but very little changes in between. I am now up to 7.

The first was, of course, a full backup. Each subsequent is a true differential. With little change, I am surpirsed any can be smaller than the previous.

I have limited my backups to 8, so I expect my ninth to replace the first differential and then on 10, to run a new full backup as I have instructed the task. I will know soon.

But nothing such as CCLeaner, deleting temp files, defrag, etc has been run to attribute to the size difference.

And thanks for posting the known bug. I assume when you say "middle" it is truly what you mean and not that in my case, replacing that first differential with number 9 will cause the validations to fail. And I really wish TI did not revalidate the original full with every differential validation. Waht a waste of time.

~Bob

 

Hello rebop,

Thank you for choosing Acronis Disk Backup Software.

Please notice that foghorne is correct about data compression.
Please also notice that when your backup location will reach limit (8 backups total), the next differential creation will make the first differential to be consolidated with the full backup.
You can find the detailed instructions on how to use Acronis True Image 10.0 Home in the respective User's Guide.

Thank you.
--
Marat Setdikov

 

Thanks for the reply, Marat. Believe it or not, I actually have a printed copy of the manual but had been trying without success to make a monthly full and differentials every three days with no more than 8 differentials with no success. I find your method untintuitive and without the posting referred to above, would not have found this. Igor tried to help from your support and told me to wait for the next build.

But, that aside, your post is unclear to me. What does this mean? :

"Please also notice that when your backup location will reach limit (8 backups total), the next differential creation will make the first differential to be consolidated with the full backup."

Today I exceeded 8 backups and it did indeed do something to limit the number. ALL backups, including the Full changed their dates. Are you saying that it somehow took one of the differentials and combined it with the Full? I just do not understand what you are saying.

And I am now set for a max 8 backups and a Full after 10 Differentials. Are you saying that maybe I don;t even need to set that full as it becomes combined with a Differential?

Please explain.

And thanks for taking the time to reply.

~Bob

 

Bob,
That is indeed what it is doing. This is the process I see, this example is based on a Backup Location keeping 6 backups, and a Task calling for a new Full Backup after three incrementals:

After the backup is done, your image file should be in D:\Backups with an automatically generated name in this basic format: 2007_03_15_07_05_30_813F.TIB This default naming indicates the date and time the file is created, in this case, March 15, 2007, 5 minutes,30 seconds and 813 milliseconds after 7 AM

2007_03_15_07_05_30_813F.TIB --- This is the Full Backup
2007_03_15_07_05_30_813F2.TIB --- This is the First Incremental, Note that it keeps the file name of the parent full backup, using "2" at the end to designate the second file in the series.

If you run this task ten times, (I'm substituting the long file names with A, B, and C) you should see this sequence in your Backup Location folder:

A-F (full backup)

A-F2 (first incremental)

A-F3 (second incremental)

A-F4 (third incremental) ***Limit reached in Scheduled Task, next is a new Full backup.

B-F (full backup)

B-F2 (first incremental) ***Limit reached in Backup Location. Consolidation starts with next backup. Note: consolidation can be a very time consuming process, True Image may appear to "hang" when nearly done. A temporary file is created in the Backup Location, with a long file name such as this:
98333365-623D-44BC-A400-B5F26B7C0EC0FDP1.TIB.
If you can see this file in the Backup Location, using Explorer, the backup consolidation process is still ongoing, all evidence to the contrary.

B-F3 (second incremental) A-F4 is consolidated into the Full Backup A-F, so now you have A-F, A-F2, A-F3, B-F, B-F2, B-F3

B-F4 (third incremental) A-F3 is consolidated into the Full Backup A-F, so now you have A-F, A-F2, B-F, B-F2, B-F3, B-F4 ***Limit reached in Scheduled Task, next is a new Full backup.

C-F (full backup) A-F and A-F2 are consolidated, now you have A-F, B-F, B-F2, B-F3, B-F4, C-F

C-F2 (first incremental) A-F is deleted, now you have B-F, B-F2, B-F3, B-F4, C-F, C-F2

And so on. Keep in mind that True image will not delete a Full Backup until a new one has been created, so make sure you have a very generous amount of extra disk space for your backup locations.

 

Thanks again for taking the time to post that CatFan, but I'm afraid I am still not totally understanding since I have my setup different.

In yours, you make another full before you have reached the limit of backups for the location. In mine, I make a new full after I have exceeded the location limit and more differentials have been run. So it is unclear what it does in the period between exceeding th number of backups limit and running a new FULL.

Marat seems to be saying that the next differential after exceeding the limit combines differentials. I am not sure that is true from what I see. I would expect it to just delete the oldest, but every file in the location, inlcuding the original full has changed date, although it does not appear they have changed size. Though, to be accurate, I did not write down the file sizes.

Now, in a nother 2 backups when I run another full having reached the set limit of number of differentials, I expect it to work as you say, but for now, not sure what it is doing.

~Bob

Ps. Ok. just reread your post again. So I understand that the earliest differential is not deleted, but combined with the original Full backup now. If this is true, this is unexpected by my experience with backup sets. But maybe.

And if so, what happens when the differential being combined has a newer version of a file that exists in the Full? Is it overwritten? Are both copies kept? This could be key to my understanding what is happening here.

 

I really don't know. I don't know if Acronis has an explanation someplace.
You might create a new, different backup location and then create a task with a small amount of data, run a full backup, then start changing some files and running your differentials, see what you get. You can do a lot of testing in a short time if you keep the amount of data small. -CatFan

 

Ok, this is now working exactly as described. Much appreciated.

The only problem is that EACH differential now validates TWO full backups plus differentials and takes 4 hours to validate. Backup is very quick. Validation is a pain.

I can understand validating the latest full, but not all.

We need more control over validation. If a file has been previously validated, should not need it again.

~Bob

 

Bob,
Very glad to see it's working for you. At this time, TI validates all files in a Backup Location, even if they are all full backups. Acronis has this post that you might want to look at: https://www.wilderssecurity.com/showpost.php?p=882898&postcount=3

Regards, CatFan

 

Thanks CatFan. Couldn't have gotten here without your posts. Much appreciated.

And good to know they are at least aware of this.

~Bob

 

Dear Catfan,
Thanks for your very valuable posting on how the TI system works with location limits etc. However, one thing is not clear to me. It is the part you describe after the limit of backup location is reached. You write:

>>> QUOTE
F4 is consolidated into the Full Backup A-F, so now you have A-F, A-F2, A-F3
>>>UNQUOTE

This seems strange to me. The oldest part of this backup is A-F, the next oldest is AF2 etc. A-F4 is the newest incremental.
Why should the consolidation process take the latest incremental (A-F4) to consolidate this in the full backup and than add the older ones as an incremental to this full? I guess that it would be more logical that the OLDEST incremental backup is consolidated in the full, and the newest are added as incrementals. It should than read

The original A-F2 is consolidated into the Full Backup A-F, so after consolidation you have A-F, A-F2, A-F3 where the new A-F2 is the changes of old A-F3 to the original A-F2 etc.

Or am I missing something?

Thanks!
Paul Smulders

 

Paul,
Sorry I don't have a definitive answer to your question.

I built the text file from using Explorer to observe what happens with the file numbers as the processes took place. When the consolidation finished, A4 vanished, so either A4 was consolidated into the Full, or A2 was consolidated and the sequence renumbered.
Regards, CatFan