Skip to main content

How to create a Disk backup as .tib (not .tibx)

Tutorial
Legend
Posts: 100
Comments: 21996

  1. Turn off AAP (or Pause Protection ATI 2021)
  2. Create a new ATI 2020 Disks & Partitions backup task.
  3. Do NOT run the new backup task - select to Backup later!
  4. Exit the ATI 2020 GUI.
  5. Open C:\ProgramData\Acronis\TrueImageHome\Scripts in Explorer
  6. Locate the most recent .tib.tis XML file & open in Notepad
  7. Find & Replace all occurrences of .tibx with .tib then Save the file.
    Note: Ignore the .tibx entry in the Exclusions listing (*.tibx)
    Find & Replace all occurrences of format="tibx" with format="tib"
  8. Launch the ATI 2020 GUI
  9. Turn on AAP (or Resume Protection ATI 2021) (if turned off in step 1.)
  10. Select the new backup task then click on Backup now.
  11. Open the location for the completed backup task to confirm .tib file was created.

Update: Tested above on ATI 2020 & ATI 2021 Beta and still works correctly. 

Update: Added extra Find & Replace step at step 7. to match the Powershell script attached in post here.

Further testing with a Powershell script shows that AAP only needs to be turned off for when making changes to the script .tib.tis XML file.  I will upload a Powershell script to this topic which can make the changes needed plus turn AAP off and then back on again during the process. Reverted script to let user manually control AAP due to changes coming in 2021.

3 Users found this helpful
Legend
Posts: 100
Comments: 21996

#1














Forum Hero
Posts: 70
Comments: 8341

#2

Nice find! 

Have you been able to successfully validate the backup as well?  Curious if this will make it validate only the one current chain now too or if it will still validate all of the chains.

And of course, would love to hear that an OS restore was successful too, if possible.

Legend
Posts: 100
Comments: 21996

#3

Rob, the modified .tib file fails on validation with a 'PITs' error as shown in the log below, however, the same .tib file can be mounted with no problem and the contents browsed!

24/09/2019 18:26:06 :837  -----
24/09/2019 18:26:06 :837  ATI Demon started. Version: 24.4.1.21400.
24/09/2019 18:26:06 :863  Operation Backup validation started manually.
24/09/2019 18:26:07 :306  Priority changed to Low.
24/09/2019 18:26:07 :324  Validate Backup Archive Location: S:\Steve HP\New Disk Task_full_b1_s1_v1.tib
24/09/2019 18:26:07 :325  Pending operation 4 started: 'Validate Backup Archive'.
24/09/2019 18:26:07 :446  Error 0x101f6: Error while checking the metadata integrity of points in time (PITs) in the archive.
24/09/2019 18:26:07 :471  Error 0x13c0005: Operation has completed with errors.

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

24/09/2019 18:27:23 :149  [T] build: 2685; process: 13776; 'C:\Program Files (x86)\Common Files\Acronis\TibMounter\tib_mounter_monitor.exe'
24/09/2019 18:27:23 :149  [T] 2019.09.24 17:27:23 UTC
24/09/2019 18:27:23 :149  [T] 2019.09.24 18:27:23 LOCAL
24/09/2019 18:27:23 :153  [T] vbInit status 0x0
24/09/2019 18:27:23 :162  [T] Notifier initialize status 0x00000000
24/09/2019 18:27:23 :165  [T] vbSubscribeForVolumeNotifications status 0x0 (0 ms)
24/09/2019 18:27:23 :168  [T] BusInfo: 0 devices { }
24/09/2019 18:27:23 :168  [T] vbGetBusInfo status 0x0
24/09/2019 18:27:23 :654  [T] [OnVolumeMounted]: volume N: mounted
24/09/2019 18:28:35 :187  [T] [OnVolumeMounted]: volume O: mounted
24/09/2019 18:28:36 :307  [T] [OnVolumeMounted]: volume P: mounted
24/09/2019 18:29:06 :347  [T] [OnVolumeMounted]: volume P unmounted
24/09/2019 18:29:18 :888  [T] [OnVolumeMounted]: volume O unmounted
24/09/2019 18:29:25 :391  [T] [OnVolumeMounted]: volume N unmounted

 I am unlikely to get round to testing an OS restore from the .tib file for some time though may try restoring to a spare HDD (it came from an NVMe M.2 SSD).

Legend
Posts: 100
Comments: 21996

#4

Regarding Validation:  this does not appear to be for this modified .tib file - I just tried validating a different disk backup task that was created by ATI 2019 and brought forward, and am seeing the exact same error for that task .tib files too!

24/09/2019 19:12:58 :215  -----
24/09/2019 19:12:58 :215  ATI Demon started. Version: 24.4.1.21400.
24/09/2019 19:12:58 :290  Operation Backup validation started manually.
24/09/2019 19:12:59 :209  Priority changed to Low.
24/09/2019 19:12:59 :297  Validate Backup Archive Location: S:\Steve HP\Win 10 SSD_inc_b2_s3_v1.tib
24/09/2019 19:12:59 :299  Pending operation 4 started: 'Validate Backup Archive'.
24/09/2019 19:13:43 :257  Error 0x101f6: Error while checking the metadata integrity of points in time (PITs) in the archive.
24/09/2019 19:13:43 :412  Error 0x13c0005: Operation has completed with errors.

I can't remember if I tested validating older .tib disk backups on the 20770 build of 2020 so will need to check on another laptop that still has that build installed to see if this may be a new bug introduced with 21400?

Forum Hero
Posts: 77
Comments: 6741

#5

Bei mir wurde ein "PITs" error bisher immer von fehlerhaften RAM Einstellungen (Voltage VSoc, Timings, Temperatur) oder zu wenig CPU Vcore verursacht. (unter hoher CPU Last macht der RAM dann Fehler)

 

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

For me, a "PITs" error has always been caused by faulty RAM settings (Voltage VSoc, Timings, Temperature) or too little CPU Vcore. (under high CPU load the RAM will make mistakes)

