I have a server using an HPE P800 controller with a RAID-0 volume and no current backup. After installing a Veeam agent, backups began failing during VSS reads with messages indicating that a volume shadow copy was corrupted. Windows Event Viewer also reports read errors and a bad block on one of the physical devices, even though the HPE storage utility still reports the array as healthy.
I need to recover roughly 1 TB of data containing about 43,000 files. I'm considering using Robocopy over the network with minimal retries, possibly reading from a VSS snapshot through a symbolic link so the source is not affected by ongoing writes. I'm also wondering whether file-level Veeam backups would be safer, and whether I should attempt CHKDSK after obtaining a backup.
Because this is RAID-0, I assume the eventual fix may involve replacing the failing disk, recreating the array, and restoring the data. Is there a safer recovery method or anything I should avoid before doing that?
3 Answers
Do not run CHKDSK on the original volume yet. It can modify metadata and make later recovery harder, especially when the underlying storage is already returning read errors. Stop unnecessary writes, disable or pause backup jobs that keep hammering the volume, and prioritize an image or a controlled copy. VSS may provide a consistent view, but it does not repair unreadable sectors and the shadow copy can disappear when storage space or backup activity changes.
I would image the volume before repeatedly scanning it or running repairs. A forensic imaging tool such as FTK Imager can attempt to read difficult sectors and record which areas could not be recovered. Save the image to fast, reliable storage, then mount it read-only with an image-mounting tool and extract files from the copy. This avoids making the failing source handle repeated file-level operations.
Treat this as a failing storage device, even if the controller utility still says the array is healthy. Robocopy can recover many readable files, but it is not a complete bad-sector recovery tool. If you use it, keep retries and wait times very low, such as /R:1 /W:1, and use /MT:1 to reduce concurrent reads. Copy the most important data first and log everything that fails. Once the data is secured, replace the disks and avoid rebuilding the replacement as RAID-0; RAID-1 or another redundant layout would be much safer.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures