A question about Differential Backups

I am trying to understand Acronis' logic behind Differential Backups.

Normally a differential backup means that the differential file contains all the changes since the full backup to which it is appended. I assume that Acronis interpret "differential" in the universal way.

So let us assume that a system partition is backed up daily using the differential backup method as follows:

* Full backup filename : WinSys_060717 (17th)

* 1st differential backup filename : WinSys_0607172 (18th) (TI appends the 2)

* 2nd differential backup filename : WinSys_0607173 (19th) (TI appends the 3)

* and so on.....

Let us assume that on the 20th the user wants to restore a previous image because of some issue with the system (e.g. an update that has had a negative impact).

Let us further assume that the user knows that the problem occurred on the 18th so they want to restore the system to the last full image. To do this they delete the 2 differential files and perform a restore.

In terms of my experience of other backup utilities the above is an accepted method of restoring to a previous version.

I tried to run a test of the above scenario in TI but received a message back that the WinSys_060717.tib file was not the last in the series and that I should restore the last file in the series.

With an incremental backup that is understandable because each file contains just the little bit of change that has occurred since the last incremental. But with a differential backup that is a little strange because any file should contain all the changes since the first full backup file was created.

Theoretically any differential file selected should restore the system (or data) from that point backwards, ignoring differential files created after it.


Any thoughts or comments....

 

What you're saying makes sense to me.
If you delete the 18th and 19th differential files, and used the 17th to restore from, it should have been able to do it.
I think I remember reading there is a bug not being able to verify a differential backup unless all prior differentials were present, which shouldn't be the case.
Maybe this has something to do with what you're describing since it created some differentials and now is having a problem with the files unless they are all there.

 

MerlinAZ, thanks for the info.

So...... general question for the Forum or Acronis Support....

Question

Does TI9 require all differential files to be present in order to restore any one of them?

(If the answer is "yes" then the next question must be "why oh why" )

 

When this is true then differential images would have any more value above incremental images.

They would only require more space which is a negative thing

 

Well exactly.... jeremyotten you are of course 100% correct.

The 2 BIG disadvantages of Incremental backups is that a) if any one image in the series is corrupt then the entire series is useless and b) the user must restore up to and including the last image in the series. The only advantage of Incremental backups is that they usually take less time to create and take less disk space. But with big disks today this advantage is almost meaningless.

The 2 BIG advantages of Differential backups is that a) it does not matter if an image is corrupt because you can restore to the image before or the image after the corrupt image and b) you don't have to restore the last image that you created because that image may contain something (e.g. a file or program or setting) that is causing a major problem. You can simply go back to the last known good configuration. (The concept is similar to a Windows Restore Point, in that each Restore Point is independent of the others).

IMPORTANT

If TI9 requires all differential images to be present in order to perform a Restore then in my view that is a BIG BUG THAT NEEDS TO BE FIXED..

 

I recall this already being noted as a bug.

 

Something screwy here. What would be the point of creating differential files if you can’t use them to restore to any given level? Bugs and more bugs. This should be address by Acronis immediately.

 

Actually, it's not that hopeless.

If one image in the series is corrupt, the set can be used up to the corrupt image creation date. Since the validation tool performs the check on the whole set it takes some moving of the last part of the series to another folder and back to identify (through validating) the last good incremental and delete further files. It's time consuming, yes, and you loose the images from the corrupt file on.

When you start a restore from a healthy incremental set, you select any one file from the set (regarded by TI as a Multivolume Archive) and on the next screen you are presented with a list of dates, corresponding to the creation dates of the files in the set, to select from for restoration. So you can restore to any state previously imaged. TI will take care to include all the earlier files automatically.

 

On the differential backups - the bug only exists in the validation of the archives - you can restore any individual differential it is just that the validation of later differentials requires the preceeding ones to pass validation.

 

Yes, but keeping all previous differentials just for validating the last one is, in my opinion, a terrible waste of disk space, since avery image created should be validated. If a user wants to have all the intermediate states available, the incremental startegy makes more sense.

 

Hi there bVolk,

I guess that's why Acronis Support have already acknowledged that it's a bug . Hopefully the Acronis Development Team will fix it in a future build so that TI only requires the original full image plus the specific differential you wish to validate. Users will then be able to delete any unwanted differentials if they wish.

