Skip to main content

[SOLVED] Backup job fails, cannot create Volume snapshot (fails to backup a recovery partition)

Thread needs solution

ATIH 2016 b5576

Hello I've converted a MBR Windows 10 to an UEFI schemata today. I assume, after this conversion it is not longer possible to backup the computer.
I've also tried cloning the settings and setting up the job accordingly. I am not even sure if the issue is related to the MBR / GPT conversion of the system drive.

Also setting up a complete new job fails.
Hence, executing a restore and backup via Linux Recovery UEFI works

p.s. my snapman registry hotfix was not applied on this machine

Here is the log from the notification email:

1 True Image 28.08.2015 21:27:02 Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
2 True Image 28.08.2015 21:27:02 Operation Buero 840 SSD Pro started by schedule.
3 True Image 28.08.2015 21:27:02 Operation description: Stage Description.
4 28.08.2015 21:27:02 AcronisLRPCConnect::BEGIN id=8.708
5 28.08.2015 21:27:02 AcronisLRPCConnect::BEGIN id=6.388
6 28.08.2015 21:27:02 AcronisLRPCConnect::BEGIN id=8.672
7 28.08.2015 21:27:02 Retreiving Fdisk ver1 disk set to Fdisk ver2c disk set...
8 28.08.2015 21:27:02 Fdisk2: Use Disk 1 host= 0 bus = 0 target = 0
9 28.08.2015 21:27:02 Fdisk2: Use Disk 2 host= 0 bus = 0 target = 0
10 28.08.2015 21:27:02 Refreshing Drivers...
11 28.08.2015 21:27:02 Enter to process disks in Mbr Driver (id = 9)
12 28.08.2015 21:27:02 Exit from process disks in Mbr Driver (id = 9)
13 28.08.2015 21:27:02 Enter to process disks in Gpt Driver (id = 10)
14 28.08.2015 21:27:02 Try to load Alternate Header from 250069679
15 28.08.2015 21:27:02 Gpt Disk F2D69FCE-AEE1-4185-84E7-0227B6A41E7B LBA=250069679 ALBA=1
16 28.08.2015 21:27:02 try to loading Header from 1
17 28.08.2015 21:27:02 Gpt Disk F2D69FCE-AEE1-4185-84E7-0227B6A41E7B LBA=1 ALBA=250069679
18 28.08.2015 21:27:02 Try to load Alternate Header from 250069679
19 28.08.2015 21:27:02 Gpt Disk C314B3E0-0681-43BC-B751-A719F3931FDC LBA=250069679 ALBA=1
20 28.08.2015 21:27:02 try to loading Header from 1
21 28.08.2015 21:27:02 Gpt Disk C314B3E0-0681-43BC-B751-A719F3931FDC LBA=1 ALBA=250069679
22 28.08.2015 21:27:02 Exit from process disks in Gpt Driver (id = 10)
23 28.08.2015 21:27:02 LDM: New ProcessDisks(rawLayer, headLayer)
24 28.08.2015 21:27:02 ProcessDisks: One more disk to check
25 28.08.2015 21:27:02 ProcessDisks: One more disk to check
26 28.08.2015 21:27:02 Mark All groups as Root Like Dgs
27 28.08.2015 21:27:02 ------ Volumes Objects ------
28 28.08.2015 21:27:02 LDM initialization complete
29 28.08.2015 21:27:02 Analysiere Volume '0-0'...
30 28.08.2015 21:27:02 Analysiere Volume 'B:'...
31 28.08.2015 21:27:02 Analysiere Volume '0-0'...
32 28.08.2015 21:27:03 Analysiere Volume '2-2'...
33 28.08.2015 21:27:03 Analysiere Volume 'C:'...
34 28.08.2015 21:27:03 Analysiere Volume '2-4'...
35 28.08.2015 21:27:03 Analysiere Volume 'D:'...
36 True Image 28.08.2015 21:27:03 Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
37 True Image 28.08.2015 21:27:03 Aktion: Backup
38 True Image 28.08.2015 21:27:03 Backup-Archiv erstellen Von: Laufwerk 2 In Datei: "B:\Meine Backups\Buero 840 SSD Pro.tib" Komprimierung: Normal Exclude: Durch Ausschlussmaske erfasste Dateien Passendes Kriterium: $Recycle.Bin, swapfile.sys, System Volume Information, *.tib, *.tib.metadata, *.~, *.tmp, C:\Users\Jürgen\AppData\Local\Temp, C:\Users\UpdatusUser\AppData\Local\Temp, C:\Users\Margarete\AppData\Local\Temp, C:\Users\UpdatusUser\AppData\Local\Temp, C:\Users\Laura\AppData\Local\Temp, C:\Users\UpdatusUser\AppData\Local\Temp, C:\Users\Jürgen\AppData\Local\Microsoft\Windows\Temporary Internet Files, C:\Users\UpdatusUser\AppData\Local\Microsoft\Windows\Temporary Internet Files, C:\Users\Margarete\AppData\Local\Microsoft\Windows\Temporary Internet Files, C:\Users\UpdatusUser\AppData\Local\Microsoft\Windows\Temporary Internet Files, C:\Users\Laura\AppData\Local\Microsoft\Windows\Temporary Internet Files, C:\Users\UpdatusUser\AppData\Local\Microsoft\Windows\Temporary Internet Files, C:\Users\Jürgen\AppData\Local\Google\Chrome\User Data, C:\Users\Jürgen\AppData\Local\Opera Software, C:\Users\Jürgen\AppData\Roaming\Opera\Opera, C:\Users\Jürgen\AppData\Local\Mozilla\Firefox\Profiles, C:\Users\UpdatusUser\AppData\Local\Google\Chrome\User Data, C:\Users\UpdatusUser\AppData\Local\Opera Software, C:\Users\UpdatusUser\AppData\Roaming\Opera\Opera, C:\Users\UpdatusUser\AppData\Local\Mozilla\Firefox\Profiles, C:\Users\Margarete\AppData\Local\Google\Chrome\User Data, C:\Users\Margarete\AppData\Local\Opera Software, C:\Users\Margarete\AppData\Roaming\Opera\Opera, C:\Users\Margarete\AppData\Local\Mozilla\Firefox\Profiles, C:\Users\UpdatusUser\AppData\Local\Google\Chrome\User Data, C:\Users\UpdatusUser\AppData\Local\Opera Software, C:\Users\UpdatusUser\AppData\Roaming\Opera\Opera, C:\Users\UpdatusUser\AppData\Local\Mozilla\Firefox\Profiles, C:\Users\Laura\AppData\Local\Google\Chrome\User Data, C:\Users\Laura\AppData\Local\Opera Software, C:\Users\Laura\AppData\Roaming\Opera\Opera, C:\Users\Laura\AppData\Local\Mozilla\Firefox\Profiles, C:\Users\UpdatusUser\AppData\Local\Google\Chrome\User Data, C:\Users\UpdatusUser\AppData\Local\Opera Software, C:\Users\UpdatusUser\AppData\Roaming\Opera\Opera, C:\Users\UpdatusUser\AppData\Local\Mozilla\Firefox\Profiles, C:\Documents and Settings\Jürgen\AppData\Roaming\Apple Computer\MobileSync\
39 True Image 28.08.2015 21:27:03 Pending operation 160 started: 'Volume-Image erstellen'.
40 28.08.2015 21:27:03 Partition 2-2 sperren...
41 True Image 28.08.2015 21:27:03 Schreibe differentielle Version zu Datei: Buero 840 SSD Pro_diff_b2_s6_v1.tib
42 True Image 28.08.2015 21:27:03 Pending operation 160 started: 'Volume-Image erstellen'.
43 28.08.2015 21:27:13 Partition C: sperren...
44 True Image 28.08.2015 21:29:08 Pending operation 160 started: 'Volume-Image erstellen'.
45 28.08.2015 21:29:08 Partition 2-4 sperren...
46 True Image 28.08.2015 21:29:08 Kann Volume-Snapshot nicht erstellen
47 True Image 28.08.2015 21:29:08 Kann Volume-Snapshot nicht erstellen
48 True Image 28.08.2015 21:29:08 Failed to lock the volume snapshot.
49 True Image 28.08.2015 21:29:08 Unbekannter Status.
50 True Image 28.08.2015 21:29:08 Das System kann nicht vom angegebenen Gerät lesen
51 True Image 28.08.2015 21:29:08 Kann Volume-Snapshot nicht erstellen
52 True Image 28.08.2015 21:29:08 Kann Volume-Snapshot nicht erstellen
53 True Image 28.08.2015 21:29:08 Failed to lock the volume snapshot.
54 True Image 28.08.2015 21:29:08 Unbekannter Status.
55 True Image 28.08.2015 21:29:08 Das System kann nicht vom angegebenen Gerät lesen
56 28.08.2015 21:29:08 ServerLRPC::_CloseConnection id=8.708
57 28.08.2015 21:29:08 ServerLRPC::_CloseConnection id=8.708
58 28.08.2015 21:29:08 ServerLRPC::_CloseConnection id=8.672
59 28.08.2015 21:29:08 ServerLRPC::_CloseConnection id=8.672
60 28.08.2015 21:29:08 ServerLRPC::_CloseConnection id=6.388
61 28.08.2015 21:29:08 ServerLRPC::_CloseConnection id=6.388
62 True Image 28.08.2015 21:29:08 Operation has completed with errors.

