RAID on a Single Server: Hardware vs Software Reality

RAID is the most misunderstood four letters in server storage. It is not a backup, it does not protect against deletion, and on a single-node VPS most of the conventional advice about it quietly stops applying. Before you plan disk counts and controllers, it helps to separate the three things RAID can actually do, survive one disk's failure, survive one disk's downtime, or buy raw performance, and to ask which of those a single rented node even needs.

What RAID actually protects

• Mirroring (RAID 1 and RAID 10) protects against one disk dying: both halves hold the same data, and reads fan out across members.
• Striping with parity (RAID 5, 6, 50, 60) protects against one or two disks dying while using capacity more efficiently than a mirror.
• Striping alone (RAID 0) buys size and speed and protects against nothing; it doubles the chance that any single failure means total loss.

Notice the pattern: RAID only answers the single question, a physical disk failed, does the system keep serving? It does nothing about rm -rf, a bad application write, filesystem corruption, or ransomware. Those need the backup discipline covered elsewhere in this series, and confusing the two is how people end up with ten disks of raw footage and no copy of it anywhere else.

Hardware RAID on a VPS is mostly a rental concept

On Netbay's infrastructure the job of surviving a physical disk failure is handled at the platform level, beneath your virtual machine: the node's High-Speed SSD storage is arranged and supervised by the provider, and your VM simply sees one reliable block device. You do not, and should not, see the internals of that arrangement; it is the same division of labor as the server's CPU and RAM. Trying to build hardware RAID inside a VM against virtual disks doubles your protection against a failure mode the platform already handles, and usually just wastes capacity and IOPS.

Software RAID with mdadm: when it is actually justified

Inside the VM, software RAID only earns its keep when you manage to give two genuinely different block devices through independent paths from two different disks. On a single VPS with one virtual disk, carving one device into two mdadm members is redundancy theater: both halves still die when the one underlying device dies, and you have silently doubled your write amplification for the privilege.

mdadm remains useful on bare-metal boxes you fully own and on any setup handed two independent volumes, so knowing the commands is not wasted:

cat /proc/mdstat
mdadm --detail /dev/md0 2>/dev/null | grep -E 'State|Devices|Rebuild'
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

If you do use it, schedule the monthly consistency check, because a mirror you never exercise is a mirror that silently rebuilds broken:

echo '0 4 * * 0 root /usr/share/mdadm/checkarray --cron --all' > /etc/cron.d/mdadm-check

Where a single VPS actually gets its resilience

Properly managed shared infrastructure takes the disk-failure worry off your plate and replaces it with two things you must own: snapshots you can roll back to, and a tested restore path. A volume snapshot is the honest single-server equivalent of RAID 1, except that it protects against a bad state, a bad deploy, or a corrupted filesystem, which are the failures that hit ten times for every one disk death.

Verify the exit ramp exists before you need it:

# a restore drill: mount a snapshot, extract, count rows
rsync -aAX snapshot-mounted/ /tmp/verify/ 
grep -c INSERT /tmp/verify/db.dump

When the drill passes against a real snapshot, you hold the single-server form of redundancy and it covers more failure modes than any mirror.

The decision, compressed

Ask, in order: is the block device already provided with redundancy above me? If yes, RAID inside the VM is redundant. Do I have two truly independent devices? If no, RAID 0 or 1 against one backend is either useless or dangerous. Do I have snapshots and a tested restore? If yes, you already hold the single-server equivalent of RAID, and it survives more scenarios per rupee.

Takeaway

On a platform like Netbay's, disk-failure protection lives under your VM, which is exactly where it belongs; spend your effort on snapshots and restore drills instead of mirroring virtual blocks. Spin up an instance at netbayhosts.in and you can confirm that division of labor from the panel to the shell in a few minutes.