Skip to main content

Validation *SLOW*

Thread solved
Enchantech wrote:
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? 

Where does the GUI show the 59.2 GB? Is it in the Activity tab?

What's the actual size of the backup file?

The 59.2GB shows in the GUI as the backup file size created from the source disk in the Activity window.  Screenshot below:

 

Next screenshot shows the recovered data:

Note that the activity shows that data was recovered to the original location yet in reality the data was recovered to a different drive.

I am asking can anyone reproduce this in a recovery operation where you have a backup showing as compressed size of 59.2GB, recovered size of backup is 39.4GB and original size of data was 145GB and change?  In my example there is a total of 85GB of old backups which were excluded from the backup by default settings so from the 145 original we loose 85GB and have 60GB left in round numbers.

When recovered this data is now 39GB in size yet no major changes in data appear in a side by side comparison.  What happened here?  I do not buy the hyberfile etc. idea primarily because this is a data disk and not an OS disk.

 

 

 

Going back to your TreeSize Free screenshots, I see the original size of the data as 123.2 GB. But your latest post says it's 145GB and change. Where does that 145 number come from. I'm not seeing it.

Taking the 123.2 less the 84.2 in the My Backup folder leaves 39 GB, which is what was recovered.

So the question is, why does ATI say in the recovery tab that 59.2 was backed up. I didn't see an answer to a prior question... what is the size of the actual .tibx file? If the file is about 39 GB, then the problem may be merely in the reporting. If the file is about 59 GB, then we have to wonder what's there.

So I have to go back to what Bobbo said a couple days ago... did something in the My Backups folder get put into the backup but not restored. Since My Backups folder does not even show up on the restored image TreeSize Free list, that would be the place I'd look. Why did the folder not get restored, even if empty? Are you able to explore the backup file to check for that folder contents?

 

As far as I can tell, it restored all of the actual data correctly when looking at the TreeSize comparison, assuming everything in the "My Backups" folder was .tib / .tibx files and completely excluded - the resulting drive has nearly the same size as the original.

So yeah, where is the 58.9GB calculated?  I believe I've seen this question from other users in previous forums.  The best I can tell, is that it's calculating more data based on other excluded files (maybe system volume information or recycle bin, or pagefile) in that number, even though it's really being excluded in the backup.  

Or, another thought... junction points.  If this is the physical disk (which by the looks of treesize, it is), then all physical data on it will be backed up and restored.  However, if there are junction points where it appears to Windows and/or Acronis that the data is larger, but the physical data actually lives somewhere else because of a junction point that makes it appear to the OS or the application that it would be on the disk, that could explain the calculation difference versus the actual physical data difference.  

Acronis shows that 59.2GB was backed up, but how big was the actual .tib file in the end when viewed in file explorer too.  Is it larger than 39GB or smaller?  I would expect it to be smaller than 39GB since compression would shrink it more.  If it is the same size or larger, that adds to the mystery.

 

I find it hard to reconcile the different sizes we are dealing with here:

- data selected for backup, data backed up, data available for recover are calculated by ATI. Note the calculation of the data available to recover is different from the data sizes shown in the recover tab. It is probably because the calculation is some times an estimate, some times an actual measurement of data being read, transferred or processed, while the data sizes shown in the recover tab are based on sectors and metadata in the TIBX file.

- actual source (partition or disk) data and TIB file size are calculated by Windows based on the NTFS volume information

I always looked at these data points as estimates to gauge what happened and what is what (disk, volume). In my mind, the combination of the translation of volume information to sector information, and the processing of data (exclusion, compression) explain the differences.

 

 

BrunoC wrote:

Going back to your TreeSize Free screenshots, I see the original size of the data as 123.2 GB. But your latest post says it's 145GB and change. Where does that 145 number come from. I'm not seeing it.

Take a look at my first screenshot of the Data to recover number.

So the question is, why does ATI say in the recovery tab that 59.2 was backed up. I didn't see an answer to a prior question... what is the size of the actual .tibx file? If the file is about 39 GB, then the problem may be merely in the reporting. If the file is about 59 GB, then we have to wonder what's there.

See the screenshot below of the tibx properties:

Since My Backups folder does not even show up on the restored image TreeSize Free list, that would be the place I'd look. Why did the folder not get restored, even if empty? Are you able to explore the backup file to check for that folder contents?

The folder was restored, it is the third folder listed and shows 0 in size.

 

Bobbo_3C0X1 wrote:

As far as I can tell, it restored all of the actual data correctly when looking at the TreeSize comparison, assuming everything in the "My Backups" folder was .tib / .tibx files and completely excluded - the resulting drive has nearly the same size as the original.

The only files in the My Backups folder are .tib.

So yeah, where is the 58.9GB calculated?  I believe I've seen this question from other users in previous forums.  The best I can tell, is that it's calculating more data based on other excluded files (maybe system volume information or recycle bin, or pagefile) in that number, even though it's really being excluded in the backup. 

System volume information is accounted for in both TreeSize views.  There is no recycle bin on this drive and as for pagefile I believe that hidden system file is always found on the system drive.

Or, another thought... junction points.  If this is the physical disk (which by the looks of treesize, it is), then all physical data on it will be backed up and restored.  However, if there are junction points where it appears to Windows and/or Acronis that the data is larger, but the physical data actually lives somewhere else because of a junction point that makes it appear to the OS or the application that it would be on the disk, that could explain the calculation difference versus the actual physical data difference.  

The source drive in question here is a physical drive.  Junction points are used on the C: system drive to direct data to the drive in question here but bear no impact on what appears on this disk.

Acronis shows that 59.2GB was backed up, but how big was the actual .tib file in the end when viewed in file explorer too.  Is it larger than 39GB or smaller?  I would expect it to be smaller than 39GB since compression would shrink it more.  If it is the same size or larger, that adds to the mystery.

Answered in my response to Bruno.

 

Pat,

Thanks for your input.  I am thinking that these numbers being estimates is what we see here as the correct answer.

I check properties of the source drive used to make the backup file.  It shows 123GB and includes the My Backup folder of 85GB.  So total data backed up as shown in ATI of 59.2GB is correct as the files in My Backup folder are excluded from the backup.

What I do not understand is how does ATI estimate the total data to recover at such an inflated number?  Where is it drawing this information from? 

Enchantech,

Thanks for correcting me. I had my retina spot welded two days ago so I'm not seeing things as easily as I should.

You said in the previous port:
" It shows 123GB and includes the My Backup folder of 85GB.  So total data backed up as shown in ATI of 59.2GB is correct as the files in My Backup folder are excluded from the backup. "

Why is 59.2 correct (123-85=38)?

I think I am now as confused as you. But it seems to be more than an estimating issue since the actual .tibx file is 59.1GB. Why did ATI think there was 145GB when the drive only shows 123GB? Could something have been detected and backed up twice? Have you run a file system check on the source drive?

OK, I tried to test too.  I took a 2019 full image and restored it to drive #1.  I then backed that drive up in 2020 and restored it to drive #2.  I compared the information in the activity screen, the size restored, and the backup file sizes.

What I noticed, is that 2019 and 2020 show a different backup size.  2019 shows the amount on disk, but 2020 seems to show the size of the .tib (at least in my test).  Other than that, the "data to recover" and the actual recovered data end up being about the same.  

Attachment Size
511661-172066.JPG 225.38 KB
511661-172069.JPG 131.13 KB
511661-172072.JPG 302.71 KB
511661-172075.JPG 207.84 KB
511661-172083.JPG 249.8 KB
BrunoC wrote:

Enchantech,

Thanks for correcting me. I had my retina spot welded two days ago so I'm not seeing things as easily as I should.

You said in the previous port:
" It shows 123GB and includes the My Backup folder of 85GB.  So total data backed up as shown in ATI of 59.2GB is correct as the files in My Backup folder are excluded from the backup. "

What I meant here is not that 123GB less the 85GB backup folder was correct but rather the total data to recover number of 145 less the 85GB backup folder equaled the 60GB (59.2) as correct.

Why is 59.2 correct (123-85=38)?

I think I am now as confused as you. But it seems to be more than an estimating issue since the actual .tibx file is 59.1GB. Why did ATI think there was 145GB when the drive only shows 123GB? Could something have been detected and backed up twice? Have you run a file system check on the source drive?

I am not sure why ATI thought there was 145GB of data on the drive.  That's the mystery.  As I replied to Pat L. What I do not understand is how does ATI estimate the total data to recover at such an inflated number?  Where is it drawing this information from?  The rest of the numbers are explainable I believe but I cannot figure out the 145GB number. 

Rob,

Thanks for testing.  Your results make sense to me and are what I would expect to see from a full OS disk backup. There are definitely differences between TI 2019 and 2020 in the estimated size of data to recover.  In your case this difference was the opposite of what I got as your total data to recover number for 2020 is less than reported by 2019 and by only a 3GB margin.  

