Validation *SLOW*

In beta testing it was found that verification of backups that use the new *.tibx format takes a lot longer. There was some debate about the possibility that the way verification takes place has changed, but only when there are multiple chains (full backup + incremental/differential) which is presumably not the case here.

Ian

Ich finde schon, das das Validieren einer .tibx Datei deutlich länger dauert, man braucht sich nur die Auslastung der Festplatte, wo das Backup-Archiv gespeichert ist ansehen. Mit ATI 2019 und einem .tib Archiv würde die Festoplatte mit dem Backup-Archiv beim Backup und beim validieren nahezu voll Ausgelastet sein (Wenn der Rechner schnell genug ist).

-----------------------------------------

I think that the validation of a .tibx file takes much longer, you only need to look at the load on the hard disk where the backup archive is stored. With ATI 2019 and a .tib archive, the hard disk with the backup archive would be almost fully utilized during backup and validation (if the machine is fast enough).

Hello Everyone,

the validation algorithm has been changed in Acronis True Image 2020 (for the new archive type). The changes allowed to improve the stability of the feature, but also led to the increases in time. 

I upgraded in place, ran a backup of my MBPro, about 427GB. For the last 9+ hours, it's been at "less than 1 minute" remaining. Is this the new feature described above? 

JIMRX4, was this a prior backup task or a new one? Just wondering whether it was continuing with a .tib chain or using the new .tibx format.

In my beta testing, I found that .tibx validations were running against all the chains, not just the most recent.This means that the more chains you keep, the greater the time to validate.

Tony Cuozzo wrote:

I upgraded in place, ran a backup of my MBPro, about 427GB. For the last 9+ hours, it's been at "less than 1 minute" remaining. Is this the new feature described above? 

Hello Tony,

what is the target location in the affected backup plan (Acronis Cloud, network share or locally attached drive)?  

Hi Ekaterina, 

As Bruno noted here, it looks like:

.tibx validations in 2020 are running against all the chains, not just the most recent.This means that the more chains you keep, the greater the time to validate.

Will this be the behavior going forward, or are the developers working to only validate the most current chain in ATI 2020?  It doesn't make a lot of sense to validate previous chains, and especially not every single time validation is run.  It would be great if the user could select each individual chain for manual validation if they want to go back and validate it manually down the road, but to me, it seems like the automated validation should follow the same behavior as the previous Acronis versions and only validate the current chain when it is part of the backup job script. And when pressing the validate button on the backup, it should only validate the current chain, or give an option of which chain to pick (select a specific chain or all chains).

Bobbo_3C0X1 wrote:

Hi Ekaterina, 

As Bruno noted here, it looks like:

.tibx validations in 2020 are running against all the chains, not just the most recent.This means that the more chains you keep, the greater the time to validate.

Will this be the behavior going forward, or are the developers working to only validate the most current chain in ATI 2020?  

Yes, I can confirm that validation is running against the whole archive here..As far as I understand there is not technical possibility to validate only particular chains/backup slices in this archive format

Hmmm, is it a limitation of the .tibx format, or a limitation of how it is implemented by the developers?  If this is the process now, I think this is a huge step backwards in usability and users are going to be less likely to validate backups.

Personally, I rarely validate .tib backups as it is now - I don't like that it takes the backup job twice as long and only validate manually when the occasion calls for it. That way, my other backup jobs can run as scheduled and don't get delayed by long validation times.  

Now though, with the .tibx format, if validation is always going to scan all existing chains in a backup, it is just going to get longer and longer, to the point where it is going to prevent backups and waste more time than is necessary.  Right now, it's probably not a big issue for most because this is new.  But, if someone has a retention policy of 3 months, 6 months, 1 year or longer, how long are those validations going to take to complete EVERY SINGLE TIME A BACKUP is run (assuming they have automatic validation turned on).

And this poses a new question too.  Could this be why the Cloud "cleanup" times are taking so long?  Does it have to validate all chains going back to, who knows when, just so it can cleanup space?  As I understand it, the Cloud backups have been using the new archive format since before 2020 and might explain why some people are seeing such extremely long cleanup times that are preventing other backups from being able to run until it has completed.

Ekaterina wrote:

Yes, I can confirm that validation is running against the whole archive here..As far as I understand there is not technical possibility to validate only particular chains/backup slices in this archive format

Ekaterina, I find this hard to believe, that it is not technically possible to only validate a recent chain.

Is what you say true for all types, ie, Full, Incremental and Differential?

Are you able to shed some light on what .tibx Validation actually does?

As you describe it, Validation will become a feature that nobody who knows what's going on will use, and one for which we will also see many many posts on the forum as more backup chains are created and Validation will take a time indistinguishable from forever. Either way, it is problematic.

That's what I was trying to convey Bruno - thanks for chiming in!

Example with a weekly backup chain and 6 months retention:

Week #1 - Backup chain #1

Full takes 1 hour, validation takes 1 hour (2 hours total)

Week #2 - Backup chain #2

Full takes 1 hour, validation takes 2 hours (3 hours total).

Week #3 - Backup chain #3

Full takes 1 hour, validation takes 3 hours (4 hours total)

Week #4 - Backup chain #4

Full takes 1 hour, validation takes 4 hours (5 hours total)

Skip to week #26 (6 months retention)...

Full takes 1 hour, validation takes 26 hours (*****27 hours total*****).  And you've exceeded a full 24 hours so now your scheduled backups are delayed too and if you have multiple backups working the same way, the validation is growing for all of them too!  This is not good!

Fully agree with Bruno that this needs both clarification and also more user control over exactly what will be validated!

I normally elect to keep a maximum of 2 recent version chains with a total of around 12 files but can see users having many more chains and much larger numbers of files being validated on every run, which will trigger concern over the time needed to complete.

My impression is that this is going to render Validation completely useless very few, short chains are retained.  (In which case Validation will only be mostly useless ... but completely irritating.)

Patrick O'Keefe wrote:

My impression is that this is going to render Validation completely useless very few, short chains are retained.  (In which case Validation will only be mostly useless ... but completely irritating.)

+1

Ian 

I tested this validation and here are my results:

First you should know that the backup task I used was created on Aug. 20 and I used the first release of 2020.  Just prior to this test my PC installed the latest Win 10 upgrade to version 18362.295.  Total data on disk after this upgrade increase from 75.4GB to 106.3GB.  The recent 2020 hotfix was also installed just prior to testing.

I first modified an existing tibx backup from a non-scheduled full to a scheduled, run every 2 hours, incremental.  I then ran a validation on the backup of 75.4GB of data.  That validation took 11 minutes and 46 seconds according to the log.

I then ran the backup task.  The original full backup task took 9 minutes and 51 seconds to complete.  The reconfigured incremental was 13.3GB in size and completed in 4 minutes and 28 seconds.  The total data to recover now shows 106.3GB rather than the original 75.4GB.

I went about using the PC for light tasks such as browsing and let the backup run twice more.  The first run totaled 125.6MB and took 1 minute and 8 seconds to complete.  The second backup totaled  301.2MB and took 1 minute and 12 seconds.

At this point I ran another validation of the backup.  This validation of 106.3GB of data took a total of 16 minutes and 20 seconds.  An increase of roughly 3 and a half minutes over the previous validation.

I then let the task run one more time.  It backup up 278.6MB of data in 1 minutes and 14 seconds.

I choose to again run validation on the backup.   This time the validation took 18 minutes and 20 seconds, a 2 minute increase from the previous run.

These numbers do not quite prove out Rob's numbers.  They do indicate an increase in time yes but not at the rate suggested.   The more data involved the longer time validation will take true, but I find it interesting that when I originally created the backup I ran validation and total time was 11 minutes and 32 seconds on 74GB of total data.  The next validation run after all upgrades took place took11 minutes and 46 seconds on 106.3GB of total data.  Only a 14 second increase.

Enchantech, is your backup all in one chain? If so, your results make sense. The main issue is that the validation is always run on all chains, not just the latest one.

Yes, this is a full chain of backups.  I am not sure what you mean they make sense?  Rob's numbers suggest a 100% increase in validation time with each incremental backup.  My results do not support that.

Hi,

