David Christensen <dpchr...@holgerdanske.com> writes: > AIUI the OP was mounting an (external?) drive partition for use as a > destination for backups. Prior to upgrading to Testing, the root > partition was /dev/sda1 (no LVM?) and the backup partition was > /dev/sdb1 (no LVM?). After upgrading to Testing, the root partition > is /dev/sdb1 and the backup partition device node is unknown. The OP > was confused by the changed root partition device node. > > > Please describe how LVM would help in this situation.
Instead of using /dev/sdb1 directly for the backup file system, the OP could put LVM to /dev/sdb1 (or now /dev/sda1). I.e. he would create a physical volume on /deb/sdb1, create a volume group e.g. named vgbkup, and would then create a logical volume, e.g. named lv1. The device name for the backup file system would then always be /dev/vgbkup/lv1 regardless of how the kernel will name underlying device (/dev/sda1 or /dev/sdb1 or whatever). In addition, you get the flexibility of LVM of adding, deleting, and resizing volumes without re-partitioning. If the OP had done that before he hadn't noticed the change from /dev/sdb1 to /dev/sda1 as he hadn't used that name. He could now change to LVM and never deal with changing physical device names again. Whether it's an internal or external drive doesn't matter. My backup drive is an external USB-3 hard drive with 1 partition containing the whole disk space of 4 TB. That partition contains volume vgroup "vg2" with currently one logical voulume "snap" of 2 TB and I mount /dev/vg2/snap to /var/snapshots for backups. Currently I don't need more than these 2 TB but I could easily extend the logical volume or create new ones for backups of my other machines or virtual machines. And I actually forget the physical device name of the vg2 volume group (I have just looked it up using vgdisplay(8), and it's currently /dev/sdf1). urs