So my question remains, why is there such a big difference in what I see when backing up a none OS disk, that has a backup folder with .tib files that are excluded by default. between the actual size of data on disk and the data to recover reported by ATI?   Where is all this extra data?  What is the application looking at?  

I wonder if it's possible that ATI, in calculating the total data to recover number, is including the default exclusion files types and the size of the VSS snapshot of the backup taken before the actual backup runs?  This possibility is the only one that makes sense to me.  

Enchantech, I'm not sure.  Mathematically, the amount backed up is correct. 

Your drive has roughly 146GB of data on it.  85GB of that is Acronis backups which will be excluded and that leaves about 61GB of data to backup.  Your backup shows 59.2GB was backed up that is in the ballpark of 61GB, plus that's also the size of the .tibx file that was created.  

So why is only 39.4GB actually recovered?  No idea, but the recovered data seems to be on point with what should be there with the side-by-side of treesize on the original and the recovered disk.

Either Acronis has a calculating error, or there is something else on the disk that we're not seeing.  Maybe a hidden system folder that has more data that we can't see - I don't know.  Very strange indeed. Is that drive being used for anything else that might be getting calculated, but really not being backed up, or something that would be excluded during the recovery process.  Even though these don't make sense, since they should be excluded in the backup already, I'm thinking of things like  

-system protection / restore points

- recycle bin

Or again, maybe some unseen folder because it has hidden and/or system attributes assigned to it.

Hopefully Acronis can weigh in on this.

Rob,

I do not believe there are any hidden folders on the disk.  Earlier today in reply to a post in another thread here on the Forum I ran from a command prompt a defrag analysis on this drive.  The results appear below.  As you can see total volume (disk) size is 465.63 GB, free space is 342.9 GB so

(465.63 - 342.09 = 123.54) which is inline with what we see in treesize, explorer, and TI as well.  How we get to 145 GB and change is still a mystery.  In my last post I speculated that possibly the VSS snapshot of the data on disk was being included in the total data to recover calculation.  I am going to withdraw that at this time due to the fact that I have minimum space allocated on this volume for restore points (320MB).  This is confirmed by the defrag output below as well (342.09 - 338.63 = 3.46),

Since I run mostly SSD's I do not defragment my drives instead, I use PS optimze to run trim on them.

Syntax (Optimize-Volume -DriveLetter YourDriveLetter: -ReTrim -Verbose)

 

Microsoft Windows [Version 10.0.18362.295]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>defrag /a f:
Microsoft Drive Optimizer
Copyright (c) Microsoft Corp.

Invoking analysis on App & User Data (F:)...

The operation completed successfully.

Post Defragmentation Report:

        Volume Information:
                Volume size                 = 465.63 GB
                Free space                  = 342.09 GB
                Total fragmented space      = 0%
                Largest free space size     = 338.63 GB

        Note: File fragments larger than 64MB are not included in the fragmentation statistics.

        You do not need to defragment this volume.

C:\WINDOWS\system32>

This is leading me to think it's a calculation error then.  Based on this info..

465-342 = 123.  

123 - 85 (excluded .tib / .tibx files) = 38 GB

You recovered 39.2 GB which is almost exact - we can probably give a little leeway for the 1.2GB based on any differences that have occurred since the backup and recovery test.

Yep, I agree.  I have contacted support on this.

I've been trying to follow recent part of this thread relating to backup sizes.  I've followed; not understood.  But  I have my own bit of confusion to add.

During the Beta test I ran a series of backups of my C: drive on my test PC at irregular intervals.  The showed different amounts of data to recover, but the amount could reflect changes so today I ran 2 backupsa couple minutes apart.

C: backup #1 (to a local drive) at 12:32- 94GB
C: backup #2 (to a NAS) at 12:34 - 82.6GB data to recover

These backups were defined with the default exclusions.  There was certainly a small change between the backups - changes to ATI's database if nothing else, but almost certainly not 11.4GB of changes.  But I noticed the there was a large difference in the size of the last full backup.

#1 - 115.1GB to recover
#2 - 83.8GB to recover

I have not tried doing a recovery but am reasonably certain the product will recover the same data.  But perhaps ATI incorrectly computes the amount to recover based on however it handles the processing of full and incr files.  (Just a guess, of course.)

 

Hi Patrick,

Yes the Data to recover numbers are off for whatever reason.  Recovery does restore all data so that is not a concern. 

