Skip to main content
Druva Documentation

Troubleshooting the alert 'CloudCache unable to read write on Volume'

 

Problem description

CloudCache cannot read or write data to the volume during backups, restores, or while running the synchronization schedule. Phoenix logs show the activity during which the alert occurs. The alert says 'CloudCache unable to read/write on Volume – <Drive:>\Phoenix\PhoenixCacheStore'.

Cause

You can encounter this issue due to one of the following reasons:

  • Hardware issues on the cache.
  • Hardware issue on the client from where the block originated.
  • There was a cache machine restart during the backup.
  • Block(s) might have been quarantined by the antivirus.

Traceback

Log location:  C:\ProgramData\PhoenixCloudCache\Phoenixcloudcache.log 

C:\ProgramData\Phoenix\PhoenixCloudCache.log 

[2020-03-12 20:13:42,868] [ERROR] [wpid 1131-3220-1584049799] Error in getting block, sid: 1982, ID: 1704049509006330195. Error: Error -3 while decompressing data: invalid stored block lengths

[2020-03-12 20:13:16,362] [ERROR] [wpid 1131-3220-1584049799] Error in opening file D:\PhoenixCacheStore\PhoenixCacheStore\1982\017040\495090\06330\01704049509006330190

Resolution

1. Check if the issue start date and last reboot time of the CloudCache are the same. 

Note: Druva recommends not to reboot the CloudCache server during the time of backup. Check with CFT/Engineering team for the missing block by creating a JIRA ticket.

2. Check if any antivirus is installed in the CloudCache server. If yes, then validate if the error block(s)/handle(s) are quarantined by the antivirus or any other third party software. 

For example: Error in opening file D:\PhoenixCacheStore\PhoenixCacheStore\1982\017040\495090\06330\01704049509006330190

Check if the block 01704049509006330190 quarantined by the antivirus. If yes, then restore the block from the quarantine.

3. Check the system and application event log of the CloudCache server for any hardware related issue. For example disk/memory block corruption.

4. Check if the alert is false positive by checking the block in the location.

5. Check if you're facing error for new handles every time or if it is for the same handle. If this error keeps occurring for new handles, then ask the customer to run chkdisk on the volume. If error occurs for the same handle then request the engineering team to run the storage script to find the corrupted restore point. Refer PHN-18642.

  • Was this article helpful?