Attachment Size
screenshot_123.png 276.6 KB
systemreport.zip 4.66 MB
0 Users found this helpful

I would wish to add my dismay at this error. I simply cannot backup may systems. At the momnet 2016 is essentially useless to me. Don't think I can add any more to the above other than I hope this is fixed quickly!

What have you done before you got trapped by this issue?

Issue persists in release b5586. Need help!

@karl,

Have you tried running a repair install of TI?

I suggest deleting all the existing tasks as they will refer to your old drive formats and make new tasks for your current set up.

no haven't tried that. I really don't want to loose the backup settings. If I don't get any response from Acronis then I might choose this path as a workaround. On the other hand this issue should see a solution instead of starting at zero.

It is unclear to me why it happens at all.

Hello, Karl Heinz!
I have looked at the System Report that you have attached and it looks like the file systems on volume C: and the recovery volume are corrupted.
I would suggest repairing the file system using chkdsk.
Hopefully this will help resolve the issue.

I can understand Karl frustration . Because I am also a victim now ....

Same error ... cannot create Volume snapshot.

There is nothing to do with volume are corrupted please.... because I remove TI 2016 and put back 2015.... all backup resume successfully.

Please help asap .....

I agree that it is nothing to do with HDD file system corruption or bad sectors.

I had a similar issue with the last but one version of ATI 2015 - but in my case it was a backup to the cloud. I could do a local backup without issue. Eventually the problem went away (after several days) and the backup completed successfully. So, it looks like a bug in the code that is causing the problem.