For me it is more of a curiosity/mystery than anything else and I love a mystery! 

Hopefully support can tell me what's up with this.

Thanks for giving it a go as your experience does reproduce my result.

Enchantech, I just learned there has been a calculating size error in Windows 10 since 1803 that is impacting a lot of people and it's still present in 1809.

Maybe this is throwing off ATI 2020 calculations as a result too? Not sure, but since other people have been questioning some oh their backup information too, wanted to point out some references.

https://www.pocnetwork.net/technology-news/windows-10-reporting-incorrect-directory-and-file-sizes/

https://appuals.com/how-to-fix-folder-size-issues-on-windows-10/

https://answers.microsoft.com/en-us/windows/forum/windows_10-files/wrong-calculation-of-folder-size-by-windows/2da61a1b-d2fd-472a-ae12-a17a4cc8f7e2

https://www.reddit.com/r/Windows10/comments/a4mmac/folder_sizes_still_incorrect_with_1809_build/

Thanks Rob, the most interesting was reddit.  I do see users folders such as appdata, local, etc. that contain these long file names.  None of those folders exist to my knowledge in my test data but I am going looking trust me!

I downloaded a utility that will discover long paths. I did find several on the source drive of the backup task.  I have since deleted all but 2 of them.  We'll see what happens now.

Just tested with update release 1 (2020 build 21400) - validation still validates all chains in the backup task and doubles the validation time with each subsequent full.  This is no good as anyone running validation as part of their backup task is going to see the performance decrease (greatly increased validation time), the more chains they retain.  

I still don't believe this is working as intended as was noted above. When testing validation in Acronis Backup 12.5 (also using .tibx format), Acronis Backup 12.5 only validates the current backup chain and works as intended - so why is the behavior different for .tibx in Acronis True Image 2020? 

Ekaterina schrieb:

Hallo, alle miteinander,

Der Validierungsalgorithmus wurde in Acronis True Image 2020 (für den neuen Archivtyp) geändert. Die Änderungen ermöglichten eine Verbesserung der Stabilität des Features, führten jedoch auch zu einer Verlängerung der Zeit. 

Tag Ekaterina, 

Heisst dass nun Ati erwartet von uns Kunden, dass wir die Validierung so genehmigen ?  Oder gleich dass Feature Deaktivieren sollten. 

Does 2020 do a validation before every recovery? I used to keep two chains of a full plus six incrementals a week to easily grab work from a few days earlier. It only took a minute to grab a file or two.

I set up a new plan to do this under 2020 and the time to grab a file increased to hours, making 2020 unsuitable for this purpose. This particular backup is about 90GB, but the incrementals are rarely over 2GB. My large backups tend to be in the 700GB range.

Also, I notice that Acronis products don't use more than one processor. It's very frustrating to watch 7% CPU utilization and 9% disk utilization while waiting to continue my work. This is all on an extremely fast Intel 750 SSD. A newer Samsung 970 EVO is slightly slower at random access, and the machine is ten cores @ 4.3GHz.

- Ken

K1EA wrote:

Also, I notice that Acronis products don't use more than one processor. It's very frustrating to watch 7% CPU utilization and 9% disk utilization while waiting to continue my work. This is all on an extremely fast Intel 750 SSD. A newer Samsung 970 EVO is slightly slower at random access, and the machine is ten cores @ 4.3GHz.

I don't have any visibility into the internal workings of ATI, but I would expect most of the backup and recovery activity to be pretty much single-threaded - read data, compress/uncompress, write data.  Having multiple cores doesn't provide any benefit unless there can be multiple threads processing simultaneously.

KTEA,

I tested CPU utilization a short time back on TI 2020 and found that it used all cores on a quad core Intel CPU.  I notice you say you have 10 cores, AMD I suspect?

If you can show that the app is not utilizing the CPU on an AMD platform I am confident the developers of TI would be very interested in that and would investigate why.

If you can supply such documentation of the issue with screenshots of Task Manager - Performance as I have in the screenshot below that would be very advantageous.  If you are able to do this I suggest using the in app Feedback option to notify Support of the issue and include your screenshot with that feedback.

CPU Utilization

I have found that the amount of time it takes to validate a full backup file in TI2020 is 2 - 3 times longer than the amount of time it took to create the backup file.

Peter

Peter,

Please create a new thread for your issue.  It will get a lot more attention from others that way.

