CoNetrix

Blog: VSS

The other day I had an issue come up with a customer where VSS (Versative Storage Server) integrated file system backups stopped working for some unknown reason. Usually, a reboot fixes these types of issues, but backups continued to fail after a reboot. I started a support call with the backup vendor and after seeing the error logs, the support tech seemed fairly sure he knew what the problem was. This error is usually caused by a malformed path within the registry. So he had me run the following commands on the server and send him the output. [more]

vssadmin list writers >> c:\writers.txt
vssadmin list providers >> c:\providers.txt
vssadmin list volumes >> c:\volumes.txt

diskshadow /L c:\shadow.txt
list writers detailed

After reviewing the text files created, he found the malformed path:

- File List: Path = c:/windows\hpsum_1327455089, Filespec = hpsumserverw32.exe

To correct the issue, I searched the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ for “c:/windows\hpsum_1327455089” and corrected the path to “c:\windows\hpsum_1327455089” . After doing this, the backup ran fine. Further research uncovered the root cause. During the last maintenance window, HP System Update Manager was used to update the HP System Management Homepage on these servers. This malformed registry key was created by HPSUM during the upgrade.

Backup, VSS, HP, backup,
 

I had an issue come up with Platespin the other day that was very strange. The Platespin protection job for a server hadn’t been completing successfully since it was upgraded to a new build. The job would run all the way up until the point where it was doing the VSS snapshots of the source machine, then it would die with a very cryptic VSS related error. This would cause the VSS System Writer to display an error state when using vssadmin list writers. I engaged Platespin support, and after about two weeks going back and forth with their support, they finally cut me loose with a “call Microsoft” recommendation. I kept troubleshooting and found that when I would try to clear out the VSS snapshots by changing the maximum space setting for the VSS snapshots to 300 MB (which is supposed to be the minimum amount required for an x86 system), I would get an error pop-up noting that 300 MB was not sufficient amount of space for snapshots on that volume. I finally found by process of elimination that 1800 MB was the magic number for the c: volume. However, even though the drive had over 2.5 GB of free space, the PlateSpin job would still fail. [more]

As a last resort, I changed the storage location for the VSS snapshots for the c: partition to the d: partition (which had over 20 GB of free space) then ran the job again. This time, the job ran a little bit farther, then died when trying to snapshot the f: partition (which was only used for a page file). After moving the VSS snapshots for the f: partition over to d:, the job ran successfully…finally. What was very strange is that the VSS snapshots would always reserve the same amount of space for each partition as the maximum setting for the c: partition. I could change the maximum space setting for snapshots on the c: partition and run the job again and the snapshots for all partitions would match the c: partition no matter what the maximum setting that I had specified for the individual partitions. I could snapshot the partitions with vssadmin and this did not happen and when backing the server up with CommVault (which uses VSS) it didn’t happen….only PlateSpin. I looks to me like their software has a bug in it.  I have emailed their support tech I was working with to explain what I found…no response so far.

Networking, PlateSpin, CommVault, VSS, backup,