Ian

Hello Dmitry,

thanks for your hint.

Here is what I've done:

checked all drives with chkdsk and drive B (backup target) had NTFS issues. I did repair them.
I ran the job and just selected the EFI System Volume and Windows Recovery Volume -> backup failed
I ran the job and just selected the EFI System Volume -> backup worked
I ran the job and just selected the Recovery-> backup failed.

At the moment I cannot explain at the moment why my backup target had issues, and most of all why the Windows internal recovery volume should have issues .

In normal conditions the recovery volume should never need a repair, moreover usual users won't be aware how to make it visible and repair it using diskpart.

I will carry out the repair on the recovery volume and report back.

I ran the chkdsk on the recovery volume but it did not found any issues.

Here is how to make the recovery volume visible and able to check using chkdsk:

run "cmd" as administrator
diskpart
list drive (estimate your system drive number)
select disk 0 (mostly system drive)
list partition (verify this drive contains your recovery partition... about 450 MB in Windows 10)
select partition 4(was the number of my recovery partition)
list partition (verify that you have selected the recovery partition * asterisk)
set id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 (converts hidden recovery partition to a usual primary partition)
assign letter=x (be sure to use X if it is free drive letter)

don't close this window yet

open explorer:
right click on drive X > properties > tools > check disk > run checkdisk