SSD to Slow disk ca / ca 120GB system disk Incremental (New set all 5 jobs) / VALIDATION enableb ( :( :( :( )

30/8 Full Job without Val => 26min

1/9 First Inc with Val => Inc = 1'   Full with Val = 26'

30/9 last Inc from the current set => Inc 1' Full with Val = 98'

I have 4 different backup job / day. This piece of software (Bullshit) is really stressing. For ex. Managing start's times, after some time the end from a backup eat the star time from follower... :(

Is really not a solution that allow validation from ONLY  a "full backup set" ?

Sorry for my englisch writing

 

Disco

 

 

Yeah, this is ridiculous. NVMe backs up 150GB in 4 minutes; 4 hours and 56 minutes to validate.  I think I'm going to AOMEI Backupper.... The notion that a user's time is worthless should not be a business model.  Dump the chumps !

frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 250
Comments: 7092

Hello Everyone,

if you notice an enormous increase in time needed for validation, please send us Acronis system info from the affected PC via the Feedback option. After having sent the feedback, please leave a comment here. so that I can find your diagnostic information in our system and attach to the related ticket. Thank you! 

Ekaterina wrote:

Hello Everyone,

if you notice an enormous increase in time needed for validation, please send us Acronis system info from the affected PC via the Feedback option. After having sent the feedback, please leave a comment here. so that I can find your diagnostic information in our system and attach to the related ticket. Thank you! 

Hello Ekaterina, I just sent feedback with a system report from a brand new backup that had 3 fulls in the chain.  As mentioned earlier in the thread, each new full in the backup task, when validated, increases the validation exponentially and the time required to validate when more fulls are created (and not cleaned up) will continue to grow longer and longer.  Here are the results from a brand new backup task that uses differential scheme (although it doesn't matter if it is differential, incremental or full only - the behavior is repeatable in all cases).  In this case.  I retain 3 chains, with 1 full and 2 differentials in each chain.  After each full, I run a validation (to save time as each validation for differentials is also impacted by this, but expected to during a chain validation). 

Just using the fulls though, it is easy to see how the time multiples after each backup is run against the full and then immediately validated.  This is really a grueling process now as the full backup takes only about 8 minutes each time, but the validation then takes much, much more time than the actual backup.

Original full validation #1

10/15/2019 5:25:10 PM: -----

10/15/2019 5:25:10 PM: ATI Demon started. Version: 24.4.1.21400.

10/15/2019 5:25:10 PM: Operation Backup validation started manually.

10/15/2019 5:25:10 PM: Priority changed to Low.

10/15/2019 5:31:28 PM: Operation has succeeded.

Start: 10/15/2019 5:25:10 PM

Stop: 10/15/2019 5:31:28 PM

Total Time: 00:06:18

 

2nd full validation #2

10/15/2019 5:52:46 PM: -----

10/15/2019 5:52:46 PM: ATI Demon started. Version: 24.4.1.21400.

10/15/2019 5:52:46 PM: Operation Backup validation started manually.

10/15/2019 5:52:46 PM: Priority changed to Low.

10/15/2019 6:04:29 PM: Operation has succeeded.

Start: 10/15/2019 5:52:46 PM

Stop: 10/15/2019 6:04:29 PM

Total Time: 00:11:43

 

3rd full validation #3

10/15/2019 6:25:00 PM: -----

10/15/2019 6:25:00 PM: ATI Demon started. Version: 24.4.1.21400.

10/15/2019 6:25:00 PM: Operation Backup validation started manually.

10/15/2019 6:25:00 PM: Priority changed to Low.

10/15/2019 6:42:40 PM: Operation has succeeded.

Start: 10/15/2019 6:25:00 PM

Stop: 10/15/2019 6:42:40 PM

Total Time: 00:17:40

I'd also like to note, that it's odd that the validation process does not log the stop, start or total time in the activity tab, like it does for the actual backup.

My desktop PC is running Windows 10 Pro, Version 1909, 64 bit

Installed memory is 8GB; the processor is an Intel Core 2 Quad CPU Q8400 @ 2.66 GHz

Installed HDD is 1T RAID 1 array with 562GB in use

My backup device is a Synology DS216 with 3T RAID 1 HDD

The LAN cables are CAT5e, rated for gigabyte speed

The 4 port hub on my Verizon FIOS router provides gigabyte transfer speed

The Gigabyte capability is confirmed by Task Manager showing over 500MBS during an Acronis Full backup

My Acronis backup scheme is Full followed by up to 5 daily INC; save no more than 2 chains; scheduled at 1 minute after midnight

Acronis full backups of about 410 GB to 422 GB have taken between 3 hours 33 minutes and 26 hours each

Acronis Incremental backups of between about 10 GB and 20 GB have taken between 1 hour 33 minutes is some instances but as much as 7 hours 17 minutes, 8 hours 42 minutes, and 9 hours and 16 minutes 

On advice from Acronis Technical support (chat) I started a validation on 3/27/2020 in the afternoon; yesterday (3/29/2020) in the afternoon it was 83% complete and an estimate of over 10 hours remaining

Today (3/30/2020 in the afternoon) the validation has reached 85% complete with over 12 hours remaining

Scheduled backups have been missed on 3/28/2020, 2/29/2020, and 3/30/2020

I have used Task Manager and see only about 10% CPU utilization; about 400MB in use by BackupWorker and less than 5% LAN utilization

The Synology DS215 is showing about 50% CPU utilization and 48% RAM utilization

I am allowing this validation to run to completion -- it _has_ to finish some day, doesn't it?

I trust neither the % completion estimate nor the remaining time to completion estimate

I will _NEVER_ run a validation again

Additional Information to comment #82

The verification completed on 3/31/2020 at 12:18 AM

That verification began on 3/27/2020 at about 5:45 PM

The duration of the verification was more than 102 HOURS

The cumulative duration to create the backups was about 112 hours

The verification took almost as long at the time to create the backups

UNACCEPTABLE

Hallo Martin Diehl,

Welche Backupeinstellungen werden verwendet? Was wird gesichert?

Sollte ein Laufwerksbackup gemacht werden, könnte man das alte .tib Format weiterverwenden, indem man das Backupscript bearbeitet.

Die Komprimierung sollte auf "Normal" eingestellt sein (eine stärkere Komprimierung bedeutet eine längere Validierungsdauer).

https://forum.acronis.com/comment/510834#comment-510834

 

Auf dem Bild ist eine Sicherung des "Time Explorer Storages" Ordners auf ein WD MyBook NAS. (Dateibackup)

Attachment Size
533583-180892.GIF 203.48 KB

Backup Settings

 

Backup settings as I disclosed that in comment # 82

SCHEDULE

Daily

once a day at 12:01 AM

Wake up sleeping/hibernating

Prevent sleep/hibernate

Run missed operations with 15 minute delay

BACKUP SCHEME

Custom

Bckup method

Incremental

Create full version after 5 incremental versions

Store no more than 2 recent version chains

Unless there is a major flaw in Acronis 2019, I will revert to Acronis 2019

 

Hallo Martin Diehl,

ATI 2019 ist eine sehr gute Wahl, ich bin mit ATI 2019 sehr zufrieden.

I thought I'd add my 2-cents to this very long chain. I see that it is marked as "solved", but the posting marked as the solutions doesn't really seem to provide one.

I am restoring a .tibx backup to a new drive. I hadn't done this yet with this format. This backup was done as a full backup on March 1st and has had 9 incrementals since. Full backups are done monthly with daily incrementals. So, there are a total of about 40 full/incrementals in the .tibx file(s). I normally verify backups. When I went to do so this time it said the time to complete the verification was 23 hours! Being skeptical of the Acronis time estimates generally, I let it continue, but more than an hour later it still said 21 hours to go and the progress bar has only moved a fraction. I aborted the validation and just went ahead and ran the restore, fingers crossed. The restore completed in about 1/2 an hour.

I'll not be bothering with archive verifications in the future. As insurance, I've bought a new main drive for 50 bucks and if the restore fails I can always put the old drive back in -- or try restoring up to 40 previous backups in less time than it takes to verify one!

Despite all the reasons I've read in this thread as to why verification takes so long, this is unacceptable an essentially renders backup verification useless. This needs to be fixed.

It appears that the inordinate time for verification is inherent in the *.tibx architecture; in ATI 2021 it is "minimised" by allowing only the most recent chain to be validated.

frestogaslorastaswastavewroviwroclolacorashibushurutraciwrubrishabenichikucrijorejenufrilomuwrigaslowrikejawrachosleratiswurelaseriprouobrunoviswosuthitribrepakotritopislivadrauibretisetewrapenuwrapi
Posts: 250
Comments: 7092

Hello Tech OHPRS,

the validation of a .tibx archive now takes more time due to the more thorough checks it does. The reliability of this feature has been significantly improved compared to the earlier versions. You may want switching to a quick validation of the last backup slice for your regular backup routine and perform a full validation once a month.