Legend
Posts: 100
Comments: 21996

#6

For me, a "PITs" error has always been caused by faulty RAM settings (Voltage VSoc, Timings, Temperature) or too little CPU Vcore. (under high CPU load the RAM will make mistakes)

Gerhard, I might agree in other circumstances but this is a new HP Omen i7 laptop and the error is only showing when validating .tib disk backups in ATI 2020.

Edit: The PITs error is thrown after only 44 seconds as shown in the log above which I would say is too quick to be a memory issue!

P.s.  Credit to one of your posts (in German) that pointed to my writing this topic for English users after following your steps!  Many thanks.

Gerhard, ich könnte unter anderen Umständen zustimmen, aber dies ist ein neuer HP Omen i7-Laptop, und der Fehler wird nur bei der Überprüfung von .tib-Festplatten-Backups in ATI 2020 angezeigt.

Ps. Dank an einen Ihrer Beiträge (auf Deutsch), der darauf hindeutete, dass ich dieses Thema für englische Benutzer geschrieben habe, nachdem ich Ihren Schritten gefolgt bin! Danke vielmals.

Forum Hero
Posts: 70
Comments: 8341

#7

I upgraded to the new version and am starting a "new" backup using differentials as I want to test the backup time and the validation time to see if it is still validating all chains or not.  I'll also be testing the "cleanup" of one of the earlier differentials with the rescue media recovery to see if it still warns of a corrupted backup if picking a later file in the backup instead of the first one... and then I'll also test bitlocker support.

Among all that, I will see if I'm getting any .pit errors while validating as well for this new backup job.  Unfortunately, I don't have any existing ones that were imported from 2019 or previous versions of 2020 to test against as well. 

Forum Star
Posts: 443
Comments: 1826

#8

What a hack Steve! Kudos as the new format has still some caveats.

Forum Hero
Posts: 70
Comments: 8341

#9

Steve, no PITS validation errors in my testing so far - do they only show up validating after making these changes for you, or on all of your validations (with the original .tibx being used).  