back to the diskpart window
remove letter=x (maintaining the correct oder is important! When you set the ID first and remove the drive letter then, this will cause the partition to reappear again every reboot)
set id=de94bba4-06d1-4d40-a16a-bfd50179d6ac override (set partition back to a hidden recovery partition)
detail partition it show be shown that the recovery partition has the ID given above and it is hidden
it does not appear anymore in the windows explorer

exit diskpart with the command(s) exit until back in CMD prompt.

Hey Karl - Good effort but as I highlighted... no need to test the drive .........

I have the same error.... put back 2015 and all will work .

So the issue is 2016 and not the drive..

Hello Dmitry I've carried out chkdsk on all drives now.
Strange enough, backup will work including the recovery partition as long the recovery parition is not hidden and has a drive letter assigned.

As soon I set the recovery partition back to defaults with no drive letter assigned the backup will fail again.

So unfortunately the issue is still not solved.

To WORKAROUND the issue I will exclude the recovery partition from the backup for the moment, but I still need solution for this problem.
It seems be a very weird one. Don't know why ATIH stresses to backup this partition on this computer, as it works perfectly fine on other computers with Windows 10 and ATIH b5586.

With the recovery partition excluded the backup ran without errors. Have the latest system report attached. I hope you can find the issue.

Attachment Size
296577-122266.zip 4.84 MB
296577-122269.png 54.44 KB

Hello Richard this is very interesting that ATIH 2015 will backup without issues. Well spotted!

Can you be bothered to upgrade to ATIH 2016 again and elaborate if your problems also exists when backing up the Windows recovery partition (Windows recovery partition != OEM recovery partition)

It would be very helpful for Acronis to know which partition is affected in your case. So try backing them up one by one until you identified the troubled partition.

For the current situation I have to agree with Ian and Richard that there is still an issue with the code, although in the changelog for b5586 the basic issue with was marked as solved.

Fixed 'Unable to create volume snapshot' error
source: http://www.acronis.com/de-de//support/updates/changes.html?p=37994

At least in some of the cases it is still not solved.

Since I am fully dependence on Acronis , why should I still keep the Windows recovery partition?

I have deleted this Windows recovery partition away ... and backup is successful .....

Hello Karl,

could you, please, set the status of Volume Shadow Copy and Microsoft Software Shadow Copy to Automatic:

Start -> Run -> services.msc.
Locate Volume Shadow Copy and Microsoft Software Shadow Copy services, right-click and select Properties.
Set the startup type to Automatic.
Restart the backup.

Does the issue persist?

Thank you,

Olga - Can I confirm it is OK to delete away the Windows recovery partition?

This Windows recovery partition is auto generated from windows installation? Will it impact they next windows upgrade?

Karl,

Thought I would pass this along. I found the following instructions in KB Article 46893 under VSS Snapshot Creation Errors:
(Backup may fail with errors:
Failed to create volume snapshot.
Failed to lock the volume snapshot. Failed to start creating the volume snapshot.
The request is not supported VSS writer '' with class ID '' has failed to process the snapshot.

Go to Start -> Run -> eventvwr.msc. Navigate to Windows Logs -> Application and Windows Logs -> System to check for error messages related to VSS service. Search for solution in Microsoft Support articles, for example see this Microsoft TechNet Article.)