There is really a very BIG BUG with the verification process ! In my case SSD2SSD work (some time ?) , But SSD2Raid (mechanical disk) Verif HANG after some time INDEFINITELY !!!!!!!!

Killing Acronis process is the only help in this case. Worse very frustated !

The devellopper have to TEST ( !!!!ù!) the product before selling it !

:(

[EDIT] The SSD2Raid was the first backup writed  on the Raid array... Only 1 file to validate => validate infinite loop after some time... The raid array was tested => OK 

Acronis TI 2020 ist eine einzige Katastrophe, was die Geschwindigkeit angeht. Alles geht deutlich langsamer, ohne dafür einen Mehrwert zu bieten. Nicht nur die Verifizierung, auch das Backup selbst und sogar das Starten des Tools sind langsamer geworden. Völlig unbrauchbar...

Enchantech wrote:

Yes, this is a full chain of backups.  I am not sure what you mean they make sense?  Rob's numbers suggest a 100% increase in validation time with each incremental backup.  My results do not support that.

I think what he was trying to say is that the 100% increase is with each chain (full plus incrementals), not each incremental. backup.

BRAINs,

Please provide feedback to Acronis via the in app Feedback option.

Enchantech, yes, you will see an I crease for every backup. But, I. 3029 and earlier, I my the current chain was validated. Now, All Chau s will be validated. So as you make new fulls, the time for validation is going to grow exponentially. If you only keep a couple of chains, it might not seem so bad.... U less your fulls are very large or you keep several chains, then ... Validation is now going to be extremely long since it is validating every backup in every chain!

I get what you're saying Rob, I just do not think it tests out as bad as you say it is.  Have you done testing to prove this?  Can you explain to me why the difference between a validation on a 106GB backup and a 74GB backup in the same chain only has a 14 second difference in my test?

Enchantech, yes, I've tested this and a few others have too. 

Every new chain you create will increase the validation time by the same amount.  So if you limit your backup chain to just 1 full every time, then backup 1 takes 1 hour to create and 1 hour to validate... backup 2 will then take 1 hour to create and 1 hour to validate chain 1 (same time as originally takes) + 1 hour to validate chain #2.  This repeats with each chain.  I posted results of this in another thread but can't find it, but will link it here when I do.

You can easily test this too with minimal time. Do a simple test with just full backups of your OS disk which should go relatively quickly.  Validate the first backup to get a base time.  Then take 2 more backups (skip the validation of the second and just validate the third to save yourself some time).  You'll see that the validation takes 3x times as long as the original backup validation.  If you take a 4th backup and validate, it will be 4x as long as the first and so-on.

Ok, I used incremental backup for my test.  I will setup a backup of a full disk and see what I get.

This still does not explain why a validation of a full backup of 74GB is only 14 seconds less that a 106GB validation.

Rob,

I started with a base full disk backup of my app and user data disk which is my D: drive.  The data on disk totals 145.7GB and backup completed in 8 minutes and 11 seconds to another internal disk.

I ran initial validation of the backup which took 3 minutes and 57 seconds.

I have set the backup to run every 3 hours and create only full versions.  I will let it rock and roll tonight then run validation in the morning.  Will post my results here.

Looking forward to it.  Basically, each CHAIN is what multiplies the validation time with the new format.  Just did a 4th backup and validation after and you can see that this validation is now at 19+m from roughly 4m to start with.  

On top of that, even though the incrementals and/or differentials, although, not a lot longer than the full in THAT chain, will all be running these longer times as the chains grow too.  It's a huge waste of time and really kills any desire to want to validate, especially if you have large backups - these are just a small backup of a test VM... I couldn't imagine doing this on my family photo folder over time.

Wonder what the experience with validation is in Backup 12.5. Might check out the forum and report back.

Ian

Tests completed.  My findings confirm that validation time in the .tibx backup format increases double in time or more with each successive backup when the task is set to create only full version files.

This is not true when the backup task is set to create incremental or differential backups unless there are more than 1 full version in the backup chain,

So this begs the question, how many users actually setup a backup of only full versions?  How many users setup a backup that contains 2 or 3 full versions along with multiple incremental or differential files?

I decided that I would see how a previous version of ATI worked in this regard.  Still having a PC running the last TI 2018 version I decided to setup an identical task of a backup of only full versions of a user data disk.  I ran the task on the drive which contained a total of 68.8GB of data which generated a backup file of 43.56GB taking 2 minutes and 34 seconds in duration.  After that task completed I immediately ran a validation which took a whopping 24 seconds to complete!  So I ask, what if anything did validation check?

I decided to let the task run twice more before running validation.  After these two backup jobs completed I attempted to run validation on the task.  I tried 3 times to run run validation and all failed within a matter of about 30 seconds.  The logs show errors such as:

• Cannot open the backup
• Failed to open the backup
• Failed to open the virtual disk
• The specified file does not exist
• The system cannot find the file specified

So I must ask, has such a validation ever been supported before?  At this point my opinion is that TI 2020 validation, having proven to take time proportional to the amount of data being checked is at least doing so!  I am not convinced that prior versions validation were even working at this point.

I am also of the opinion that few users will actually setup and use a task that contains multiple full version files, at least no more than 2 full versions thus, time to validate, although taking some time, is not so long as to cause the user not to use it.  Especially if the process now actually does what the documentation claims which is:

"The backup validation feature allows you to confirm that your data can be recovered. The program adds checksum values to the data blocks being backed up. During backup validation, Acronis True Image opens the backup file, recalculates the checksum values and compares those values with the stored ones. If all compared values match, the backup file is not corrupted"

I will NOT post screenshots of my experience with TI 2020 as they would only be redundant at this point however, I am posting a screenshot of TI 2018 Activity so that you can see those results.

I am also attaching the log file which shows the validation failure of TI 2018.

If validation in terms of usage is different in Backup 12.5 then I would expect Acronis to bring such difference to the True Image product at some point in the future.

Enchantech, 

While the Incrementals and differentials are relatively "normal", anytime a full is completed (not just a full only backup scheme), the validation time is going to be extended.

I take a full,a follower by 6 daily incrementals and repeat each week. I would say this is a relatively common backup scheme... Weekly or even bi-weekly. If retaining weekly backups for just a month, the validation increases 4x. And I'm sure there are people taking weekly full backups and retaining much more than just a months time frame so it just gets worse.

There really is no reason to validate older backups outside of the current chain, and no reason to keep validating chains that are no longer being modified, and that is really the problem. The behavior is broken and the increased time is ridiculous as each chain is supposed to be independent for recovery and for validation. A dependency of chain B on chain A, when chain A has no backup data related to chain B, is terrible and I feel very strongly that this is a broken model. It's also why rescue media is throwing errors after cleaning up chains and trying to recover from another chain in the same backup task.

I'm going to play with backup 12.5 to see how it compares as I suspect it is working the way I would expect it to, but need to see for myself .  Either way, this is a deal breaker in 2020  for me and the first time in many years I've felt this strongly about a change in behavior that is going to prevent ATI from being my go-to if it's working by design and not a bug.

I was also thinking of trying Backup 12.5 to see if it works properly. Hopefully I will get a chance to do so tomorrow.

Ian

Rob,

I understand your position.  I also understand that there may well be others whom practice backup as you do.  I am not one of them.

For myself, and I understand this is not for everyone, I practice backup in a very different manner.  For my desktop machines I only create periodic full OS disk backups.  I run these when there are major upgrades released to the Windows platform.  I create one prior to the upgrade and one after.  These are non--scheduled full disk tasks of drive C:.  I use junction points in Windows to direct my user data to a partition on a different drive other than my C: OS drive.  So on a weekly basis I will backup only user folders that have had significant change for the week.  There are times when I do not feel the need to even do that so I don't and because of that I certainly do not schedule backups.  I also cull older backups regularly to manage space requirements.

For my laptops I retain a full backup of the system.  Because these machines are not my primary machine, data on them is minimal and does not change much so again, I simply make full backups of them in the same manner I do my desktops.  In worst case scenario I can perform a clean install of Windows and install what few apps I run on them and be back in business in a very short period of time.

Am I concerned about loosing any data?  Not really.  I keep multiple copies of backups on various media so for the most part I can get back most data I have.  There may be some that I would loose on rare occasion but nothing I could not live without.

I also run drives that contain media such as music, movies, photos, and rather than backup these drives I simple copy this data to other storage devices for archival purposes. Why do I do that?  Such data is already in compressed format so using a backup app that essentially does much the same thing is not logical.   I simply leave the data as is and let redundancy provide data protection. So my backup needs are far different than yours and other users I'm certain.

I do understand your position in regards to the validation issue discussed here but, I do not share your disdain for the product.  I find the advancements in AP, backup speed, and the other features I use of True Image worthwhile and good improvements.  If the product no longer works for you than I suggest you use previous versions or another product.

Enchantech wrote:

I do understand your position in regards to the validation issue discussed here but, I do not share your disdain for the product. 

I'm certainly no mind-reader, but I don't see disdain for the product anywhere in this thread.  I do see (and share) disdain for the new behavior of the Validate function.  I think it appropriate that we share these feeling with Acronis to help them evaluate the impact of behavior.

There are many schemes for backups.  I could be way off base here, but I think the new behavior of Validate - when used - will negatively effect many of theme because many of these schemes result in multiple chains.  (I know that all my backup tasks eventually create multiple chains.) 

The new, more in depth checking performed by Validate would be a very useful feature if the function could be directed at a single chain.  It currently seems to be a very frustrating feature for many users.  Acronis needs to be aware of this and correct the situation if possible.  If something in the new design makes it impossible to correct the behavior - an extremely unlikely situation, I think - then it would be helpful if Acronis would actively promote backup philosophies that minimize the impact.

Patrick - yes, that's my sentiment too.  It's not to say I've lost faith in Acronis, but am really having trouble getting onboard the 2020 train in its current state and some of the changes (or bugs, or lack of implementation - hard to say on many of the items I am used to using that do not currently work, or haven't worked for a few years now). 

