From OCAU Wiki
LVM - Logical Volume Manager
Migrating drives sucks. You've all been there: your workstation or server disk is full, and the users are bitching that they want more space. You know buying a bigger file server costs money, and the migration is a headache.
Linux LVM is a virtual layer that sits over any device. It can live on top of real hard disks, USB hard disks, MD RAID devices, iSCSI and Fibrechannel connects, etc, etc. What it does is create a virtual disk over the top of the physical disks which can be created, destroyed, resized or extended in a few simple commands.
So, lets look at a real-world scenario. I have a graphic design client who chews through disk space like a fat kid goes through ice cream. I built them a Linux server (with SAMBA and LDAP for Windows and Mac file sharing and Domain log-ons). In it I put 2x 80GB hard disks in a Linux-software RAID1 mirror for boot and OS (called /dev/md0 by Linux), and 4x 320GB hard disks in a Linux-software RAID5 stripe+parity (giving them 960GB of space - one disk's worth of space is lost to CRC, but it means they can lose one disk out of the set and keep working without data loss). This is called /dev/md1 by Linux.
Now here's where the smarts come in. Over the top of the 960GB set, I put LVM (which Linux calls /dev/mapper/data, containing one drive called /dev/md1 (which is really 4 drives, but LVM doesn't care). On top of that, I put a normal Linux file system, and then share it all via SAMBA. Each morning, users log on to their Windows workstations, and see their network server share (mapped to drive S:\ in Windows) as 960GB of space.
6 months later, the disk is full! What the hell these guys do, I don't know, but hey - it's their business and not mine. They want more disk space! What to do?
Simple. I run out and buy another 4x320GB SATA hard disks. I plug them into the Linux box. I tell Linux MD RAID to combine them as a single RAID device /dev/md2. I then tell LVM that /dev/mapper/data now extends across two hard disks, /dev/md1 and /dev/md2. Tadaaa! /dev/mapper/data jumps from 960GB to 1920GB (1.9TB - Terabytes). I "unmount" the Linux file system, tell it to resize itself to fill up the rest of the disk, and remount. In 15 minutes, the users now have double the disk space, and there was no need to migrate data to new servers!
LVM has another neat trick called "snapshotting". This is a means of pausing a file system and taking a "snapshot" in time of it's contents. This snapshot can be stored on spare space at the end of the disk, or compressed as an image and sent to another server. If your server blows up, you can either repair it and restore from the image, or simply fire up the image on your spare server, give it the same network details and all of a sudden it's running on a different box, yet none of the users know the difference! Remembering again that Linux servers store all of their config data in plain-text files. No need to restore registries or other complex binary-only files that you can't read. Reconfiguring a server is a matter of overwriting some plain text files and rebooting!
Again, visiting my earlier comment about having a site office become a server room in under an hour. And again for the Microsoft Windows Server users, remember that all of what I describe costs $0 in software. None of what I describe here is Linux-only by any means. But all of what I describe here costs tens or even hundreds of thousands of dollars in software, licensing and proprietary hardware (most of which is built on embedded Linux/BSD anyway).
So that's part 2 of my enterprise Linux intro. Part 3 is coming later, and will cover virtual machines, virtualisation, hypervisors, and a way to use Windows Server and Linux together and not need to worry about drivers and hardware dramas ever again.