If you go to this article the part "this Microsoft TechNet Article" is an active link.

In locating the VSS error code in the Windows Logs and cross referencing such codes with the TechNet link may help.

Hello Olga, hello Enchantech, I will look into possible VSS problems. But I am confused how the visibility of a drive can make a difference.

"Since I am fully dependence on Acronis , why should I still keep the Windows recovery partition?
I have deleted this Windows recovery partition away ... and backup is successful ....."

Suum cuique Richard, I think that this problem should not be solved by workarounds at all. You will need the recovery partition to use features like computer reset if you want to install Windows 10 baremetal or keeping your data and refresh Windows. MS said that the recovery partition is not that important anymore due to Windows 10 new structure but still recommends to keep it in case that drive C gets really inaccessible in any case.

Also in the past years I had situations where my Acronis backups failed to recover at all (not only one), so personally I am happy to have this recovery access too. Ofc I could also use a Windows disc / USB stick but this has drawbacks over MS new method how they can restore Windows 10 to default which will include all installed Windows updates - 1 month.

"Olga - Can I confirm it is OK to delete away the Windows recovery partition?"

Hello Richard,
I agree with Karl, deletion of Recovery partition is not a solution.

Karl, I will wait for result of setting the startup type of services to Automatic.

Thank you,

Hi Olga - Noted.