Regardless of how we do our own backups, the rules/guidance seem to be changing in 2020 and the clarification is not there and in this case, it was provided, but really does not make sense to me.  I am about to run my backup 12.5 validation comparison and looking forward to seeing if the behavior is the same, or not.

We all have our own backup recommendations and preferences.  For those of us who are used to certain backup schemes (like me), I prefer my weekly full and 6 incremental's for local drives and my bi-weekly full and every-other-day incrementals for a 2-week period to my NAS.  I'll never trust longer backup schemes for my OS and will alwys feel the most comfortable with this setup because of the more frequent fulls and that's even though I have several supplemental Acronis True Image backups, in addition to several others doing the same thing with different backup programs.  

Personally, I would like to see what Acronis defines as a chain in clear-cut text.  As I research it on Google, view the definition in other backup products, and how we've been told chains function in ATI 2019 going all the way back... a chain is one set of backups that include the original full and all coinciding incrementals or differentials in that particular backup and a new chain starts upon completion of the next independent full backup again.  Each chain, starting with the next full, is supposed to be a separate backup and independent of all other functionality of chains that come before, or chains that come after it.  If this is true (and it should be), then the new behavior of validation for ATI 2020 .tibx files no longer follows the definitions of a chain and is blurring functionality across more than one chain.  