FYI, validation is still validating all chains in my tests and doubling the time with each new chain (if you aren't cleaning up).

Manual "cleanup versions" is working for me now and the rescue media is not complaining if I click on any of the existing files in the backup now so at least that is working better. I still can't backup my main PC with rescue media (always fails in 2020, but not 2019) and Bitlocker support was not added as was anticipated with this release :(

Legend
Posts: 100
Comments: 21996

#10

Rob, I am only seeing validation errors with .tib disk backup files and these are happening almost immediately after the validation is started, as shown by the log below:

26/09/2019 22:33:00 :363  -----
26/09/2019 22:33:00 :363  ATI Demon started. Version: 24.4.1.21400.
26/09/2019 22:33:00 :391  Operation Backup validation started manually.
26/09/2019 22:33:01 :112  Priority changed to Low.
26/09/2019 22:33:01 :196  Validate Backup Archive Location: S:\Steve HP\New Disk Task_full_b1_s1_v1.tib
26/09/2019 22:33:01 :197  Pending operation 4 started: 'Validate Backup Archive'.
26/09/2019 22:33:02 :711  Error 0x101f6: Error while checking the metadata integrity of points in time (PITs) in the archive.
26/09/2019 22:33:02 :788  Error 0x13c0005: Operation has completed with errors.

Only 1 second elasped between starting and failing validation.

Disk .tibx backups are validating without any issue!

26/09/2019 22:33:18 :144  -----
26/09/2019 22:33:18 :144  ATI Demon started. Version: 24.4.1.21400.
26/09/2019 22:33:18 :173  Operation Backup validation started manually.
26/09/2019 22:33:18 :529  Priority changed to Low.
26/09/2019 22:47:12 :050  Operation has succeeded.

Old disk .tib backups created by ATI 2019 also validate without issue in ATI 2020...

24/09/2019 20:41:48 :279  -----
24/09/2019 20:41:48 :279  ATI Demon started. Version: 24.4.1.21400.
24/09/2019 20:41:48 :353  Operation Backup validation started manually.
24/09/2019 20:41:48 :909  Operation: Validation
24/09/2019 20:41:48 :910  Priority changed to Low.
24/09/2019 20:41:48 :952  Validate Backup Archive Location: S:\Steve HP\MyBackup_full_b1_s1_v1.tib
24/09/2019 20:41:48 :955  Pending operation 4 started: 'Validate Backup Archive'.
24/09/2019 20:43:34 :068  Operation has succeeded.

Forum Star
Posts: 141
Comments: 1207

#11

I just ran an experiment and created a .tib by editing the script. I ran validation on the task and it worked fine. I then re-ran validation by invoking ATI from the Explorer context menu and it worked.

Since the backup was on my other networked PC which runs ATI 2019, I tried to run a validation just to see what happens. The error message is pictured in the attached file.

My second test was to create a Diff task and run it twice. It is creating a -0001.tib file. What I suspect may be occurring is that the file is in fact a .tibx format with a .tib extension.

Attachment Size
514725-172947.jpg 114.99 KB
Forum Star
Posts: 141
Comments: 1207

#12

I just realized that I did the substitution in the script of .tibx to .tib and that was the problem. I will rerun and see what happens.

Forum Hero
Posts: 50
Comments: 8147

#13

Can someone here explain to me why you want to break the usage of this new .tibx format?

Forum Hero
Posts: 70
Comments: 8341

#14
Enchantech wrote:

Can someone here explain to me why you want to break the usage of this new .tibx format?

I don't like the validation of all chains and think it's broken.  Until/unless the other bugs and remaining items get fixed, I don't feel like .tibx poses a strong enough benefit to lose the other features and end up with super long validation times to go with it.  

Once all the bugs and the validation is sorted out, I will be happy to transition to .tibx format. 

Forum Hero
Posts: 50
Comments: 8147

#15

Okay, if that's the case why install and use 2020 at all?  Why not just stick with the 2019 product?

Forum Hero
Posts: 70
Comments: 8341

#16

That's what I'm doing on the main PC for now , sticking with 2019.

I am using 2020 on the backup laptop for bug and feature testing to keep supporting it as much as possible though. I'd like to use 2020 on all of them, but I don't think it's ready for daily use for my main PC, especially since the rescue media isn't working on it either. I'm really trying to find fault on my rig / drive, but as 2019 works on it and the other backup products I use do too, but only 2020 is floundering, it's really looking like a 2020 issue. I haven't heard back on the feedback I sent either.

Legend
Posts: 100
Comments: 21996

#17
Enchantech wrote:

Can someone here explain to me why you want to break the usage of this new .tibx format?

Bob, the original reason was down to the bug preventing large backups from completing but that is now resolved so the process may no longer be needed.

Personally, it was just an exercise to see if it was possible but ideally, I would have preferred that Acronis offered this as a Settings option within the GUI rather than have users modify script files.

I am finding that the new .tibx files are more reliable, especially for validation, in ATI 2020.

Forum Hero
Posts: 50
Comments: 8147

#18

Rob,

I think your right that your issue with the product and the recovery media is your rig and not the application itself.  I posted a reply to you with another suggestion I have on fixing your recovery media problem HERE

Look at post #8.  I believe that the design of the 2020 product, which obviously incorporates some of the advanced features of the Acronis Backup product, mean that users have a new learning curve to master.  One of the feature requests of users in past products was better\reliable validation of backups to the point that if a backup passed validation it would indicate a high very probability that the backup would work when restored.

To achieve that I am guessing here that the use of GPT disks has proliferated the user base enough that the application may now be using the MFT and it's mirror to perform validation and to assess integrity of data prior to backup.  That would be a 2 fold approach to improving reliability.  I consider that a win and I believe there is evidence to support my guess.

I hope my suggestion in the other post fixes your issue with the rescue media.

 

Steve,

I concur with your statement " I am finding that the new .tibx files are more reliable, especially for validation, in ATI 2020." above for the reasons I stated in response to Rob.   I get your interest in seeing if script modification would do as you thought so that's fine.  I am pleased that the large backup bug was fixed in short order as it shows that Acronis is listening and striving to be the best in the market.

Thank you both for your replies.

Forum Star
Posts: 141
Comments: 1207

#19

I just reran some tests using Steve's script changes. I ran a Disk incremental backup and I ran manual validations while there was only one Full, and again when there was a second Full. The validations all succeeded and the times were close to each other so no validating older chains.

If I tried to validate the backups under ATI 2019, I got the PIT error.

If the excessive validation times for multiple chains is still an issue, then I can see using the .tib instead of .tibx for backup tasks that have multiple chains with validation desired. If this problem is fixed, then I don't see a need for the .tib format.

As for Steve's desire for an option to choose .tibx or .tib, I can see how this would be desirable and recall it was suggested during the beta phase. On the other hand, if Acronis is trying to phase out the .tib files then that process would become much harder if they actively support choosing .tib.

Does anyone know if the Files and Folders backups will also be moving to .,tibx in the future?

Legend
Posts: 100
Comments: 21996

#20

Quick update on the validation issue I was seeing for .tib files.

I updated the backup tasks that were giving me the PIT's errors on validation to force these to create a new full backup .tib file using the latest #21400 build, then ran a separate validation for the two tasks which worked successfully as expected!

An interesting aspect here is that modifying the task in the ATI GUI did not change the modifications that was made from .tibx to .tib for the task, these were retained and the new full backup was using .tib and validated fine.

27/09/2019 16:43:05 :800  -----
27/09/2019 16:43:05 :801  ATI Demon started. Version: 24.4.1.21400.
27/09/2019 16:43:05 :927  Operation Backup validation started manually.
27/09/2019 16:43:07 :002  Priority changed to Low.
27/09/2019 16:43:07 :091  Validate Backup Archive Location: S:\Steve HP\New Disk Task_full_b2_s1_v1.tib
27/09/2019 16:43:07 :094  Pending operation 4 started: 'Validate Backup Archive'.
27/09/2019 16:48:01 :355  Operation has succeeded

27/09/2019 17:09:34 :164  -----
27/09/2019 17:09:34 :164  ATI Demon started. Version: 24.4.1.21400.
27/09/2019 17:09:34 :306  Operation Backup validation started manually.
27/09/2019 17:09:35 :301  Priority changed to Low.
27/09/2019 17:09:35 :347  Validate Backup Archive Location: S:\Steve HP\Win 10 SSD_full_b3_s1_v1.tib
27/09/2019 17:09:35 :349  Pending operation 4 started: 'Validate Backup Archive'.
27/09/2019 17:14:33 :306  Operation has succeeded.

Forum Star
Posts: 141
Comments: 1207

#21

Does this imply that the validation issue was actually a problem in the creation of the full backup? Given the problems which were resolved in 21400, it might be good advice to start new chains under the latest version, regardless of the type.

Legend
Posts: 100
Comments: 21996

#22

That could be the case Bruno - the issue went away after forcing new full backups for my tasks that were failing validation previously last updated or created by #20770.

To a certain extent we still appear to be continuing the beta testing here given some of the significant issues being fixed and waiting to be fixed!

Forum Hero
Posts: 70
Comments: 8341

#23

Enchantech, I was saying I do NOT believe it is related specifically to my rig (not as far as health goes) - but possibly a conflict or incompatibility with ATI 2020.  Although I'm willing to learn the new features and requirements of 2020 (it's still using the same VSS and ADK that 2019 that my other backup products are too) , I find it EXTREMELY odd that ATI 2019, Macrium, EaseUS, Aomei and Windows Backup all have no issues backing up this computer in both the live running instance of Windows, or with their instances of offline rescue media created with the same system WinRE and the same instance of ADK 1903/1809 used to build the ATI 2020 rescue media, but only the ATI 2020 WinPE/WinRE rescue media fails on this system.

