No VOLSNAP provider (or words to that effect)
I reported a problem a couple of days ago headlined "Win 10 Application Event log: VSS event 12293 during nightly backup ..." when I was using TI 2021 to continue a thread of backups with .TIB files.
This morning, I hoped that forcing a switch to .TIBS files would clear things up.
Unfortunately, the first attempt caused the backup to abort, with an error message something like the one I used as the headline for this message. I went through the log files in "MVP Assistant" hoping to find the exact wording but didn't. I did find an error in the "backup_worker" log timed to match the failure I experienced. I've attached the entire log entry.
Looks like the .TIB process can survive the VSS problems, while .TIBX can't.
Yep. But the backups on the old thread of .tib files still works, VSS errors notwithstanding. Did another one about an hour ago, just to make sure.
All of the VSS errors in the event log are the same 12293 errors that I was seeing with the backups creating .TIB files.
I've attached a screenshot of the VSS Doctor output. You'll see that it doesn't show any concern with any of the VSS tests, but the "Event Log" entry is absolutely full of 12293 errors. (The Disk Space problem is on the Recovery Partition, which only has about 250MB remaining)
This is driving me nuts.
Bert, if the VSS Doctor report is clean without any issues being shown, then the further options are:
Try deselecting individual partitions such as the Recovery one and running the task without this to see if the same issue is given?
Open a Support case direct with Acronis Support and let them investigate why this snapshot issue is only being shown for .tibx backup tasks, not for .tib ones?
The VSS 12293 errors each mention a specific drive, but all 3 logical drives show up in them. In TI backup source configuration, I used the "full partition list" to exclude all but the actual data partitions (which might not be a good idea).
So, I'm reduced to trying one logical drive at a time. It's worth a try.
Bert wrote:.... I'm reduced to trying one logical drive at a time. It's worth a try.
I have been having similar problems in Win 7 where .tib on 2019 seemed to work, when .tibx on 2020 does not.
However I only just discovered the Validation function and found that every single stored .tib backup failed Validation. If you haven't, I would suggest running Validation on your .tib files.
I tried a separate single disk in my server and .tib backups did Validate, but there were still a range of VSS errors in Event Viewer, so I am still not sure if they are reliable.
The other thing I just found was that the various Acronis processes use a lot of CPU % and I observed a very high temp increase due to this, with longer (1.2TB) backups failing at 100C core temp when shorter (100GB) backups did not.
I hope this helps but feel free to ignore if this is not relevant.
Bert wrote:...
So, I'm reduced to trying one logical drive at a time. It's worth a try.
I just did a backup of the C:, D:, and E: drives individually. The D: and E: backups to the .TIBX format worked perfectly, while the attempt to back up the C: drive failed immediately.
The C: drive is GPT, while the D/E drive is MBR. The C: drive came that way from the factory, while the D/E drive is left over from my old Windows 7 machine. Don't know if this is a factor, or if the C: drive itself is somehow corrupted, somewhere.
I sent a support request to Acronis.
Bert, whether the drive is GPT or MBR should not make any difference here, I have both types in my own PC and the backups are fine.
Steve Smith wrote:Bert, whether the drive is GPT or MBR should not make any difference here, I have both types in my own PC and the backups are fine.
+1
It suggests that there is a problem with the HDD/SSD, possibly on one of the hidden partitions - I had that happen once, and running chkdsk on each partition solved the problem - rather than assign drive letters to the hidden partitions I used MVP Tool - CUSTOM ATI WINPE BUILDER recovery media, which assigns drive letters to these partitions, opened command prompt and ran chkdsk with the appropriate parameters on each partition.
Ian
IanL-S wrote:rather than assign drive letters to the hidden partitions I used MVP Tool - CUSTOM ATI WINPE BUILDER recovery media, which assigns drive letters to these partitions, opened command prompt and ran chkdsk with the appropriate parameters on each partition.Ian
Well, I made a bootable USB drive, fired it up and tried every selection I could find, and none offered me the option of assigning drive letters to the extra partitions, except for the one little 9MB piece at the end that's not allocated.
The 4 others, unnamed EFI System Partition, "DELLSUPPORT", "Image" and "WINRETOOLS," were nowhere to be seen. Could the fact that these partitions can't be manipulated at all through Disk Management be the culprit?
Or have I simply missed something important?
I was able to assign drive letters by using "mountvol."
CHKDSK /R on all 4 partitions showed no logical or physical problems.
I may have found the solution to this problem, which was described in detail in KB 63024, which the "The operation was terminated because no Volsnap driver was found." points to directly. I never saw the link because my backups are all done at night when I'm not around and I only spotted the error message by accident because I was using another PC about 6 feet away when this backup ran.
Anyway, the fix is to put back an entry in a registry key which apparently got deleted by some other application, possibly Kaspersky's AV program. The registry key and what needs to be replaced is described in the KB.
I've sent this off to the tech who's been working on my TIBX problem. I could easily fix the missing data in the registry, but if there's something else going on, I don't want to screw up their work.
Hoping to get a response this week, and hopeful that it fixes the problem (by the way, "System Restore" on Windows 10 also doesn't work when this registry key is corrupted).
I have a similar problem which started in this thread...
https://forum.acronis.com/forum/acronis-true-image-2020-forum/2019-2020…
...which transferred to Tech support who tried to implement KB 63024, but it did not fix the problem and crashed my PC. Fortunately it was recoverable, if somewhat heart stopping, so do beware.
Check out the helpful comment in my thread, which included how to find related VSS problems in "Event-Viewer". This enabled Tech support to agree the above KB and others were incorrect, but the Viewer did help point to other problems (StableBit DrivePool not supporting VSS) that have made the situation a little less bad. What I did discover is the Validate facility which to my shock determined that EVERY single backup I had made was faulty.
I have reverted to 2019 which runs OK now, although Validate take extraordinary time to complete even a 10min backup, so I have asked for my 2020 Subscription to be terminated and asked for a refund.
Wow. Thanks for the warning and the information.
I suppose the tech who's been working on my problem knows about what you just said, which is why it wasn't offered as the immediate fix to my problem.
I'll take a look at your thread and try to match it up with my problems.
I didn't have to back up to TI 2019 since I'm still able to make TIB backups with 2021. Not the best situation, but it keeps things running.