What I'm experiencing and we are being told in 2020 with the new .tibx format is that:

1) the .tibx extension now requires that all chains be validated together and are not independent for each separate chain.  

2) the .tibx extension also now appears to have dependencies for recovery in the rescue media across multiple chains, even if you properly clean up version chains in the Windows GUI.  If you do this, you now end up with warnings that your backup is corrupted and that you shouldn't do a full disk restore, but can pick data out of it, instead.  Huh?!?  Why is this if each version chain has independent data in it?

---------------------------------------------------------------------------------------

https://www.acronis.com/en-us/support/documentation/ATI2020/index.html#90.html#o9322

Backup version chain

Sequence of minimum two backup versions that consist of the first full backup version and the subsequent one or more incremental or differential backup versions. Backup version chain continues till the next full backup version (if any).

---------------------------------------------------------------------------------------

Read this entire page on the user guide (this is just a snippet):

https://www.acronis.com/en-us/support/documentation/ATI2020/index.html#16143.html

• Differential

  Select this method if you want to create backup chains containing only full and differential backup versions.

  You can configure the scheme by using one of the following options:

  • Create only differential versions after the initial full version - select this item to create only one backup version chain. Automatic cleanup is not available for this option.
  • Create a full version after every [n] differential versions - select this item to create several backup version chains. This is a more reliable but more space-consuming backup scheme.