I hadn't tried with the Linux since I haven't touched it in probably 2 years now, but decided to try it and it did work.    So now I'm 100% sure it is an issue with the WinPE/WinRE version of just ATI 2020.  What specifically is causing the problem, since it apparently works on other systems, is a mystery at this point, but there is something that is triggering this in 2020 WinPE/WinRE rescue media, that doesn't exist in previous versions of True Image, Linux versions of True Image rescue media, or any of the other WinPE/WinRE backup media I also am able to successfully backup this same system with.  And that's what is frustrating the heck out of me!

I looked at the other post.  VSS doctor finds no issues.  Even so, the rescue media is relying on the OS loaded into memory (X: drive is essentially a Ramdisk with it's own instance of VSS running) so not sure if that would even apply with an offline rescue media backup because I don't think the snapshot would be taking place on the drive being asked to be backed up. 

SFC /Scannow = clean

DISM /Online /Cleanup-Image /CheckHealth = clean

VSS Doctor = clean (but probably not relevant for rescue media anyway) 

CHKDSK /F /R  C: = clean  (note that I also did chkdsk on each individual partition with AOMEI partition manager as well and no errors or issues detected either)

Long surface check in Aomei, EaseUS and Minitool (all partition tools), for full disk and individual partitions = clean

*** Offline backup with all releases of ATI 2020 using ADK 1903 WinPE and also WinRE = BAD (both ADK and WinRE ***

Offline backup with ATI 2020 Linux rescue media = Good

Offline backup with ATI 2019 17750 WinPE created with 1903 ADK and also system WinRE = Good (both)

Online backup with ATI 2019 17750 = Good

Offline backup with Macrium Reflect Home 7.2.440 WinPE created with 1809 ADK  and also system WinRE = Good

Online backup with Macrium Reflect Home 7.2.440 = Good

Offline backup with EaseUS Todo Backup Pro 11.5.0.2 WinPE created with 1903 ADK = Good

Online backup with EaseUS Todo Backup Pro 11.5.0.2 = Good

Offline backup with Aomei Backupper Pro 5.2.0 WinPE created with 1903 ADK = Good

Online backup with Aomei Backupper Pro 5.2.0 = Good

Windows 10 online backup = Good

Attachment Size
514907-173018.JPG 50.3 KB
514907-173020.JPG 565.41 KB
514907-173023.JPG 205.45 KB
514907-173025.JPG 272.74 KB
514907-173026.JPG 194.67 KB
514907-173029.JPG 137.74 KB
Forum Hero
Posts: 50
Comments: 8147

#24

Interesting results guys.  Got me to wondering so I did a test of my own.  Hope you will find it enlightening.

To begin note that the test was run on a new build I recently completed (last week).  This is a new test-bench platform for me.  The base is an ASRock Z270 SuperCarrier MB, Intel i7 7700K 4.2GHz CPU, 32GB G.Skill 3200 Trident Z ram, 2-Samsung 970 Pro 512GB  NVMe M.2 PCIe x4 Gen 3 drives in RAID 0.  Additional disks are a total of 4 SATA III SSD drives, 2 Mushkin 240GB drives and 2 Samsung QVO 1TB drives.  (Yes, it is a beast!)

After completing this build I installed Windows 10 Pro x64 and fully updated it.  I then installed ATI 2020 20770.  Once installed I created backups of the OS drive to four different local locations.  These locations are:

  1. Local drive G:, 1TB QVO, created 2 BU files, 1 compressed, 1 uncompressed.
  2. LAN drive: 4TB WD My Book USB 3.0 attached to ASUS AC-3200 router
  3. LAN NAS device: 24TB TerraMaster 4 bay w/ 4 x 6TB Seagate Ironwolf 7200rpm NAS drives
  4. LAN Server: 12TB Freenas server, ASUS ITX MB, i5 CPU, 16GB G.Skill 2400 DDR3 ram, ZFS filesystem running RAID Z.

All of these backups are 8GB in size.  Total data reports as 21.5GB.  These backups were not validated.

After reading the last posts from Bruno and Steve I decided to upgrade the ATI install on this PC to version 21400.  Had no issues in doing so.  Before the upgrade I ran a validation on each of the backups listed which total 5 backups in 4 locations.

Also note that these backups are Full non-scheduled so are one time base archives which I always create on new builds.

  • Starting with the local G: QVO drive I ran validation on the compressed backup.  The log file shows the validation began at 12:09:42 until 12:10:46 a total of 1 minute and 4 seconds. and was successful.
  • I ran validation on the LAN attached WD My Book.  The log file shows validation began at 12:14:52 until 12:18:39 a total of 3 minutes and 47 seconds and was successful.
  • I ran validation on the LAN NAS.  The log shows validation began at 12:11:19 until 12:18:39 a total of 3 minutes and 20 seconds and was successful.
  • I ran validation on the LAN Server.  The log shows validation began at 12:21:48 until 12:24:42 a total of 2 minutes and 54 seconds.
  • I ran validation on the local G: drive on the uncompressed backup file.  The log file shows validation began at 12:24:56 until 12:25:59

After upgrade to ATI version 21400 I ran validation on each of the backups above again.  A comparison of the logs showed only minor changes of 1 to 2 seconds in total time to run the validations.  All were successful and all logs read virtually identical in terms of content.

These are results indicate that performance on a single version file is very good in overall terms.  As for my LAN setup, note that I run a subnet in which there are 2 routers, 2 switches, and dual nics on 3 of my 4 wired connected PC's.  The Freenas server and the TerraMaster NAS are on an independent subnet from the rest of the LAN.  This causes a brief delay in initial connection of those devices from the PC's but does not effect actual performance.  The network backup results show how hardware makes a huge difference in performance.  Having said that the lowly WD My Book drive still performs well at just under 4 minutes for an 8GB file to be written to the device.

This test does not reflect performance of incremental nor differential backup performance but I'm sure someone else will provide that.

Forum Hero
Posts: 50
Comments: 8147

#25

Rob,

Just trying to help you narrow down your issue.  I know you know how to test things out.  Having said that it makes absolutely no sense why you have this problem and seemingly no one else does! 

I could be wrong here but I think that VSS will run on any drive where disk space is allocated for such.  In my work with VSS I have setup on my main system a minimum restore point allocation on my C: drive of 4.76GB or 1%.  Additionally I have an older SATA III HDD that I repurposed as a single large VSS disk.  I have allocated 100% of that drive which is a 1TB drive to host restore points.  This works extremely well and Windows doesn't mind at all that I have it setup this way.  VSS doctor always complains when I run it that I am low on free space but since I know why I disregard the warning.  Every so often I will delete all but a couple of the latest restore points off of the VSS disk.  I always wait until the disk is about half filled before doing so.  Since I began setting up systems this way I have not had a single VSS or restore point issue.  I think that is a good track record.

At any rate, I hope you get your issue figured out!  Your logs show issue with snapshots and data integrity.  Those are facts that cannot be ignored.  Where these problems are I have no idea but I am willing to say that even though you have success with other software and ATI versions in creating backups there is likely an underlying problem on your system.  If it were truly the 2020 application in WinPE/RE then others would be having the issue as well.

Forum Hero
Posts: 70
Comments: 8341

#26

Enchantech, I appreciate the help, I really do.  Any option that leads to an eventual solution, is a good one. 

The only place this "VSS error" exists is in the 2020 rescue media "log", so I'm still inclined to say it's not on the system itself - it says there is an integrity issue, but I have a feeling it (Acronis 2020) is causing the problem based on whatever it's checking for and it's probably not checking correctly in this particular case... which I'll admit, is probably not the most common occurence since it is only on this one machine (that I know of). 

If I can literally take 8 other backups with different products, and also check the disk integrity, OS integrity and VSS integrity with multiple other tools that say things are good, but one product (and only the current version of it, but not previous versions of it) say there is an integrity problem, I'd put money on the problem being that one product. It's not like 2020 came out the door without a bunch of bugs.  

At this point, all I can do is give the data to Acronis and let them look at it.

Forum Hero
Posts: 50
Comments: 8147

#27

Okay,  tell you what, I take the bet it is not the Acronis product and it is something on your system.  Hope you find it soon and let us all know who wins the bet. :)

Legend
Posts: 100
Comments: 21996

#28

The only place this "VSS error" exists is in the 2020 rescue media "log"

Rob, can you clarify the above statement?  Is this when creating rescue media or when using it?

I was under the impression that VSS is only relevant when working within Windows, not when booted from the rescue media?  Or does it get brought in because of WinPE?

Forum Star
Posts: 52
Comments: 1774

#29

Steve,

Understanding the use of VSS under WinPE/WinRE can be difficult. Here's some information that may help. The VSS service will NOT run under a standard WinPE. If a company needs to run VSS in WinPE they must modify the WinPE to make VSS work. I have tested to see if Acronis has done this and found that they have not. The VSS service will not run under an Acronis WinPE media made using the Advanced method building from an installed ADK. You can test this in your own media by trying to start the VSS service manually. In a command window enter the following command:

net start VSS

You will be told the service name is invalid. The VSS service is present in WinPE, but the conditions are such that it will not run and you get the "invalid" error message.

On the other hand, VSS will run in a standard WinRE. Microsoft has made WinRE more capable than WinPE. When you run the net start VSS command in WinRE you will be told the VSS service has been started successfully. It can also be stopped using the "net stop VSS" command.

That begs the question as to whether True Image is using VSS under WinPE/WinRE. It is not using VSS under WinPE because the service will not run. It's very difficult to know if the program is using VSS under WinRE. The program could be testing if VSS will start and using it if it does start. If it is being used, it would probably be stopped after it is used. That will only be a matter a second or so. I do know that when the TI GUI is running in WinRE the VSS service is stopped. I can test this using the MVP Tool because the GUI can be left running while a command window is available.

All that being said, I would be very surprised to learn that Acronis is using VSS under any circumstance in WinRE. Only Acronis can answer that question.

 

 

Forum Hero
Posts: 50
Comments: 8147

#30

Paul,

Great information, much appreciated.  I had always wondered if VSS was in use in recovery media.  I suspected not but never knew for sure and still do not but I do have a better understanding of its use in that environment now.

If VSS were in use here, would you think that the service would use any disk configured to have System Protection enabled or just any free space on any disk?

Legend
Posts: 100
Comments: 21996

#31

Paul, thanks for the good information about VSS - always something new to learn!!

Forum Star
Posts: 52
Comments: 1774

#32

Bob,

I don't know enough about VSS to answer that question.

Legend
Posts: 100
Comments: 21996

#33

I have to say that I cannot see any benefit to using VSS from the rescue media as by definition there are or should be no locked system files being backed up as already in an offline environment as far as the main Windows OS is concerned.

Forum Hero
Posts: 50
Comments: 8147

#34

Thanks Paul.

Steve, I agree that VSS would be of no use in the environment.  In Rob's example he did mention the issue he has in both WinPE and WinRE environments.  So this begs the question then what data integrity error dies the application error out on?

Not knowing how ATI is checking data to be backed up now is a huge disadvantage from a troubleshooting perspective.  Hopefully Support will be able to shed some light on the subject for Rob.

Forum Hero
Posts: 50
Comments: 8147

#35

In conjunction with the thread linked below I ran a validation on the backup scheme outlined in the thread link.  Basically a scheme of a full, 3 inc. limited to 3 chains.

Thread

After completing the above backup test I ran validation after scheduled scheme cleanup.  In watching the GUI progress indicator while the validation ran I could tell when the validation was running against a full backup and when it was running against the incremental components.  When validation would complete a full backup scan the progress indicator would flash and then flash again to run the next full scan.  I observed that behavior 4 distinct times for the longer full scans which is the number of full backups in the archive.  The archive itself contains a total of 9 backups after the cleanup.

Each full backup totals 8.7GB in total compressed sized.  If we times that by 4 (the total number of fulls) we have 34.8GB of data to validate.  The incremental backups size is small enough to be inconsequential to this discussion. 

Performance of the validation on the archive was as follows:

Validation began at 11:40:24

Validation ended at 11:45:07

Total elapsed time was 4 minutes and 43 seconds

Divide 4:43 by 4 full BU and we get 1 minute 10.75 seconds per full backup scan.

If we take 8,700 MB and divide that by 70 seconds we get 124.285 MBps.

I believe this to be an acceptable level of performance.  So even though it is obvious to me that the applications validation is still scanning all elements of the archive that scan, in my opinion, has been improved dramatically in the new version 21400 release.

Forum Hero
Posts: 70
Comments: 8341

#36
Steve Smith wrote:

The only place this "VSS error" exists is in the 2020 rescue media "log"

Rob, can you clarify the above statement?  Is this when creating rescue media or when using it?

I was under the impression that VSS is only relevant when working within Windows, not when booted from the rescue media?  Or does it get brought in because of WinPE?

Yeah, it's not specifically VSS, I guess.  The error I get is in the Acronis 2020 rescue media log under WinPE/WinRE, but refers to the snapshot state failing, which makes/made me think VSS was being used somehow, but maybe it is still relying on Snapman / Snapapi in the rescue media, I'm not sure. 

 

<event code="48" id="3" level="4" line_tag="0x1C981E20C1C9F1BB" message="The backup has been created but its data is inconsistent with the source. Backup will be automatically restarted." module="7" time="1569534503">
            <field name="$module" type="TIdentifier">disk_backup_vsa64_530</field>
            <event code="50250" id="4" level="4" line_tag="0x3FEC04E376B8A2B6" message="Failed to obtain the snapshot state." module="16" time="1569534503">
                <field name="$module" type="TIdentifier">disk_backup_vsa64_530</field>
                <event code="9" id="5" level="4" line_tag="0x2AACB7B2AB852AC" message="Already stopped." module="0" time="1569534503">

 

Actually, today, it even failed with a new error and would not back up at all with the WinPE rescue media from 2020.  

"File system error is found.  Consider checking the disk"

 

And normally, this would be a big red flag for me to run chkdsk, etc. because that is exactly what we should/would do based off this type of error.

However I've already done that - several times, with multiple tools and none of them finds an issue.  This is a Samsung 970 EVO Plus and I've just upgraded Samsung Magician to version 6.0 and ran both the short and long tests and even it says the entire disk is fine.  And Friday, I did a bunch of chkdsk and surface checks with lots of other tools, and have run SFC and DISM health checks too and all are clean - all but ATI 2020 rescue media.  And, right after I get these errors with the 2020 WinPE/WinRE rescue media, I went ahead and tried the 2020 Linxu version and it was fine, so then I did another Acronis 2019 offline WinPE backup without issue, and then followed up with another one from Amoei and another one from Macrium without issue too.

So, I really believe that 2020 has a calculation issue on what it determines to be an integrity error because either it is an amazing tool for finding these issues and outshines all the other disk checking tools that specifically do this and aren't as good, or it's another 2020 bug (which is what I believe it is since it only happens with ATI 2020 WinPE/WinRE and not ATI 2020 Linux rescue media, ATI 2019 rescue media of any kind or in Windows, as well as the same for Macrium, Aomei and EaseUS backup programs and also their disk check utilities, and also not Hard disk sentinel or Speccy either).

I'll be restoring my 2019 image back tonight because 2020 is causing other issues with all of my USB drives - identifying them as network shares with the Acronis icon too (something I've seen reported a couple of times now too).  Apparently, the 2020 install has decided that all USB drives now need to be associated with:

