none
Free space on shadowcopy volume is less than threshold value RRS feed

  • Question

  • Hi all,

    We've recently linked DPM with Azure to protect our SharePoint and Exchange environment, Exchange has been backing up no problem, SharePoint however is failing with the below error; 

    Unable to create a snapshot of the replica volume for this datasource. Following are possible reasons and recommended actions:
    1. Free space on shadowcopy volume is less than threshold value (1258291200 Bytes) for taking a shadow copy. Please increase size of shadowcopy volume.
    2. Replica of datasource is in invalid state. Please run consistency check on this datasource.
    3. Replica data is in inconsistent state. Please create a disk recovery point of this datasource. (ID 33504)

    There's plenty of space in the recovery point volume (32.16GB allocated, 2.39GB used), to test this i once up'd the size to 100GB, the volume has now been shrunk down. 

    We're using SCDPM 2012 R2 CU9 and SharePoint 2013 with the February CU. 

    Am I missing anything? 

    Any help will be much appreciated! 

    Dane

    Wednesday, May 18, 2016 3:49 PM

Answers

  • Hi Altayan,

    We actually managed to create a backup successfully today, it turned out to be an issue with the mount points. 

    We ran this command - mountvol >C:\mountvol.txt - Found that there were missing volume mount points - resync'd the missing mount points (DpmSync -Sync) - this caused the replicas to become inconsistent so we ran a consistency check, re-ran the job and it worked! 

    It's extremely frustrating because they could've saved end users countless hours by making sure the error messages displayed properly...


    • Marked as answer by Dane-948 Thursday, June 2, 2016 1:51 PM
    Thursday, June 2, 2016 9:17 AM

All replies

  • Anyone have a solution?

    Friday, May 20, 2016 1:55 PM
  • We are having the same issue.  We've been with Azure for over 1 year, but over the last few months we've steadily had more and more problems, with increasingly vague error messages.  Over the weekend we had all of our Azure jobs fail to upload with the above error message, normally it's just 2-5 in a 24 hour period that fail.  We are 100% up-to-date on Windows and DPM updates. We aren't having any problems with disk backups and none of the data sources that are failing to upload have consistency issues, we've run those checks dozens of times over the last months without turning anything up.  I know several system administrators at various other companies across the country, Education and Healthcare just for reference, that have moved off of Azure because of the issue and the incredibly long recovery times.  I've heard good things about Dell's backup service and we are starting to investigate it as an alternative.
    Monday, May 23, 2016 1:53 PM
  • Hi Altayan,

    We actually managed to create a backup successfully today, it turned out to be an issue with the mount points. 

    We ran this command - mountvol >C:\mountvol.txt - Found that there were missing volume mount points - resync'd the missing mount points (DpmSync -Sync) - this caused the replicas to become inconsistent so we ran a consistency check, re-ran the job and it worked! 

    It's extremely frustrating because they could've saved end users countless hours by making sure the error messages displayed properly...


    • Marked as answer by Dane-948 Thursday, June 2, 2016 1:51 PM
    Thursday, June 2, 2016 9:17 AM
  • Thank you very much for coming back around and replying to this thread.  I am currently running the consistency checks on our system after doing as you suggested.  I had contacted Microsoft directly and a 3rd party consultant and received no response after opening the tickets.  I had almost forgotten about this thread, but I am very glad I checked it.  Thanks again!
    Monday, June 27, 2016 3:27 PM
  • I am sad to report that this did not correct our issue with pushing backups to Azure.  Our local backups have been running all along, and there were a number of mount points that the sync did correct, however, all of our Online Recovery Point jobs during the night failed.  I'll keep pushing Microsoft and the consulting group to see if they can find anything else wrong.  If they can't by the end of the week, I am planning to stand up another DPM server from scratch and try moving our protection groups to it one by one and see if the problem follows.
    Tuesday, June 28, 2016 1:52 PM
  • I may have found the solution.  Perhaps I missed this somewhere along the way, but I can find any mention of it.  I modified the protection groups to remove online protection, and then added it back with the exact same schedules.  I have a test run going right now and it is actually writing to the cloud. Assuming nothing else breaks I think I have this defeated and just need to go through the rest of the protection groups doing the same steps. I'll respond back here in the event that it fails, otherwise any future reader should consider this my fix for the issue.
    Tuesday, June 28, 2016 4:42 PM