Skip to main content
commvault.com commvault.com
Question

How hyperscale deal with read request after a disk failed

  • November 7, 2025
  • 2 replies
  • 29 views
L
Bit
Forum|alt.badge.img+1

Hi friends,

Good day! I got this situation, there was data disk failure happened and new disk was not yet replaced, but a DDB verification job got started, it reported completed with error due to some block can’t be read, but the DDB verification succeeded the nex day, but the new disk not yet replaced too. why this happened? does this mean that hyperscale reconstruct the data blocks on the failed disk to the rest good disks? I thought it should like RAID when a data block on a missed drive can be calculated out by EC code  from the rest drives when access request come?

Thanks,

Leo

2 replies

Bronco
Vaulter
Forum|alt.badge.img+3
  • BroncoVaulter
  • Vaulter
  • November 7, 2025

Hello Leo,

In simple terms, what happened is normal and expected behavior in a Commvault HyperScale X system. When one of the data disks failed, the first DDB verification job tried to read some data that was stored on that disk. Since the disk was missing, those blocks could not be read, and the job finished with errors.

However, HyperScale X uses a smart protection method called erasure coding. it’s like an advanced, software-based version of RAID. Instead of relying on a single disk, data is split into small pieces and stored across several disks along with extra “parity” information. This parity allows the system to rebuild or recreate any missing data from the remaining healthy disks.

So, even though the failed disk hadn’t yet been replaced, the system quietly rebuilt the missing data fragments in the background using information from the other disks. When the verification ran again the next day, those same data blocks were now readable from the reconstructed copies, so the verification completed successfully.

In short, the system didn’t ignore the failure it automatically healed itself using redundancy. The disk still needs to be replaced to restore full protection, but this behavior confirms that HyperScale X’s built-in fault tolerance was working as designed.

Regards,

Siddharth Gandhi

 

R
Vaulter
Forum|alt.badge.img+3
  • Rohit RaviVaulter
  • Vaulter
  • November 7, 2025

Hi ​@Leo2025 

Yes, your understanding of EC 4+2 is correct. Even if one of the disks is faulty, when a read request is initiated, the system is capable of rebuilding the data from any four available blocks, whether they are data or parity segments.

Regarding your DDB verification, if the verification jobs are incremental, the jobs that have already been verified will not be automatically re-verified unless the specific job is manually selected for verification.

To confirm this behavior with certainty, I would recommend raising a support ticket so that the logs can be reviewed in detail.

Regards,

Rohit Ravi

Terms & ConditionsCookie settingsAccessibility statement