LPIC-2 Advanced Storage: Software RAID (mdadm), iSCSI and NBD

A single disk is a single point of failure. When it dies, everything on it dies with it — and meanwhile, one disk can only read and write so fast. RAID (Redundant Array of Independent Disks) glues several physical disks together so the operating system sees one block device that is faster, larger, more resilient, or some blend of the three.

Think of it like a delivery company. One van (one disk) is slow and, if it breaks down, the parcel is stuck. Run several vans and you can either split each order across them to deliver faster (striping), send a duplicate van behind every order so a breakdown loses nothing (mirroring), or keep a spare van loaded with enough information to reconstruct any one lost load (parity). RAID levels are just named recipes for which of those tricks you use.

On Linux, you build these arrays in software with `mdadm` ("multiple devices admin"). The kernel exposes the result as a `/dev/mdN` device you partition, format, and mount like any disk.

mdadm --create takes a list of member block devices and bonds them into a new /dev/mdN. You tell it the level (the recipe) and how many devices participate. Here we build a RAID 5 across three disks.

Once an array exists, `/proc/mdstat` is your single window into its health. The kernel keeps this file live: which disks are members, whether any are missing, and — crucially — how far along a rebuild or initial sync has progressed. After creating a parity array, or after replacing a failed disk, watch this file until it reports clean.

Here is the step learners forget — and the one labs love to grade. Creating an array assembles it for the running system only. At the next boot, the system scans for arrays to bring up, and it consults `/etc/mdadm.conf` (on some distros /etc/mdadm/mdadm.conf) to know which arrays it should expect. If your array is not listed there, it may not assemble — or may come back under a different device name like /dev/md127, breaking any /etc/fstab entry that named /dev/md0.

mdadm --detail --scan prints exactly the ARRAY line the config file wants — UUID, level, and device count. You append it to the config so the description is on record.

Picking a level is a trade between three things: speed, usable capacity, and how many disks you can lose without losing data. Here is the mental model for each common level:

• RAID 0 (stripe) — data split across all disks for maximum speed and full capacity, but zero redundancy. Lose any one disk and the whole array is gone. Pure performance, for data you can afford to lose.
• RAID 1 (mirror) — every disk holds an identical copy. Survives losing all but one disk, but you pay half (or more) your capacity for it. Simple and very safe.
• RAID 5 (single parity) — striping plus one disk's worth of parity spread across the set. Survives one disk failure; usable capacity is (N−1) disks. A common balance of capacity and safety, but a rebuild after a failure stresses the remaining disks.
• RAID 6 (double parity) — like 5 but with two parity blocks, so it survives two simultaneous failures; usable capacity is (N−2). The safer choice for large, slow disks where a rebuild takes so long a second failure is plausible.
• RAID 10 (stripe of mirrors) — mirror pairs, then stripe across them. Fast and redundant: survives at least one disk per mirror pair. The premium choice for databases — you pay half your capacity, like RAID 1.

The one-line rule of thumb: *0 = speed, 1 = safety, 5 = balance, 6 = balance with a wider safety margin, 10 = speed and safety (at a price).*

RAID gives you bigger, safer storage on one machine. iSCSI lets a machine serve raw block storage over the network so another machine can use it as if it were a local disk. The serving side is the target; the consuming side is the initiator.

Think of it as renting a storage unit by mail. The target is the storage facility; a LUN (Logical Unit Number) is one specific unit it rents out; the IQN (iSCSI Qualified Name, like iqn.2026-06.com.example:storage.disk0) is the globally unique address printed on the door; and the ACL is the access list at the front desk — only an initiator whose own IQN is on that list gets the key.

You configure the target with `targetcli`, an interactive shell. The build order is always: backstore → target (IQN) → LUN → ACL.

On the client (the initiator) you use `iscsiadm`. The workflow is two beats: discovery (ask the target portal what it offers) then login (actually attach a LUN). After login, the remote LUN appears in lsblk as an ordinary new disk like /dev/sdX — at which point you partition, format, and mount it like any local device.

First, the initiator's own identity. Its IQN lives in /etc/iscsi/initiatorname.iscsi, and it must match the ACL you set on the target — otherwise login is refused.

Now treat it like a disk — but mount it with one special option. Because the device only exists after the network is up and login succeeds, a normal /etc/fstab line would make the system try to mount it too early at boot and hang. The `_netdev` option tells the system to wait for the network first.

iSCSI is not the only way to put a remote disk on a local device node. NBD (network block device) is a much smaller protocol built into the Linux kernel: a server (nbd-server, TCP port 10809) offers one or more named exports, and the client (nbd-client) attaches one of them to a local `/dev/nbdN` device. From then on it is an ordinary block device: blkid, mount, mkfs and fsck all work on it. Every read and write travels over the network to the server.

There are no IQNs or ACLs to match here. You need three things: the server's name, the export name, and a free /dev/nbdN on the client. The nbd kernel module creates /dev/nbd0 upwards (modprobe nbd if they are missing).

Surviving a reboot takes two files. /etc/nbdtab tells the system what to attach: one line per device, <device> <host> <export> [options], with the device written without /dev/. With that line in place, nbd-client nbd0 attaches it by name, and on a systemd host systemctl enable nbd@nbd0 does that at boot. Then /etc/fstab mounts the filesystem, with `_netdev` for the same reason as iSCSI: the device does not exist until the network is up and the client has connected.

You have a real root shell. These commands are read-only — they report on whatever storage exists without building or breaking any array. Run them to make the concepts concrete; if there are no md arrays here, the first command says so plainly.