Regards

 

Hi Menorcaman & bVolk

Thanks for your input, I was not aware that this issue had already attained "Bug" status.

What about a "fix" date or a "fix" build? Any news on that?

bVolk wrote ....

You are right of course. A little careless typing there on my part. Thanks for the correction.

Mem wroter....

Well in practice that is the same thing isn't it? No one would ever restore an image without having validated it, the two operations are in practice tightly associated with each other.

A new question....

What if a user has all the differential images and let us say one of them won't verify? Is a restore possible?

(I get the feeling that Acronis have done a little "copy & paste" job and taken some of the code from Incremental and used it for Differential)

I am not happy Acronis make my job much more difficult with this lack of attention to detail.

 

As far as I'm aware the answer is "yes" (assuming of course that you're not trying to restore the differential that failed to verify ).

Regards

 

Hello Menorcaman,

I saw the acknowledgement and I also expect they will fix that issue, eventually.

My reply to Mem was meant to oppose to his wiew regarding the consequences of the bug, which is somewhat too lenient in my opinion. Except for those who follow Xpilot's approach.

 

Guys,

Just finished reading throught this post and of course found it extremely interesting as you all have brought up very valid and useful points.

I've read in other post concerning Acronis' lack of update documentation and/or lack (or desire) to expand on update details stating such things as "improved GUI" or similar - specifically what and how was it improved?.

All this makes me wonder, since I purchased this program based on a recommendation and not checking into the company's history - just how long has Acronis been developing TI-9? Sure doesn't seem very long considering all the issues!

 

Xpilot wrote....

Of course this is a valid argument. And on our own home or work PC's this is probably what many of us do.

However, things are not like that in a small business environment. Many small businesses walk a tightrope between the Tax Man and the Bank Manager. Costs are always as issue. And it is not the cost of the equipment it is the cost of the expertise that is needed to make it all work.

My clients are for the most part good at what they do, but what they do has nothing to do with computers. They look to me to provide them with cost-effective solutions that do not need an MSCE to run them. And disaster recovery is absolutely key to their continued existance.

 

Hiptech wrote.....

Many of us in this Forum are agreed that ATI9 is very rough around the edges. However, difficult as it may be to believe, it is still the best product of its type currently available.

Now I won't mention competing products by name (the Global Moderator will bounce the post) but many of the long-standing members of this Forum have all had heart-stopping, nerve-jangling experiences with other backup utilities.

So, if you have just purchased TI9, you did the right thing.

All we want is for Acronis to stop adding "bells & whistles" to the product and give the developers a chance to sort out all the underlying issues that impact negatively on the product and on the customers.

 

You've just reminded me of one of my pet hates - the (in)famous Acronis True Image WISH-LIST thread .

Regards

 

I couldn't agree more ...

 

Perhaps the WISH-LIST only needs prioritization like disregard (postpone) all requests not related to improving product reliability, performance and intended functionality.

 

With tongue in cheek, I had previously suggested that perhaps Acronis Support should start another WISH-LIST thread for what users would like to see NOT included in True Image .

Regards

 

Perhaps it is now time to remove tongue from cheek..?

 

One person's bell or whistle is another person's bloat. Of course, the reverse is true too. Which is just another way to say diff folks want diff things.

I don't think the prudent approach is to make a program inherently free of all but bare bones features, but rather to make the features optional. It even makes sense to have several prepackaged option-setups available at installation, out of the box -- typical, custom, advanced. bare bones.

 

Shieber wrote....

In principle what you say has a lot of merit and is certainly the optimal way to develop and present software.

I think the real issue here is that many users of TI are frustrated when functionality of dubious merit is added to the software while long-standing issues remain unresolved.

Acronis is a commercial organisation and as such needs to balance resource utilisation against perceived commercial benefits. Developers cannot be assigned to fixing problems if they are busy chasing the next "gee-whiz" thing that marketing thinks will make TI the killer-app of all time.

And very often marketing gets it wrong. What is perceived as a hot-shot selling feature is in all probability not known, used or even understood by 90% of the client base. All too often the foundation stones of what comprises good software are forgotten while developers spend their valuable time on developing functionality which at best is questionable.