"Unable to create volume snapshot" error (and others)
Having worked many times in the past I'm getting the following errors today. The backup appears to run to the end (the .tib file is created) but then this error occurs and the .tib file is deleted and the backup job restarts.
Anyone have any ideas why it's started to fail?
2021-02-06T14:34:06:282+00:00 4032 I000101F8: Pending operation 173 started: 'Creating partition image'.
2021-02-06T14:34:08:406+00:00 30832 I00640000: Writing full version to file: PC1_full_b1_s1_v1.tib
2021-02-06T14:34:08:977+00:00 4032 I000101F8: Pending operation 173 started: 'Creating partition image'.
2021-02-06T16:13:50:494+00:00 4032 I000101F8: Pending operation 173 started: 'Creating partition image'.
2021-02-06T16:13:58:489+00:00 4032 I000101F8: Pending operation 173 started: 'Creating partition image'.
2021-02-06T16:15:46:315+00:00 4032 I000101F8: Pending operation 173 started: 'Creating partition image'.
2021-02-06T16:15:54:984+00:00 4032 I000101F8: Pending operation 173 started: 'Creating partition image'.
2021-02-06T16:16:01:309+00:00 4032 E000101F6: Error 0x101f6: Unable to create volume snapshot
| trace level: error
| line: 0x65b5eb7011094703
| file: c:\bs_hudson\workspace\790\processor\diskadm\da_commit.cpp:348
| function: DaProcessor::CommitImpl::OnDaError
| line: 0x65b5eb7011094703, c:\bs_hudson\workspace\790\processor\diskadm\da_commit.cpp:348, DaProcessor::CommitImpl::OnDaError
| $module: ti_demon_vs_17750
|
| error 0x70021: Unable to create volume snapshot
| line: 0xa5695862aaf8e69c
| file: c:\bs_hudson\workspace\790\core\resizer\backup\backup.cpp:831
| function: resizer::BackupImageBuilderImp::DoCommit
| line: 0xa5695862aaf8e69c, c:\bs_hudson\workspace\790\core\resizer\backup\backup.cpp:831, resizer::BackupImageBuilderImp::DoCommit
| $module: ti_demon_vs_17750
|
| error 0x10c449: Failed to lock the volume snapshot.
| line: 0x3fec04e376b8a236
| file: c:\bs_hudson\workspace\790\core\fdisk\win_snapshot.cpp:1344
| function: win_snapshot_core::CallSbLock
| line: 0x3fec04e376b8a236, c:\bs_hudson\workspace\790\core\fdisk\win_snapshot.cpp:1344, win_snapshot_core::CallSbLock
| $module: ti_demon_vs_17750
|
| error 0x9: Unknown status.
| line: 0x2aacb7b2ab852ac
| file: c:\bs_hudson\workspace\790\core\fdisk\ver2\arch\windows\win_errors.cpp:40
| function: Fdisk::AddKstatusError
| line: 0x2aacb7b2ab852ac, c:\bs_hudson\workspace\790\core\fdisk\ver2\arch\windows\win_errors.cpp:40, Fdisk::AddKstatusError
| code: 0x13
| $module: ti_demon_vs_17750
|
| error 0xfff0: The media is write protected
| line: 0xbd28fdbd64edb8f1
| file: c:\bs_hudson\workspace\790\core\common\error.cpp:307
| function: Common::Error::AddWindowsError
| line: 0xbd28fdbd64edb8f1, c:\bs_hudson\workspace\790\core\common\error.cpp:307, Common::Error::AddWindowsError
| code: 0x80070013
| $module: ti_demon_vs_17750
2021-02-06T16:16:01:485+00:00 4032 E013C0005: Error 0x13c0005: Operation has completed with errors.
| trace level: error
| line: 0x9f2c53c72e8bcec0
| file: c:\bs_hudson\workspace\790\products\imager\demon\main.cpp:714
| function: main
| line: 0x9f2c53c72e8bcec0, c:\bs_hudson\workspace\790\products\imager\demon\main.cpp:714, main
| $module: ti_demon_vs_17750
Andrew, it looks like there are 5 (or more) partitions on the disk(s) you have selected. The first one has taken 1 hour 40 minutes to complete, the next three go quickly and the last one errors.
So do what Steve suggests, but also consider creating separate backup tasks for each disk if this backup task includes more than one disk. This would allow you to see which disk is problematic. If you can nail down the disk, the next step may be to determine which partition causes the error.
BrunoC wrote:Andrew, it looks like there are 5 (or more) partitions on the disk(s) you have selected. The first one has taken 1 hour 40 minutes to complete, the next three go quickly and the last one errors.
So do what Steve suggests, but also consider creating separate backup tasks for each disk if this backup task includes more than one disk. This would allow you to see which disk is problematic. If you can nail down the disk, the next step may be to determine which partition causes the error.
Yes, it has a single 1Tb SSD, here is the view from Disk Manager. One main partition and others created by the Dell recovery apps I assume? What's mystified me is that the backup used to run successfully and I've not knowingly changed anything (although who knows what the Dell updates do).
Steve Smith wrote:Andrew, welcome to these public User Forums.
Two initial suggestions:
- Do a restart of Windows on the PC where ATI is running and the Source data is located. This can often clean up any issues causing VSS snapshot errors.
- Download a copy of the Acronis VSS Doctor tool after doing step 1. then see if this reports any VSS error conditions. If errors are reported, allow the tool to fix any that it offers to do so for you.
If you are still seeing issues after doing the above, then more information is needed about the backup task here? What are you backing up here, how many disks / partitions in the backup source, what size of data is involved and how much free space is available on the source disk drive?
I've restarted multiple times without success. The backup had the source set to "Whole PC" which I assume backs up the main drive C:\ and all the other partitions (see comment below with image of all the partitions as viewed from Disk Manager). I'm just trying a "Files" only backup of just drive C:\. I'll let you know what happens and then give the VSS Doctor tool a go.
Andrew, do you only have the one disk drive installed in this PC?
If yes, then Entire PC will capture the contents of just that one disk drive & all partitions, however, if you have more than one disk drive, then it will include all disks & all partitions!
Please be aware that a Files & Folders backup of drive C: will never be usable to recover your Windows OS and applications! You will always need a Disks & Partitions backup for OS recovery due to all the locked data and registry information etc needed.
The approach that I would recommend after running the VSS Doctor, is to try creating Disk & Partition backups of each partition one at a time and see if the error can be isolated to a single partition, then you can make a more informed decision about the next steps that may be needed!
Steve Smith wrote:Andrew, do you only have the one disk drive installed in this PC?
If yes, then Entire PC will capture the contents of just that one disk drive & all partitions, however, if you have more than one disk drive, then it will include all disks & all partitions!
Please be aware that a Files & Folders backup of drive C: will never be usable to recover your Windows OS and applications! You will always need a Disks & Partitions backup for OS recovery due to all the locked data and registry information etc needed.
The approach that I would recommend after running the VSS Doctor, is to try creating Disk & Partition backups of each partition one at a time and see if the error can be isolated to a single partition, then you can make a more informed decision about the next steps that may be needed!
There is only one 1Tb SSD with a single user partition - drive C:\ (although the other partitions are created by the Dell system recovery tools). I succeeded with a backup of the files on C:\ using the "Files and folders" method rather than "Entire PC". After that I tried a backup with "Entire PC" and it failed again. It tends to suggest the problem is with one of the backup partitions Dell seem to create.
I ran VSS Doctor and I've attached the report.
Looking through the report there is one oddity...the "disk" called
C:\ProgramData\Microsoft\Windows\Containers\BaseImages\e6f22d72-aa00-4e5b-a396-6224b212e7f1\BaseLayer\
I think this is a file created by Windows Sandbox.
Do you spot clues in the report?
Andrew, getting back to what Steve suggested... try creating backups of the individual partitions on your drive as it appears that only one partition is failing. Use the Disk/Partitions backup method where you can individually select partitions.
Since the C: partition backup seemed to work in the original log, just run a backup of each of the other four smaller partitions, one at a time. Hopefully that will tell you where the failure is.
Looking at the VSS report, the two partitions listed at the end of the disk... 12.83 GB and 1.07 GB show space below minimum.
I also see at the end of the report some event errors related to HardDisk2, which I suspect may what looks like a 4TB D: drive you seem have online when running the report. There is one controller error on HardDisk1 (C: drive) but that may not be serious.
Andrew, thank you for the copy of the VSS Doctor output text, and the final section of this is where you need to be focussing here, as I would be concerned at seeing some of the entries being reported there from the System Event log. Please follow the Google links provided in the output text which should point you in the correct direction, but also check what hardware diagnostics are available to test the hardware elements being highlighted!
Event Log Status: Warn Description: Some VSS-related errors or warnings occurred during the previous day Events: Timestamp: 08/02/2021 16:04:31 Type: Error Source: disk Message: The driver detected a controller error on \Device\Harddisk1\DR10. InstanceId: -1073479669 SearchLink: https://www.google.com/#newwindow=1&q=disk+event+id+3221487627 Timestamp: 08/02/2021 14:44:16 Type: Warning Source: disk Message: An error was detected on device \Device\Harddisk2\DR5 during a paging operation. InstanceId: -2147221453 SearchLink: https://www.google.com/#newwindow=1&q=disk+event+id+2147745843 Timestamp: 08/02/2021 14:12:29 Type: Error Source: disk Message: The driver detected a controller error on \Device\Harddisk2\DR5. InstanceId: -1073479669 SearchLink: https://www.google.com/#newwindow=1&q=disk+event+id+3221487627 Timestamp: 08/02/2021 08:08:35 Type: Error Source: disk Message: The IO operation at logical block address 0x100 for Disk 2 (PDO name: \Device\0000014a) failed due to a hardware error. InstanceId: -1073479526 SearchLink: https://www.google.com/#newwindow=1&q=disk+event+id+3221487770
Note: I have omitted duplicate entries in the above data.
BrunoC wrote:Looking at the VSS report, the two partitions listed at the end of the disk... 12.83 GB and 1.07 GB show space below minimum.
I also see at the end of the report some event errors related to HardDisk2, which I suspect may what looks like a 4TB D: drive you seem have online when running the report. There is one controller error on HardDisk1 (C: drive) but that may not be serious.
Those are Dell recovery partitions (not mapped to a drive letter) so I can't alter the space on them. Strangely many backups have worked on this machine in the past with (presumably) the same partition structure. I've certainly not changed them myself. Perhaps the Dell updates have increased the amount of data in these partitions?
Ok, all the partitions on Disk 0 (the 1Tb SSD) can be backed up individually. The problem is with the MSFT virtual disk. This makes some sense as I've only recently enabled the Windows Sandbox option in Windows 10. It looks like Windows Sandbox is somehow creating a file based virtual drive that is incompatible?
Anyone seen this before?
Ok, I've just come across this https://kb.acronis.com/content/63012
63012: Acronis True Image: Entire PC backup fails with "Unknown status" if Windows Sandbox is enabled
It appears to be fixed in V2020
Well done Andrew for finding the KB 63012 document about the Sandbox - I had a vague memory of something related to sandbox but couldn't remember the context! Duly bookmarked!
Wouldn't it be nice if ATI could tell what disk/partition was the problem in the error.
Another good reason not to select Entire PC as a source.
Andrew, if you are considering updating ATI because of this issue, do be sure to understand about the new .tibx format first. I expect, though, that you will just be going to a Disk/Partition backup of the main disk.
Hi Bruno, yes I upgraded to V2021 in the end and it successfully backed up the "Entire PC" to a .tibx without any issues. You are right it would be really helpful to know more information about which partition failed and on which physical, or virtual, disk that partition is on. Surely it'd be easy to add this to the logs at least?
It's also slightly crazy that V2019 deletes the .tib if one of the partitions fails. It'd make more sense if didn't delete the .tib although I gess that could lead you into a false sense of security.
I'm slightly surprised that V2021 does not list the existing .tib files as potential restoration sources.
Anyway, backing up successfully again!
Andrew Jones wrote:I'm slightly surprised that V2021 does not list the existing .tib files as potential restoration sources.
You should be able to restore from the .tib files in ATI 2021. If they are not showing up in the GUI, you may need to "Add existing backup" to bring them in.