Solved

Failing DDB Backup on a Windows-based MA due to shadow copy space allocation exhaustion

  • 8 January 2021
  • 2 replies
  • 2801 views

Userlevel 3
Badge +4

Hi Team, 

My DDB Backup operations are failing with the following error message: The snapshot of the Dedupe database from the previous attempt of this job is not available and a new one could not be created, as the job cannot continue under this condition, it will fail 

I can't really find anything in the Commvault logs outside of a few VSS-related errors. What could this mean? 

Regards

Winston
 

icon

Best answer by Jon Vengust 11 January 2021, 00:09

View original

2 replies

Userlevel 3
Badge +5

The description for this particular issue is a bit more granular in that it explains to us the shadow copy (snapshot) of the DDB has been lost.

 

This means it was initially created but failed to grow and/or was prematurely deleted. We generally report the following error when this occurs: The snapshot of the Dedupe database from the previous attempt of this job is not available and a new one could not be created, as the job cannot continue under this condition, it will fail

 

This error is occurring at the MediaAgent level and as such, we'll need access for further review.

 

Evidence/Logs

 

When performing DDB Backup operations on a Windows-based MA, we leverage the Microsoft VSS Writers (Volume Shadow Copy Service) in order to quiesce the DDB without taking it offline altogether. It is not the Commvault product itself taking the shadow copy, but us requesting the writer to do so.

 

Our own logging whereby we call upon the VSS writers to take the shadow copy will output the below error in this scenario:

 

MA > \Commvault\ContentStore\Log Files\clBackup.log (located within our Commvault installation directory unless specified otherwise)

 

8712 2a54 03/12 08:33:15 1556710 COpenFileManagerPrivate::CreateShadow(245) - Failed to get Snapshot path for Volume path [<DRIVE_LETTER>] on reattaching to shadow <SHADOW_ID>

 

We can use OS event logging in order to identify root cause when encountering space-constrained issues with the DDB Backup. Below are two of the most common examples of this behaviour:

 

System logs via Event Viewer (Source: volsnap)

 

[Error] The shadow copies of volume <DRIVE_LETTER> were aborted because the shadow copy storage could not grow due to a user imposed limit

 

[Error] The shadow copies of volume <DRIVE_LETTER> were deleted because the shadow copy storage could not grow in time. Consider reducing the IO load on the system or choose a shadow copy storage volume that is not being shadow copied.

 

Resolution

 

When referring to the user-imposed limit, the volume in which the shadow copy is being created is configured to not exceed a certain size. In this case, the shadow copy requires more space in order to expand and grow to accommodate for the DDB size. We can modify this however with the below steps:

 

1) Right-click the DDB volume within Windows Explorer, select Configure Shadow Copies...

 

2) Select the DDB volume from the list. Click on Settings...

 

 

3) Acknowledge current settings. Most likely, you will see the Use Limit radio button configured

 

 

4) Three options are available to us here:

 

a) Set the maximum shadow copy size allocation to No Limit

 

 

b) Increase the manually configured limit (MB) to an appropriate size via trial/error

 

 

c) The staging area for the shadow copy can be relocated to an alternative volume if space is too constrained on the current volume

 

After performing any of the above steps outline in #4, proceed to perform another DDB Backup operation and record your results.

 

When referring to the growth error event, more than likely the DDB volume is at or near capacity and as such the snapshot cannot grow given the lack of physical capacity. Either extend the current DDB volume and/or relocating the shadow copy to an alternate path is also applicable here. There have been occurrences whereby there are snapshots that have yet to be cleaned up. This can be confirmed by reviewing the output of the vssadmin list shadows command (Source: vssadmin list shadows). If any are still remaining feel free to remove these vssadmin delete shadows command (Source: vssadmin delete shadows).

 

If the issue does persist further please seek Commvault Support and raise a ticket for a deeper look. Please let me know if you have any further queries/concerns with the above information. Otherwise, if you found this guide helpful, don’t forget to upvote this post for visibility!

Userlevel 3
Badge +4

Hi Jon 

Thank you very much for the detail answer !

Regards

WW

Reply