RAID is not a backup: how companies lose data in minutes

A Warsaw accounting office, design studio or law firm can have RAID, green disk lights and no usable backup at the same time. RAID may keep a system running after one disk failure. It does not roll files back after ransomware, deletion, bad rebuilds or volume corruption.

One quick administrative decision can make recovery harder than the original fault. If a RAID or NAS shows degraded/offline, a volume disappeared, or a rebuild started after disk replacement, secure the member disks before guessing.

RAID does not replace a backup

RAID is an availability mechanism. Backup is a recovery mechanism. A RAID array can keep a server online during selected hardware faults, but it cannot restore yesterday before a user deleted a folder or malware encrypted shares.

If ransomware encrypts files on a RAID volume, the array faithfully stores the encrypted version. If an administrator launches the wrong rebuild, RAID may propagate damage across the set.

RAID versus backup: the difference that matters

• RAID: keeps services running despite selected hardware failures.
• Backup: lets you restore data from before deletion, encryption or corruption.
• RAID risk: the array can synchronize a bad state.
• Backup risk: it must be tested, isolated and protected from the same incident.

How data recovery from a damaged RAID 5 usually works

The controlled procedure starts with stopping writes, documenting disk order and imaging member drives. Recovery work is then performed on copies, not on original disks.

1. Identify every member disk and preserve original bay order.
2. Create controlled images of the drives that can still be read.
3. Reconstruct RAID parameters: order, stripe size, parity rotation and offsets.
4. Mount or analyse a virtual reconstruction and recover data to a separate target.
5. Only after data is secured, decide how to rebuild production infrastructure.

Wrong reconstruction parameters can make the file system look unreadable even when the data is still present.

Case study: when no backup damages the business

A company can lose access within minutes when RAID is treated as the only safety layer. Examples include ransomware encrypting shares, a rebuild started on the wrong disk, a controller fault after power loss or a damaged volume that the system keeps writing to.

In each case, RAID may keep parts of the infrastructure alive long enough for damage to spread. A verified, separate backup is what gives the business a clean restart point.

What to prepare before reporting a company RAID failure

• RAID level, number of disks and NAS/controller/server model.
• Disk order, bay numbers and serial numbers.
• Event timeline: disk replacement, rebuild, power loss, update, ransomware or deletion.
• Services on the array: SMB shares, VMs, databases, iSCSI LUNs or accounting systems.
• Backup status and whether a restore test has already been attempted.

When not to improvise

Stop improvising if the RAID contains business data, backups are uncertain, the array has already started a rebuild, the NAS reports multiple errors or encrypted files appeared on shares.

For time-sensitive environments, compare this article with the first 24 hours after server or NAS failure and the QNAP NAS ransomware case.

How to turn this lesson into an emergency plan

Separate availability from recovery. Use RAID for uptime, snapshots for short rollback windows, offline or immutable backups for incident recovery, and restore tests so the plan is more than a dashboard checkbox.

A practical plan should say who is allowed to shut the system down, where bay order is recorded, which backups are isolated from the production network and who decides whether to involve the lab before a rebuild or restore attempt.

When RAID should be treated as an incident, not a normal fault

A single degraded disk is not always a disaster. The risk changes when the array contains critical company data, the backup has not been verified, the controller reports more than one warning, or somebody has already tried a rebuild, restore or disk swap.

At that point the priority is no longer to make the dashboard green. The priority is to preserve the state of every member disk, document what changed, stop unnecessary writes and choose a recovery route that does not make the damage permanent.

• multiple disks report errors or disappear from the array,
• a rebuild started after replacing the wrong or uncertain disk,
• the NAS or server still works but folders, databases or VMs are missing,
• ransomware, deletion or file-system corruption affected data on the RAID volume,
• backup status is unclear or the first restore test failed.

When to stop improvising and switch to an emergency plan

Stop if the next action is only a guess: another reboot, another controller import, another rebuild, another repair job or a restore over the only copy. In RAID recovery, the first wrong attempt often causes more damage than the original failure.

Before continuing, collect the disk order, serial numbers, event timeline, screenshots of NAS or controller warnings and information about services running on the array. That evidence lets the lab reconstruct the case from copies instead of experimenting on production disks.