Storage Management Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

Capacity, failure, and the name of the disk

Storage planning starts with two numbers and a failure you can stand. How much usable space you need, and how many disks you can lose without the volume going offline. RAID is a way to arrange those disks. It is not a backup. A file deleted on a RAID volume is deleted on every member. The backup guide is the copy that survives a mistake. This page is the volume that survives a disk.

RAID 1 mirrors. Usable space is about one disk, and one disk can fail. RAID 10 stripes mirrors. It wants an even count and survives a failure inside each mirror, not any two disks. RAID 5 and RAID 6 trade space for parity. RAID 5 survives one failure. RAID 6 survives two. A rebuild on a large disk is a long, heavy read of every survivor. That is a reason to prefer RAID 6 or RAID 10 when the disks are large and the volume is the only copy of the week, even though RAID is still not the backup.

LVM sits above disks or above RAID and hands you logical volumes you can extend. Physical volumes are the disks or partitions you add. A volume group collects them. A logical volume is what you format. The filesystem is a third layer. Growing a logical volume does not grow the filesystem until you do that step, and growing the filesystem does not create a backup of what was on it.

Disk names such as /dev/sdb move when hardware moves. The serial and the by-id path do not. Every ticket that will partition, create an array, or run pvcreate names the serial you read from the label and from the host. If those two strings disagree, you stop. The wrong disk is the outage people remember.

A lab volume with a written capacity, not a surprise

Suppose the ticket asks for about 2 TB usable and survival of one disk failure, on disks of 2 TB. RAID 1 on two disks gives about 2 TB and survives one failure. Four disks in RAID 10 give about 4 TB and a clearer rebuild. RAID 5 on three 2 TB disks gives about 4 TB and survives one failure, with a rebuild that reads the other two. The RAID calculator on this site turns those choices into a capacity. It does not touch a disk. You still pick the failure story.

The lab uses disks you can wipe because they were blank when you installed the host. You record the serials in the ticket before any create command. You do not type a device node from a blog. If a command would initialise a disk, the serial in the command's own listing matches the ticket, and a second person reads both.

An LVM layout for that space is one volume group and one logical volume for the data, plus the boot path the installer already made and that you do not resize in this window. The filesystem type is the one the backup tool can restore. Extending later is a new ticket: lvextend, then the filesystem grow, then df. You do not extend because the command was available.

After the volume is mounted, df shows the size you expected, and a test file written and read back is the proof. The backup guide then gets a first copy. A volume with no backup is a volume you are not finished with, even if the RAID is healthy.

Layout	Survives	Usable space, roughly	Watch
RAID 1, two disks	One disk	One disk	A rebuild is a full copy
RAID 10	One disk in each mirror, not any two	Half the disks	Even disk count
RAID 5	One disk	Disks minus one	Long rebuild on large disks
RAID 6	Two disks	Disks minus two	Write penalty, calmer rebuild
Single disk	Nothing	The disk	Not a RAID decision. It is a backup decision

A change you can finish

The change window for a new volume is: serials checked, calculator result in the ticket, create on those serials only, filesystem, mount, test file, backup job pointed at the mount. A resize of a volume that already has data adds a backup taken before the resize, and a practise restore is already true for that data.

Rollback of a new blank volume is to stop using it and wipe only the disks whose serials you just initialised. Rollback of a resize is the backup. You do not invent a resize rollback at 2 a.m.

Write usable size and the failure you must survive.
Run the capacity through the RAID calculator and paste the result.
Read serials from the host and match them to the physical labels.
Create or extend only those members.
Make the filesystem or grow it, then mount, then df.
Write and read a test file as the service user.
Point the backup at the mount and take the first copy before you call it done.

Mistakes that outlive the command

storage fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Calling RAID a backup and skipping the restore test.
pvcreate or an array create on /dev/sdb because a guide used that name.
RAID 5 on very large disks as the only copy, then a second failure during rebuild.
Growing the logical volume and forgetting the filesystem, so df still shows the old size.
Resizing a full production volume with no recent restore test.
One volume group that mixes the disk you can lose and the disk you cannot, with no note.
A mount in fstab by a name that will change, instead of a UUID you recorded.
Filling the volume to 100 percent and discovering the journal and the logs die with it.

Decisions to write down before the window

One decision for storage: Usable capacity and the number of disks you can lose are both in the ticket. The calculator result matches them. Members are serials. Device nodes are a hint you recheck on the day. RAID is not the backup. The first backup runs before users depend on the volume. The filesystem is one the restore procedure already uses. A new filesystem type is its own decision. Boot devices are out of scope for this window unless the ticket is about the boot device and you have console access. fstab uses a UUID or a by-id path you copied from the host after the volume existed. A grow is two steps, volume then filesystem, and df is the proof of the second. Free space stays above the number you will alert on. The performance guide is what a full disk feels like. A second person read the serials aloud before any initialising command. Rollback is written: abandon a new blank volume, or restore from backup for a resize. And the LVM command builder's draft was trimmed to these serials. Extra commands in the draft were deleted.

Storage checks before users depend on the volume

Confirm this before you call the change done: Calculator output is in the ticket and matches the layout you created. Every member serial was read back from the host after creation. df shows the size you expected on the mount you expected. A test file was written and read as the service user. fstab has a UUID or a stable id, and a mount -a was tried in the lab. The backup job names this mount. Boot disks were not members unless that was the change. No command ran against a serial that was not in the ticket. Free space is above the alert line. A second person heard the serials. The rebuild or degrade story is one sentence you can say without the calculator. A restore of the test file was done from the backup, not only a backup job that exited 0. The previous fstab line is in the ticket if you changed one. The hostname in the prompt matches the hostname in the ticket for storage. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for storage happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: Cloud: Storage Cost Calculator.