C:\Users\XXXXX\AppData\Roaming\Microsoft\Windows\Network Shortcuts and is preventing the drives as showing up with their real volume letter in this case too.

I really can't trust the reliability of integrity of 2020 at this time.  I really like True Image, been my bread and butter for about 6 years now; I hate to say it, but this release has started to shake my confidence in it though and I hope I can work with them to identify what is causing this behavior and help them fix it.

 

Attachment Size
515091-173112.jpg 280.62 KB
515091-173115.jpg 276.05 KB
515091-173118.jpg 401.16 KB
515091-173121.jpg 337.79 KB
515091-173122.jpg 387.43 KB
515091-173128.jpg 227.03 KB
515091-173129.jpg 351.17 KB
515091-173130.txt 1.43 KB
Forum Hero
Posts: 50
Comments: 8147

#37

I hope you find the problem Rob.  The errors reported may be wrong but there is something going on that is creating the errors that's for sure.  Like I say, I have no problem with the recovery media so for me it all works as expected.

What exactly are you backing up to anyway?  Have you tried a different target?

Legend
Posts: 100
Comments: 21996

#38

Rob, it would be interesting to see the whole offline backup log from the rescue media?

I have just booted from my MVP WinRE rescue drive and made a full backup of my internal NVMe M.2 SSD drive and just got 2 lines in the log in essence!

<?xml version="1.0" encoding="UTF-8" ?>
<log build="21400" product="Acronis True Image" task_name="My Disk Drives Backup" uuid="D9722965-00C4-475A-8861-BDF18687417F" version="24.4">
<event code="0" id="1" level="2" message="Operation 'My Disk Drives Backup' started." module="100" time="1569842347" />
<event code="252" id="2" level="2" message="Backup operation succeeded." module="100" time="1569842791" />
</log>

Looking at the Windows Task Manager when the backup was running just showed that ATI was running backup_worker.exe as the main process.  The Services showed that VSS was stopped and no Acronis services that I could identify.

Your log entry saying:  Backup will be automatically restarted. would suggest that the Acronis Scheduler service is needed to do an automatic restart of the backup?

The further log entries you share seem contradictory too.

message="Failed to obtain the snapshot state." time="1569534503"
type="TIdentifier">disk_backup_vsa64_530
message="Already stopped."  time="1569534503"

I read 'Already stopped' as referring to the prior snapshot error with both having identical time stamps.  The 'disk_backup_vsa64_530' is puzzling as it is possibly suggesting a VSS hybrid feature 'vsa64' but that is my pure speculation.  I didn't see anything like that in the task manager or services tab of same for my backup?

Forum Hero
Posts: 70
Comments: 8341

#39

Hi Steve - these are all offline backup tasks with WinPE.  The logs are very vague, to say the least.  I'm uploading the log and the disk information from the offline system report.  

For what it's worth, I'm now 1,000% sure it's an ATI 2020 issue.  I went ahead and blew away the entire drive by killing off all partitions with Minitool offline rescue media.  I then initialized it again and installed Windows 10 1903 cleanly. 

I then restored the C: partition from my just created and successful ATI 2019 offline backup over the newly created C: partition and then booted the system to make sure it was working correctly - and it was. 

Ran a quick set of tests on the drive (chkdsk /f /r C:, sfc /scannow, and a couple of surface tests again) and no issues identified as before. 

Rebooted and backed up the drive with ATI 2019 offline rescue media again without issue. 

Rebooted and attempted to backup the drive with ATI 2020 and still get the same error with a failed backup, despite the backup files actually being created. 

Nothing shows any type of drive issue or CRC error other than ATI 2020 WinPE/WinRE on this particular machine.  I would expect that after wiping the drive and running chkdsk /f /r on the recovered C: partition (with no errors reported) - that should have resolved any real consistency issues if they existed.  But also, since it's only 2020 stating there is an error, I really think it's an application issue.

 

Attachment Size
515370-173203.txt 1.43 KB
515370-173206.txt 501.34 KB
515370-173211.jpg 84.78 KB
515370-173214.jpg 93.22 KB
Legend
Posts: 100
Comments: 21996

#40

Rob, which actual Samsung 970 Evo drive letter is being backed up in your offline test here?

Does the same issue occur if you select the other Samsung 970 Evo drive?

Do you see any errors reported if backing up the same drive using the ATI 2020 app in Windows?

I am still puzzled as to why there should be any reference to snapshot in the offline logs???

Forum Hero
Posts: 70
Comments: 8341

#41

Hi Steve,  The drive being backed up is:

3-   d(6) GPT   466G NVME  0-0-0    Samsung SSD 970 EVO Plus 500GB 2B2QEXM7
                                  MBR                                ------
                                  GPTpri                             -----v
  -1       ----  529M  529M  147M NTFS   27 Windows RE H Recovery... --c--V
  -2       ----  100M  100M   70M FAT32  EF EFI          ........... --c--V
                                  MSresr                             -----v
  -4       --JE  465G  465G  375G NTFS   07 NTFS, HPFS   NVME1_500GB --c--V

I believe it was listed as E: in the rescue media.

I haven't tried backing up the other drive - it has quite a bit more data on it, but I'll do that next to compare.

No, I haven't backed up with 2020 online.  I installed it and noticed a bunch of other issues immediately (like all USB drives showing up as a network drive instead of local drives!) and immediately restored an image back to 2019 as this is my daily machine that I need to be able to reliably backup and restore.  

I may give it a go one more time just to see if I can backup with it online, or not - should be a good test and then restore back to 2019 (even if successful).  

Forum Hero
Posts: 50
Comments: 8147

#42

Rob,

I noticed that you ran chkdsk /f /r on this disk and I believe by your description it is a secondary disk?  

Since you are obviously I'd say running an NTFS filesystem have you tried running the following commands:

chkdsk X /scan

chkdsk X /spotfix

chkdsk X /sdcleanup

Where X is the drive letter?

I have found that with NTFS there are times when the /f and does not find errors that exist.  I do not run the /r on any of my SSD's as SSD's lack sectors so the command is unnecessary.  In the commands above the /scan will run a check like /f online.  The /spotfix will require a restart as will the /sdcleanup.  The /sdcleanup is of interest because it performs a garbage collection on unneeded security descriptors.  If ATI 2020 is running the metadata checks I think it is stray security descriptors just may be your issue.

 

Forum Hero
Posts: 70
Comments: 8341

#43

Steve,

OK.  Tests complete.

Yes - the secondary Samsung EVO 970 500GB drive backed up just fine with the offline WinPE rescue media (ATI 2020).  I also chose a different backup destination drive than I've been using - just in case. 

Yes - the online backup of the disk that fails in rescue media backed up just fine with ATI 2020 from Windows! 

I went back and tried an offline backup with the different destination disk and it still failed. 

So, all backups on this disk work in Windows and with offline rescue media, and pass all known disk checks with a multitude of tools... except for the ATI 2020 WinPE/WinRE rescue media.  

My best guess is the WinPe/WinRE is not successfully recognizing the disk being backed up and is crossing its wires.  I say this because this disk is the main OS drive in Windows (C: drive), but I have another same Samsung EVO 970 for my VM's that shows up in Windows as the F: drive.  In the rescue media, the secondary EVO (with my VMware files) is always listed as C: and the OS drive is always listed as E:.  I don't know, maybe True Image 2020 WinPE rescue media is somehow confusing the drives after the backup has started (like when it goes to verify the integrity at the end) and referencing the wrong C: drive in this case.  I guess I'll have to disconnect the second drive, and try one more time just to see.

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

Enchantech,

The drive is my primary OS drive (C:) in Windows - it (Samsung EVO 970 500GB) is mounted directly to the M.2 PCIe NVME slot on the motherboard.  The other Samsung EVO 970 500GB is connected to a PCI adapter .  Interestingly enough, that one is backing up fine in the WinPE ATI 2020 rescue media as noted to Steve above.

I supposed I will need to try swapping the problem drive from the mainboard to the adapter (and remove the second 970 evo)  and see if it makes a difference, but I don't think it will in either regard.

I'll get to it, just to rule it out, but this has been exhausting to trouble shoot and I'm losing interest with every new test since it's been so time consuming.

No, I had not tried those specific commands as /f /r should check everything, regardless of the file system.  The X: drive is an older MyDigital BPX PCIeNVME drive and isn't one I've tried backing up in the rescue media yet. I'm running them now, just to see, but need to reboot to complete the second command so will resport back in a bit.

So Windows ATI 2020 backups up this disk fine... but not the rescue media... really think it's the rescue media that is the problem.

Forum Hero
Posts: 70
Comments: 8341

#44

I think I found the bug! Trying to verify / validate the behavior, but looks to be identified.

I run ATI 2019 on this system, which is installed on the "problem" disk.

After upgrading to 2020 (which had a successful backup in Windows), I ran an offline backup and it worked. I believe now the issue is a compatibility problem of having 2019 installed on the disk if trying to use 2020 winpe/WinRE rescue media.

I'm restoring my image with 2019 to repeat the test (which should fail to backup with 2020 media) and if it does fail, I will upgrade to 2020 again and try one more offline backup... Which if it works then, is proof enough for me at this point. Anyone else have a system with 2019 installed who can try to take an offline backup of that disk with 2020 winpe rescue media to try and replicate?

Forum Hero
Posts: 70
Comments: 8341

#45

Verified and repeatable. ATI 2020 winpe/WinRE fails to backup w disk where ATI 2019 is installed (and not running). Likely similar for any older version on the backup disk.  

Forum Star
Posts: 141
Comments: 1207

#46

Why would the rescue media version care (or even know) what programs are on the disk that it's backing up?

Forum Hero
Posts: 70
Comments: 8341

#47

It shouldn't. I have a feeling it's more metadata being updated in the background, if True image exists on disk. And it's failing to update because 2019 is older, so it should just ignore it and not try to modify it and throw random false disk integrity errors.

Forum Star
Posts: 52
Comments: 1774

#48

I just ran the test you requested. Clean install of TI 2019 with the 2019 version of UR also installed. Backup succeeded with the Acronis Simple WinRE recovery media for TI 2020 build 21400. Validation also succeeded from the recovery media. 

I would suggest you concentrate on possible computer related issues. Here's how I would test:

1. Remove the drive and install it in another computer. See what the TI 2020 WinRE media does with it. If it still fails the same way, put the system on another disk using another backup program and try again in that computer.

2. If the backup succeeds in step 1, try to find out what is going on with the problem computer. Remove memory and retest. Replace memory with memory from another computer and retest. Re-flash the BIOS. Connect the drive to another port (use your adapter card). Try anything else you can think of with the computer configuration.

It really appears this problem is unique to that situation and not a programming bug.

Forum Member
Posts: 10
Comments: 52

#49

@Steve-

Will following your method to change from .tibx to .tib then create filenames such as what .tib used before? For example

Susan_full_b2_s1_v1.tib and Susan_inc_b2_s2_v1.tib

It's so much easier to know what's taking place with my backups using this naming scheme. The .tibx really tells me nothing unless I check the file date and happen to remember what yesterday's file size was. Per bobbo's (Rob?) suggestion in another thread, I have submitted feedback via the app on this request.

Forum Hero
Posts: 70
Comments: 8341

#50
Mustang wrote:

I just ran the test you requested. Clean install of TI 2019 with the 2019 version of UR also installed. Backup succeeded with the Acronis Simple WinRE recovery media for TI 2020 build 21400. Validation also succeeded from the recovery media. 

I would suggest you concentrate on possible computer related issues. Here's how I would test:

1. Remove the drive and install it in another computer. See what the TI 2020 WinRE media does with it. If it still fails the same way, put the system on another disk using another backup program and try again in that computer.

2. If the backup succeeds in step 1, try to find out what is going on with the problem computer. Remove memory and retest. Replace memory with memory from another computer and retest. Re-flash the BIOS. Connect the drive to another port (use your adapter card). Try anything else you can think of with the computer configuration.

It really appears this problem is unique to that situation and not a programming bug.

At this point, I'm out of gas on this and punt to Acronis to look at the logs and system reports. 

This is the only tool that fails to properly backup and/or reports any issues with the disk and can be repeated by reverting between 2019 and 2020 with the installed version of True Image. 

I don't see how simply upgrading to 2019 to 2020 in the live OS (on the same disk) would resolve a system hardware or supposed disk issue and allow the backup to complete, but reverting back to 2019 on the same disk, suddenly causes "disk integrity" errors that no other tool seems to be able to confirm. 

If there were any signs of hardware failure or issues anywhere else (Windows logs, third party disk checking tools, Windows  disk checking tools) I'd be game to keep checking, but at this point, it's a witch hunt to try and pin the problem on this drive when there are no other signs of issues and only problems with a newly released, and to be honest, fairly buggy upgrade.  The problem here is one application out of about 20 that fails, yet, the issue can be corrected simply by upgrading to ATI 2020 over 2019 on the host OS.  

Going back to what I've previously posted, ATI WinPE/WinRE 2019 backs up the disk fine and so does the Linux version and Windows version.  ATI 2020 Linux version backs up the disk fine and so does the installed version, but ATI 2020 WinPE/WinRE does not if the installed version of Acronis is 2019, but works fine if the installed version on the OS disk is 2020.  Macrium, EaseUS, Aomei and Windows backup all backup fine in Windows and associated rescue media regardless if ATI 2019 is installed or upgraded to ATI 2020.  No disk partition tools or manufacturer drive tools find any system faults either - just ATI 2020 rescue media in this one specific case.  

I've done my due diligence to try and make this work, but I'm going to be fine with not using 2020 in the long run if support can't figure it out. Unfortunately, I'm not willing to make the move to 2020 based on this type of application behavior and need to have stable backup software on this machine.  2019 is doing great, but if there's no reliable upgrade path here, at some point, I guess I move on.  Hoping that wont' need to be the case though.  ATI has been great for me for many many years and hope it could still be an option moving forward.