Migrating to LVM

Question

The drive on my Ubuntu media server is nearly full. I hope to add another 2TB of capacity to the machine and would prefer for all 3.5 TB to be recognized as a single drive. To complicate things, I don't want to lose any of the data on the drive or have to reconfigure any programs.

My plan was to use LVM to create a volume group on the new drive an use dd to copy the contents of the old drive. Then I plan to erase the old drive and add it to the volume group.

Will this plan work?

My biggest questions are: -Will dd be able to copy my installation to another drive without problems? Even if its a volume group? -Will dd be able to copy a 1.5TB drive to a 2TB drive and leave the remaining space free.

Answer 1

If you're already using LVM:

• Make sure the new disk is mounted and partitioned for LVM (toggle LVM bit)
• Create a PV on the new disk (pvcreate /dev/your-new-disk)
• Extend your VG to include the new PV (vgextend your-volume-group /dev/your-new-disk)
• pvmove your data from the old disk to the new. No need for dd. (pvmove /dev/your-old-disk will force LVM to move the data from the old disk to any other available disk.)

If you're not already using LVM:

• Create a PV and VG on the new disk.
• Copy your data into a new LV in the new VG.
  I would use dump+restore if available for your filesystem, but you can use cpio or tar or even dd if you want.
• Format the old disk, turn it into a PV, add it to the VG.

---

^{The following is somewhat opinionated and has nothing to do with LVM.}

• ^{dump+restore:}
  • ^{Operate on the raw block device, so source atime etc. is unaffected and destination ctime etc. can be set correctly.}
  • ^{Preserves all hardlinks, and should understand filesystem internals well enough to preserve all extended attributes, security policies, and other filesystem-specific metadata.}
  • ^{Source and destination can be of different sizes; only copies in-use data.}
  • ^{Should be the fastest method.}
• ^{cpio/tar/rsync/cp:}
  • ^{Operate on mounted filesystem, so source atime is changed, destination ctime cannot be preserved, inode numbers change, etc.}
  • ^{Preserving hardlinks requires keeping all known inodes in memory, and may or may not be done correctly. Tool may or may not understand filesystem well enough, or have privileges, to preserve extended attributes, security policies, and other filesystem-specific metadata.
    (For example, ext4 supports sub-millisecond timestamps, but as far as I am aware, none of these tools preserve them.)}
  • ^{Source and destination can be of different sizes; only copies specified data.}
  • ^{Spends a lot of time in syscalls (stat, opendir, readdir, closedir, mkdir, open, read, write, close, …).}
• ^dd:
  • ^{Is an exact copy of raw block device.}
  • ^{Copies all blocks, whether in use or not.}
  • ^{Duplicates all filesystem structures, including things which should be unique (such as UUID).
    Can't mount both (by default) at the same time on the same system if they're XFS.}
  • ^{Cannot resize during copy.}
  • ^{Comparatively slow if the filesystem was not very full.}