Symptoms

Job begins, but does not get past VSS, nor does it seem to fail:

  • Job hangs with 0’s across the board when viewing client > properties for the job and virtually no message logs available; or
  • Job fails due to network connectivity (reset by peer).

Troubleshooting

Disable VSS entirely to confirm if this is a VSS issue or not.

If the backup completes with VSS disabled, attempt to run a backup with VSS enabled but Include Writers disabled. This will determine if it is all of VSS or just the writers that is causing the issues.

Also, try to run the following through the client diagnostics tab to view the writers. If it does not work (hangs up), try the same from the server itself.

vssadmin list writers

If running the above command hangs as well, try the following:

  1. Try rebooting the machine and see if that fixes the “hang” problem.

  2. If not, make sure the service is not disabled.

    1. Open Start Menu, right-click Computer, and then click Manage.

    2. Go to the Services panel (Services and ApplicationsServices).

    3. Find Volume Shadow Copy in the list.

    4. The Startup Type value should not be Disabled.

    5. Change Startup Type to Manual if necessary.

  3. Try restarting the service from the Properties dialog (see steps above).

    1. If service is running, click Stop to stop it.

    2. Click Start.

    3. Check that Service status goes from Starting to Started.

  4. Try running vssadmin list writers again.

The reason the client started to hang up had to do with an issue with the VSS writers. (It is a common testing step to disable VSS on hung up or failed jobs to confirm or eliminate it as a factor in the issue.) Disabling VSS allowed the job to run successfully, with the side-effect that any open files were not backed up as is expected. From what they saw in the logs, our engineers suspected the VSS issue was linked to the VSS writers. This was confirmed when we could not bring up the writers using the CFA and you also could not bring up the writers from the server itself (using the command we sent you). This confirmed that there was not an issue on our side, rather the issue was on the server itself.