• Incremental

  Select this method if you want to create backup chains containing only full and incremental backup versions.

  You can configure the scheme by using one of the following options:

  • Create only incremental versions after the initial full version - select this item to create only one backup version chain. Automatic cleanup is not available for this option.
  • Create a full version after every [n] incremental versions - select this item to create several backup version chains. This is a more reliable but more space-consuming backup scheme.

---------------------------------------------------------------------------------------

https://kb.acronis.com/content/61844

HideClick here to see what version chain is

Version chain is a set of a full backup and all incremental and differential backups, that depend on it:

---------------------------------------------------------------------------------------

https://kb.acronis.com/content/1536

On the other hand, if you want to increase backup reliability, by not having to rely on a chain of incremental backups, then differential backups would be the best solution.

Technically there is no limit on the number of incremental/differential backups in a chain. However, since one invalid incremental backup makes all consequent incremental backups inaccessible, it is recommended to create a  new full backup after several incrementals and start a new chain.

---------------------------------------------------------------------------------------

https://kb.acronis.com/content/6730

• Incremental backups allow you to form long chains of backups to save space.

• A differential backup contains only the changes from the previous full backup. The base backup is always a full backup.

  Differential backups are useful if you would like to avoid using long backup chains and would still like to save space.

---------------------------------------------------------------------------------------

https://www.acronis.com/en-us/support/documentation/ATI2020/index.html#38839.html

Validating backups...

---------------------------------------------------------------------------------------

Backup 12.5 has no issue validating JUST the CURRENT chain.  I would hope ATI can do the same, seeing as how they are both using .tibx.  I get that Backup 12.5 is an enterprise solution and has more features and capabilities, but True Image should still follow the procedures for a backup chain in regards to validation and cleanup.  This does not appear to be a limitation of the .tibx file format based on this test.

For what it's worth Backup 12.5 actually validates much faster than True Image too - great enhancement over the home version and one of the reasons it would justify the price difference.  I haven't used Backup 12.5 much, but after these hand full of tests, I'm already pretty impressed.

So there are some growing pains with the new format in True Image.  Have no idea why that is but again, I would expect Acronis to bring the same functionality in backup and validation that is obviously present in Backup 12.5.

Thanks for testing and posting Rob.

Ekaterina wrote:

Bobbo_3C0X1 wrote:

Hi Ekaterina, 

As Bruno noted here, it looks like:

.tibx validations in 2020 are running against all the chains, not just the most recent.This means that the more chains you keep, the greater the time to validate.

Will this be the behavior going forward, or are the developers working to only validate the most current chain in ATI 2020?  

Yes, I can confirm that validation is running against the whole archive here..As far as I understand there is not technical possibility to validate only particular chains/backup slices in this archive format

Enchantech,

I'm hoping it's just a bug to work out too. 

The concern came from the note that this seems to be a technical limitation, which I'm not buying.  Chains need to be treated as chains for backup, validation and recovery or it's going to be a big mess.

Bobbo, thanks for the analysis. There is nothing in your document references to lead me to any new understandings. But, it does seem that ATI has not handled the validation of .tibx backups well whereas Backup 12.5 does this better.

Hopefully, the Acronis team will recognize the issue and address it soon. I've been holding off using ATI 2020 on my main PC until things look better.

Same thing for me Bruno. I'm staying with 2019 on my main PC until/unless some of these issues get ironed out.

Yeah, the logs I just posted are a little vague.  To add context, those are 3 back-to-back full backups with validation in Backup 12.5. 

The total time for the full backup with validation on all 3 of them was nearly the same at around 8 1/2 minutes.  The backup takes roughly 6 minutes and the validation takes roughly 2 1/2 minutes, but the times are nearly the same on each run and the validation is not causing the times to grow.

In ATI 2020, the backup time remains the same in a similar test, but the validation doubles every time a new chain is started and keeps growing and growing and growing.

Both ATI 2020 and Backup 12.5 are using .tibx so it doesn't seem to be a technical limitation of the archive format in 2020.

I could be wrong here but what I think the response from Ekaterina points out is that a backup chain is now handled as an archive whereas previously a backup chain was handled as a number of recovery points in time.

If a backup consisting of a number of full, inc and/or diff files is now an archive then validation and recovery are all dependent on each component of the chain.

If a backup consisting of a number of full, inc and/or diff file is handled as being recovery points then validation and recovery will have much different dependencies. 

This might be a limitation of consumer grade PC's that do not fully support virtualization and so to compensate for low powered hardware this change in handling of backup chains is the result.

If that is true then it is time to start thinking of new backup strategies I would say.  Backup your changed data regularly and keep separate full backups of whole disks.  This would lessen validation and recovery time.  Should also fix the issues with recovery media. 

Yes, this would be manually intensive but effective nonetheless!

Enchantech wrote:

If that is true then it is time to start thinking of new backup strategies I would say.  Backup your changed data regularly and keep separate full backups of whole disks.  This would lessen validation and recovery time.  Should also fix the issues with recovery media. 

Yes, this would be manually intensive but effective nonetheless!

Effective perhaps, but not something the average user should have to deal with.  This will likely cause Acronis to lose customers.

I found this reply to another thread interesting so wanted to post it here as I believe it is relevant to this conversation and will fix the slow validation problem when implemented.

Mount of .tibx file

Hmmm, that would be great if it does fix it!  However, I'm not sure they are related... I guess we'll find out when update two comes out.  Update 1 is the one planned for this month, so not sure when we'll see update 2.  looking forward to seeing what both fix though as I would like to use 2020, but need it to be more polished before I can commit my main system to migrating.  A couple of other update 1 fixes look to also be bitlocker rescue media working and a fix for the "corrupted" backup notification in rescue media if you have properly cleaned up versions in the GUI.

Enchantech wrote:

If a backup consisting of a number of full, inc and/or diff files is now an archive then validation and recovery are all dependent on each component of the chain.

If a backup consisting of a number of full, inc and/or diff file is handled as being recovery points then validation and recovery will have much different dependencies.

My understanding of the problem described in this thread - or at least one of the problems - is that Validate is now processing multiple backup chains.  If that understanding is incorrect, ignore everything I say in this posting.

I, unfortunately, do not know the significance of "archive" vs "backup" so I don't understand the point being made here.  But it seems to me that a single chain (full plus incr or diff files) is all that is needed for a successful recovery.  If so, I don't see the need for Validate to process more than a a single chain, regardless of the format - .tibx or .tib.  Doing so adds unnecessary processing time. 

Enchantech wrote:

I found this reply to another thread interesting so wanted to post it here as I believe it is relevant to this conversation and will fix the slow validation problem when implemented.

Mount of .tibx file

It will be interesting to see how Mount behaves. Let's hope Mount processes just the single chain pointed to.  Even though Mount is not intended as a diagnostic tool, it must do pretty much everything needed (and possibly more) to verify that a backup chain is a valid source for a recovery.  Sounds like a Validation to me.

Hopefully Mount and Validate will share a lot of code.  And hopefully that shared code will come from Mount rather than the present Validate.

Mounting the backup file, just like mounting an ISO file, in effect creates a virtual disk.  Since the tibx format at present cannot be mounted that means there is a problem with virtualization of the file.  That would in-turn effect validation and possibly recovery in some cases as these backups containing multiple full disk images must be handled virtually during either validation or recovery.

Have you attempted to recover the backups you created that have the slow backup issue?

I decided to run recovery on the test backup I created.  I got some interesting results.  First, I was able to recover the backup in Windows TI GUI.  Interestingly, the recovery tab when selected displayed my OS disk C: drive and my data drive which was mounted as drive J:.  Interestingly as well my data drive contains a folder called My Backups that contains some old backup files I left there.

