Replacing a Failed Single-Drive RAID 0: Source StorCLI Case

This translates a source case that replaces a failed drive configured as a RAID 0 virtual drive while the server remains running. RAID 0 cannot rebuild lost data from redundancy. Creating a new VD, partitioning and formatting produce new storage; restore data from backup. Hot-swap support and service impact depend on the controller, chassis and application.

1. Before replacement

Identify the actual device, serial number, controller, virtual drive and enclosure/slot. The source uses smartctl -i /dev/sdx; -i reports identity/capability information, not a complete health assessment. Controller-attached drives may also require the appropriate device selection.
Stop/quiesce affected I/O and unmount the affected filesystem where applicable. The source says it did not unmount during its incident; that is not a general instruction to leave active filesystems in use. Temporarily comment out the affected /etc/fstab entry.
Inspect all VDs and PDs with the read-only commands below. This source proceeds only after its target VD is Offline and target PD is Failed; those states do not authorize modifying any other drive. Record the exact IDs.

storcli64 /call /vall show
storcli64 /call /eall /sall show

If needed, locate the confirmed target. Replace x placeholders with the actual controller, enclosure and slot:

storcli64 /cx/ex/sx start locate
storcli64 /cx/ex/sx stop locate

2. Inspect the replacement

storcli64 /call /eall /sall show

The source expects the replacement to be UGood, with no F foreign-configuration indication. Record its EID:Slt. Confirm that it is genuinely the intended replacement before creating a VD.

Foreign configuration

The source lists the following syntax; brackets and the vertical bar describe optional/alternative syntax and are not literal shell commands:

storcli64 /cx/fall show [all]
storcli64 /cx/fall del|delete
storcli64 /cx/fall import

Delete and import are alternatives, not successive cleanup steps. Import attempts to bring a foreign configuration into use; deletion discards its metadata. Preview and investigate the exact controller/foreign configuration, particularly if any data needs recovery. Do not delete metadata just because a drive shows F.

Preserved cache

The case encountered preserved cache because the old failed VD had not been deleted. Its original broad examples are retained here for diagnosis, not as a block to run across a server:

storcli64 /call show preservedCache
# Historical all-controller/all-VD example: do not apply indiscriminately.
storcli64 /call /vall delete preservedCache force

Discarding preserved dirty cache loses its unwritten data. Broadcom documents per-controller/per-VD syntax storcli /cx/vx delete preservedCache [force]; select only the confirmed affected VD, follow the matching controller guide and resolve recovery needs first. The source’s guess that deleting the old VD before replacement would avoid the cache issue was not tested. Deleting a VD must likewise target its exact ID; selecting a healthy VD destroys its configuration/data access.

3. Create the intended new VD

The source’s create example, with the Chinese placeholder translated:

storcli /cx add vd r0 drives=<NEW_DRIVE_EID:SLOT>

Replace the entire placeholder with the verified enclosure/slot syntax supported by the installed StorCLI/controller. The source uses storcli64 for inspection and storcli here; use the actual installed compatible binary. Confirm the selected drive before creating the new empty RAID 0 VD.

4. Recreate and mount the filesystem

Use lsblk to identify the newly exposed block device.
The source partitions with gdisk, formats with mkfs and mounts the result. Partitioning/formatting is destructive; confirm the exact new device and intended filesystem rather than using another disk’s path.
Record the new filesystem UUID and update only the affected /etc/fstab entry. In this case a mount appeared not to take effect; systemctl daemon-reload followed by mounting again made /data2 usable. This is the recorded systemd/fstab case response, not a universal repair for every mount problem.
Run mount -a to validate the configured mounts and check the intended new filesystem’s read/write behavior. Restore the backed-up data and validate the application before returning it to service.

Broadcom StorCLI reference; use the edition matching the controller and installed tool.

Original case/reference: stored source.