Forum Discussion

Ryan_Craig's avatar
Ryan_Craig
Level 3
12 years ago

VSS snapshot of VxVM volumes fails

As the title says, VSS snapshot of my VxVM volumes is failing.

System Description:

W2k8 R2 SP1, FC-attached diks, SFWHA 6.0.1 installed

Backup software being used:  EMC NetWorker

 

Problem:

At this point, backup of the disks under VxVM (if that's not a totally obsolete terminology to use - I see Windows classes SFHA volumes as such in the registry, anyway) is failing.  The strange thing is that it was working up until a certain point on Friday, at which point I did some un/re-configuring of the NetWorker client software on the machine, and then it stopped.  Originally I also had VCS installed, and two nodes were acting as part of a cluster, but I removed VCS to try and narrow down the problem.  Right now only Storage Foundations for Windows (HA) is installed on both machines.

The disks are provisioned via FC, and are configured, one disk each, in disk groups "DG1" and "DG2".  One group, "DG2", is imported and the single volume on it is mounted as "Y:\".

When I attempt a backup of files on this volume, it just hangs for a long time (~30 minutes), until VSS finally times out, and then finally prodceeds to do a backup without a snapshot (legacy method, as we call it).

This is what I get in the system logs through event viewer:

 

Volume Shadow Copy Service error: Unexpected error DeviceIoControl(\\?\Volume{45a4f034-f1bb-422c-9ac1-332fe35e6386} - 0000000000000108,0x0053c008,000000000023D000,0,000000000023E010,4096,[0]).  hr = 0x80070079, The semaphore timeout period has expired.
. 
Operation:
   Processing EndPrepareSnapshots
Context:
   Execution Context: System Provider

The same happens whether the Veritas VSS provider is registered or not, or whether its service is running or not.

In my efforts to troubleshoot this, the only thing I've noticed that may be a bit odd is that I have quite a few entries in the registry for volumes, more than I have actual physical volumes.  The system has one "local" drive, and two under VxVM control.  These are testing systems, and so have had SFW 5.2 installed previously, plus I have now installed and uninstalled SFW 6.0.1 several times while trying to trouble shoot this.  Note that the GUID of one of them does match the error message above.

 

Backup of the local (C:\) disk works normally.

For all I know this may not be a SFW/VCS problem at all, but an issue with Microsoft's flaky (in my experience, anyway) VSS implementation.

TIA,

Ryan

business continuity
Error messages
Storage Foundation for Windows
  • mikebounds's avatar
    mikebounds
    Level 6
    12 years ago

    I work mainly with SF on UNIX, but I do work on SFW on MicroSoft Windows too and have used VSS in the past, before COW (Copy-On-Write) was available and this is my understanding:

    There are 2 types of VSS snapshots:

    Full VSS snapshots:

      Database is quiesced using MS API
      SFW full snapshot it taken
      Database is un-quiesced using MS API
     

     

    COW VSS snapshots:

      Database is quiesced using MS API
      MS COW snapshot it taken
      Database is un-quiesced using MS API

    If you are using COW snapshots, I am not sure what SFW is doing, other than giving you an interface to use or schedule the MS tasks, so issue is probably with MS.  If you are using Full snapshots, then you could try a snaphot without VSS - this will not quiesce the database so will give you a "crash" copy of the database, but it should help to determine where the issue is.  To do a full snapshot without VSS, run:
     
    vxsnap -x snapdata.xml create -g DG2 source=Y:\/DrivePath=Z:
     
    This will take a full snapshot of Y: and mount the snapshot on Z:
     
    Mike

     

  • Ryan_Craig's avatar
    Ryan_Craig
    Level 3
    12 years ago

    With the Veritas VSS provider registered, attempting to use vxsnap as you detail above results in this:

    C:\>vxsnap -x snapdata.xml create -g DG2 source=Y:\ /DrivePath=Z:

    Please wait while snapshot operation is going on.

     

    Failed to complete the operation...
    V-76-58657-15: VSS Provider reached an unexpected provider error. Please check Application log or VSS provider log for more information.
     
    And the error log has this:
    Volume Shadow Copy Service error: Error creating the Shadow Copy Provider COM class with CLSID {6e374478-ad8e-41d1-90cb-38dc78fd4144} [0x80040154, Class not registered
    ]. 
     
    Operation:
       Obtain a callable interface for this provider
       Check If Volume Is Supported by Provider
       Add a Volume to a Shadow Copy Set
     
    Context:
       Provider ID: {637528cf-81b2-4e05-8bd2-74b33b6f893c}
       Class ID: {00000000-0000-0000-0000-000000000000}
       Snapshot Context: 9
       Execution Context: Coordinator
       Provider ID: {637528cf-81b2-4e05-8bd2-74b33b6f893c}
       Volume Name: \\?\Volume{45a4f034-f1bb-422c-9ac1-332fe35e6386}\
       Execution Context: Coordinator

    But I've gone searching in the registry, and it appears that the Veritas VSS writer is registered, as vssadmin output also shows.  I can only suppose that there's something wrong with the registration of the vxvssprovider, however.

  • Ryan_Craig's avatar
    Ryan_Craig
    Level 3
    12 years ago

    As this is not a production system, but rather a test system, I decided to stop spinning my wheels and pulling out my hair trying to figure this out, and just reinstalled the OS, etc on both nodes of the cluster.  And now they're working fine - but they were working fine before they weren't, too, so I may end up getting another opportunity to figure out why.

  • mikebounds's avatar
    mikebounds
    Level 6
    12 years ago

    I tested the syntax of vxsnap create I gave above on a 5.0 SFW system and this works ok.  I also did it the "old way" which is to use:

    vxassist -g DG2 snapshot H: DriveLetter=Z:

    So you could see if this works - if this works, then I would guess there is something wrong with VSS, which could be something wrong with your registry.

    Mike