After selecting the data drive for recovery TI showed a total of 39.3GB of data to recover.  I thought that to be strange as the data drive itself contains 123.5GB of data.  I selected the data drive backup as the backup to recover.  By default TI then displayed the original source data drive as the recover to destination.  I wanted to recover to another drive so I expanded the choice list and selected a blank USB 3.0 external drive I had attached.  Shortly after  I was offered a Proceed button which I clicked and the recovery began.

The recovery ran to a successful conclusion.  The TI Activity screen showed that the backup had been successfully recovered to it's original location taking 6 minutes 48 seconds.  I immediately had a look in Explorer at the external target disk and sure enough, all the data in the backup had been written to that disk.

I was curious as to how a backup that according to the Activity page contained 145.8GB of data to recover could have recovered all data and only used 39.3GB of space.  I did a comparison of all folders between the original source disk and recovered disk to find out.  Well, it turns out that even though TI activity showed that all data on disk had been backed up when it came to recovery not all data was recovered.  What was left out of the recovery were the old backup files in the My Backup folder I mentioned earlier.  These backups totaled 84.2GB which I confirmed to be correct.  Had I selected the original source drive to recover to I would never have discovered this issue.

So it appears that there is a problem when recovering data to different location when using the Windows app if there are TI backup image files contained in the backup.  It also appears that there is issue with TI in determining which location a recovery is run to!   If anyone can duplicate this then we may have another problem that needs fixing!

These issues seem to me to be bugs in the application coding.  Since I am not a coder however that may not be the case.  I do think that if the virtualization issues are addressed then validation will be fixed as well.

Enchantech, 

I'm trying to follow exactly what you did so I can attempt to test it later.  

What was left out of the recovery were the old backup files in the My Backup folder I mentioned earlier.  These backups totaled 84.2GB which I confirmed to be correct.  Had I selected the original source drive to recover to I would never have discovered this issue.

Are you saying you backed up a drive that had .tib or .tibx files on it and they were not restored?  If so, that makes sense to me because one of the default exclusions in the Windows GUI are there for True Image backup files. 

*.tib

*.tib.metadata

*.tibx

Or, did you remove those default exclusions and those files were really captured in the actual backup file that you restored, but upon restore, they were really not restored?  

If so, I wonder if this is because it was and older backup script (carried over from 2019 into 2020) and the exclusions were passed on, or something like that. 

Or is this a brand new 2020 backup where the .tib and .tibx default exclusions were removed before the backup ever ran and it did indeed back them up, but the recovery still did not restore them correctly?

I've never attempted to make a backup of any .tib or .tibx files before so have never tested this.

Rob,

Backups were performed with the standard exclusions so I did not expect the .tibx (nor any .tib) files to be backed up.  They were not backed up which I verified by exploring the backup files which were created. 

I agree that this aspect of my result is expected behavior and I was not clear on that point.

What needs to be answered is:

Why does the GUI show that TI backup files that reside on the source disk are part of the total data backed up when they are excluded by default?

Why does the recovery success notification say that the recovery has been successful to the original location when an alternate location was for recovery was selected?

When the backups were originally created the GUI shows a total of 59.2GB for the total size of the backup yet recovery is only 39.4GB, where is the rest of the data?  My comparison of the source disk and recovered disk shows that the only difference is the old backup files. So it is like this:

Original size of data on source disk = 123.5GB

Original size of backup file created = 59.2GB

Total size of data recovered = 39.4GB

Total size of old backup files excluded form backup = 84.2GB

123.5GB - 84.2GB = 39.4GB

59.2 - 39.4 = 19.8GB, where is this 19.8GB?

Rereading my previous post I realize that I left out part of this equation, sorry.

Enchantech,

I believe that would be the recycle bin, page file, system volume information and other excluded files.  To be sure though, use treesize free for a quick overview of the original disk and the recovered disk and make note of any large size differences in folders.  You can open two instances of treesize and split them side-by-side which might point some of the differences out fairly quickly.  

I did use treesize to compare the source disk and the recovered disk.  Screenshots below:

Source disk appears below

Recovered disk appears below

Where is the 19.8GB?