by the way I also tested setting the service to Automatic.... same error.....:(

If like this .... I really thinking can I ask for a refund...

Richard,

Thank you for update!
I would ask you to collect SnapAPI and VSS Requestor logs and System Report as per the following article https://kb.acronis.com/content/48686 and contact our support team: https://www.acronis.com/support/, we'll do our best to find the solution.

Best regards,

Hello again,

sorry for the late reply. I have checked the VSS eventlog entries and the configuration. For some reason I found out that VSS was not activated at all on the reported computer, means the VSS service is set to manual and is not running. There are no issues in the eventlog, but what irritates me is:

System protection (VSS based) was turned off completely! I was not aware about this because on this computer I used VSS actively.
When I checked my own computer (no backup issues with ATIH here) computer protection was also disabled while the maximum VSS storage limit was set to maximum.

I am curious why this setting occours on 2 different computers in a same way (not cloned, no GPOs etc). On a third Windows 10 computer the settings are "normal" so system protection is enabled on the system drive and storage limit is set to a low percentage, like usual.

All I can say is that I have not disabled computer protection on any of the computers. At first I thought this strange config would be originated by ATIH 2016 or Windows 10 (bug), but looking at the third computer this cannot be validated.

I encourage everyone of you to have a look at your individual computer protection settings and let me know if they are ok or set in a strange way like I have seen it.

In Windows 8 / 10:
right click on start screen button > System > System protection

In Windows Vista / 7:
right click on Computer > Properties > System protection

As said the standard settings are that protection is enabled on the system volume (mostly C) and the storage size is set to a low percentage.

Afaik VSS service is usually set to manual startup @Olga

Attachment Size
297834-122479.png 526.43 KB
297834-122482.zip 4.19 KB

Hello Olga,

I have tried your solution to alter the VSS service startup. I've created a new task called "system-volume" for these tests.
This job will only backup the problematic Windows recovery partition to avoid overhead in the logfiles.

Windows default settings:
VSS service (servicename: VSS): manual, not started
Microsoft Software Shadow Copy services (servicename: swprv):, startup manual, not started

VSS service startup: automatic
Result: backup of hidden Windows recovery partition fails

--

VSS service startup: automatic and started
Result: backup of hidden Windows recovery partition fails

--

VSS service startup: automatic
SWPV service startup: automatic
Result: backup of hidden Windows recovery partition fails

--

VSS service startup: automatic, started
SWPV service startup: automatic, started
Result: backup of hidden Windows recovery partition fails

At least I tried running a backup of the recovery partition with tracing enabled and VSS / SWPRV: startup automatic, not started

I have attached the most recent System report with tracing enabled!

Attachment Size
297849-122488.zip 5.09 MB

Hi Olga .

https://kb.acronis.com/content/48686 is for TI 2015 and I never have the issue.

Those service Volume Shadow Copy service etc I run or not also have the error.

I think Karl already collected quite a lot of data and mine should be similar to him.

As I said ..... same OS same PC ... I put in TI2015 perfectly well.... remove TI2015 and put in 2016 error comes.

So that should be a clear clue .

Karl,

thank you very much for logs!

Have a good day!

Hello Richard,

Yes, you are right, this article is for Acronis True Image 2015, but I posted it, as it is valid for 2016 version too, and the same information should be collected for investigation.

I do not force you to collect the information, we continue the investigation with Karl's logs. If we have more information from different environnements, we will be able to provide better solution.

Thank you,

Karl, Richard,

Been following this thread and I have a question for you. Are the problems your having happening on machines that you have upgraded from one version of True Image to another? Same question if you upgraded from the RTM to current 5586 version?

If you have would you mind having a look at C:\windows\system32\drivers and looking for snapman.sys and/or snapmanXXXX.sys where XXXX is a number and letting us know what you find?

I have found that on my test machine with 2 different installations that were in place upgraded (ie. upgrade installs over previous release) there were multiple snapmanXXXX.sys files. These are driver files that work with VSS to capture disk state for a running backup task. If you find that you do have multiple drivers listed you should find as well a snapman.sys file (no associated number). If you hover your mouse over this file a balloon tip will appear that shows what version of the snapman.sys file is being used. What version on your systems is this?

I found in my test machine that performing an uninstall of the application followed by a run of the 2015 cleanup tool and checking the registry filters as indicated that these numbered snapmanXXXX.sys files were still present in above named folder. I manually deleted them and then did a clean install of the 5586 app, had a look back at the drivers folder and only found a snapman.sys file that when viewed to check version number was a different version than what I saw prior to the uninstall I described.

In other words I had performed upgrades to my TI installs via the upgrade feature within the application on these test installs which resulted in the leftover snapmanXXXX.sys and a non numbered snapman.sys file. The snapman.sys file showed as using one of the numbered snapmanXXXX.sys files and when a clean fresh install was performed the app created a new snapman.sys by itself and that file is a different version.

I have not experienced the issues you have but I have to wonder if what I found here may have something to do with your problems.

Hi Enchantech,

to answer your question, the issue happens on a computer that has been upgraded from ATIH 2015 to 2016
"there were multiple snapmanXXXX.sys files"

this is also what I've found out when digging the issue about BSODs snapman.sys caused. But only one file named snapman.sys is linked in the Windows registry and will be actively used for this job (https://forum.acronis.com/de/node/96768#comment-291297, https://forum.acronis.com/forum/97512)

The active snapman.sys is 4.7.0.2439 while there are backup copies of the files 4.6.0.2434 and a backup of the 4.7.0.2439 itself. The same situation is present on my computer where I have tested ATIH 2016 beta, so the presence of duplicate files is not an issue.

What is your version you have at the end after going through all these uninstalls and cleanups?

Karl,

I too have version 4.7.0.2439 after a clean install. I too found only 1 file linked in the registry but I had some other weird occurrences with one install in which for example after upgrade from 2 previous BETA versions and the RTM to the first release version 5576 the machine would no longer shutdown after backup, could not pause a Cloud backup either. Once I uninstalled everything, ran the cleanup tool, removed the extra snapman drivers, and clean reinstalled the app all returned to normal. I just see this as strange behavior, I have no explanation for this but it seems somehow related.

Roger,

Thanks for answering.

I clean install or not.... also have the problem..

Right now the work around is to give the partition a drive letter.... and wait for the patch before remove the driver later ...

The situation on your computer is pretty unclear for me though, you did alter so many things along the way

Upgrading, Downgrading, deleting the partition, now speaking about assigning a drive letter.

Hi Karl

Sorry for the confusion ... yes you have understand correctly... except that I forgot to mention every action I put back to the same image before I try .

Before I try 2016 .... I have clone a image first -- lets call this "A"

I play with A ... upgrade and tested have error .... then I restore back A ... then I tried delete partition and it work .... after that again I restore back to A .... and assign a drive letter and test .....

So I always have a A .. which is not damage by 2016 .

ok thanks for your explainations Richard. I really hope that Acronis can investigate the issue with just one logfile. At the moment I am quite happy that this seems to be more of a rare issue but imho it is still important to get fixed.

unfortunately no change in build 5620, while the changelog still states

Fixed issues

Fixed 'Unable to create volume snapshot' error

Afaik you can request a refund within 30 days after purchase. Despite the quite low answering rate from officials to threads I still have hope they will fix it.

Karl,

I have a suggestion. Set the VSS service to "disabled" and try to backup the Recovery partition. I have seen VSS fail to snapshot a Recovery partition when there was not enough free space on the partition. TI will fall back on its own snapman service to create the snapshot with VSS set to disabled.

EDIT:
Here's some additional information on the VSS service. The default setting in Windows is for a Manual start. Before running a backup with TI, VSS is stopped. When TI starts a backup it requests the VSS service to start and the service should be running. When the backup is completed, TI request the VSS service to stop. You can check the state of the VSS service before, during and after a backup to confirm this.

Mustang give a very good clue ---- not enough free space on the partition..

I resize the Recovery partition ( I give it a 50G more ) .... and guess what ......... the backup successful ..... !

I am now able to hide back the partition ... and living with extra 50G in the recovery partition...

Maybe I will try to resize to lesser.... like 10G more ....

Hi Mustang,
it is actually hard to check as the backup of this 400 MB partition is simply done fast - or better said aborted too quickly. I will disable the VSS service and try it. I wonder why Acronis asked me to explicitly enable the VSS in the previous debugging, just as if they think that snapman would not jump into the process at all.

@Richard, thanks for experimenting but I dont want to waste any more space for this recovery partition, it is just 400 MB sized and only a bit of it actually allocated. Resizing is no option of a workaround for me.

I've disabled the VSS Service and tryed the Backup with the Recovery included, same Error on my machine.

Karl : No need to give 50G .... I tried just 5 GB will have no more issue....... So I can give it no issue.....lol....

Updated : .... Ok just give it 1GB on top of 400M will solve the issue...

Richard,

I don't think 1 GB of extra space is needed. I have a 300 MB Recovery partition that is 78% used (66 MB free space) that works okay. Try making the partition 450 MB (adding 50 MB to the original 400 MB).

I have resize too many times already ..... I think give it 1GB ( drop from 50G) is happy for me already .....Lol...

WilliB,

Make sure that the RPC service is running on your machine, VSS is dependent on it and will error out if it is not running. Also if you have more than 1 disk drive installed in your machine make certain that your Windows OS disk is listed first in the boot order in your machine bios. This has proven to work for some users.

Enchantech,

thank you for your tip, checked my config, VSS and RPC is running and my OS Disk is the first, it is always to avoid troubles.
But unfortunately it doesn't help :-(

WilliB,

Have you run chkdsk against all partitions on the drive including those which are hidden like the recovery partition mentioned here? Filesystem errors are known to cause snapshot creation failures so it is a good idea to eliminate that as a possibility as well.

I agree with Mustang that there is a correlation in some instances that insufficient room on a partition can be the root cause of this snapshot failure. Having said that it is not the only reason for such failures. So it is best to check all know possible causes before declaring it an issue in the product.