# Moving harddrives

## silwerspawn

of course we all have the fstab.

but I just unmounted a drive to be more exact sdb the /mnt/TvShows-Music:

```

/dev/hda1       /boot                   ext2    noauto,noatime          1 2

/dev/hda3       /                       ext3    noatime                 0 1

/dev/hda2       none                    swap    sw                      0 0

/dev/sdg1       /mnt/System             ext3    defaults                0 0

/dev/sdf1       /mnt/Movies             ext3    defaults                0 0

/dev/sde1       /mnt/AnimeA-G           ext3    defaults                0 0

/dev/sdd1       /mnt/Games-Music        ext3    defaults                0 0

/dev/hdb1       /mnt/Programs           ext3    defaults                0 0

/dev/hde1       /mnt/Anime              ext3    defaults                0 0

/dev/sda1       /mnt/Anime2             ntfs    defaults                0 0

/dev/sdb1       /mnt/TvShows-Music      ext3    defaults                0 0

/dev/sdc1       /mnt/Anime3             ntfs    defaults                0 0

/dev/hdf1       /mnt/Downloads          ext3    defaults                0 0

shm             /dev/shm                tmpfs   nodev,nosuid,noexec     0 0

```

my trouble is now that alle the other harddrives have jumped one step down, so sdc1 is now sdb1, and sdd1 is now sdc1 etc.

this is not good karma for a server. 

is there somehow i can lock the drives to their position?

----------

## linuxtuxhellsinki

You can start to use LABELs or UUIDs on partitions   :Exclamation: 

This is from tune2fs's manpage.

```
-L volume-label

Set  the  volume label of the filesystem.  Ext2 filesystem labels can be at most 16 characters long; if volume-label is longer than 16 characters, tune2fs will truncate it and print a warning.  The volume label can be used by mount(8 ), fsck(8 ), and  /etc/fstab(5) (and possibly others) by specifying LABEL=volume_label instead of a block special device name like /dev/hda5
```

For UUIDs you'd check manpage of uuidgen and you can check 'em with..

```
# vol_id /dev/hda1

ID_FS_USAGE=filesystem

ID_FS_TYPE=ext3

ID_FS_VERSION=1.0

ID_FS_UUID=ce5fbbf5-cb7a-4fb2-805c-97954d093f7e

ID_FS_UUID_ENC=ce5fbbf5-cb7a-4fb2-805c-97954d093f7e

ID_FS_LABEL=boot

ID_FS_LABEL_ENC=boot

ID_FS_LABEL_SAFE=boot
```

----------

## silwerspawn

Thanks that worked out well..  :Very Happy: 

Now the system is running smooth.

----------

## VoVaN

Though, it's not that easy as the solution in the previous post, but LVM would be an option for you as well and it's much more flexible with many hard drives (see some sexamples below). 

```

..snip..

/dev/vg/usr             /usr                    ext3            noatime,barrier=0                               0 0

/dev/vg/var             /var                    ext3            noatime,barrier=0                               0 0

/dev/vg/tmp             /tmp                    ext2            noatime                                         0 0

/dev/vg/src             /usr/src                ext3            noatime,barrier=0                               0 0

/dev/vg/opt             /opt                    ext3            noatime,barrier=0                               0 0

/dev/vg/games           /usr/share/games        ext3            noatime,barrier=0                               0 0

```

```
>lvs -o +devices

  LV      VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert Devices

  data    vg   -wi-ao  27.13G                                       /dev/sda3(5416),/dev/sdb3(5416)

  games   vg   -wi-ao   9.31G                                       /dev/sda3(4224),/dev/sdb3(4224)

  home    vg   -wi-ao  10.00G                                       /dev/sdb3(768),/dev/sda3(768)

  media   vg   -wi-ao 115.00G                                       /dev/sdc2(512)

```

```
>pvs

  PV         VG   Fmt  Attr PSize   PFree

  /dev/sda3  vg   lvm2 a-    73.47G  32.75G

  /dev/sdb3  vg   lvm2 a-    73.47G  32.75G

  /dev/sdc2  vg   lvm2 a-   233.52G 116.52G

```

----------

## linuxtuxhellsinki

 *VoVaN wrote:*   

> Though, it's not that easy as the solution in the previous post, but LVM would be an option for you as well and it's much more flexible with many hard drives. 

 

And you might loose everything when one drive breaks.

----------

## VoVaN

 *linuxtuxhellsinki wrote:*   

>  *VoVaN wrote:*   Though, it's not that easy as the solution in the previous post, but LVM would be an option for you as well and it's much more flexible with many hard drives.  
> 
> And you might loose everything when one drive breaks.

 

Well, it all depends on design...

----------

## linuxtuxhellsinki

Ok, so what would be left (or lost) if you'd loose sda at that your example ?

And if you've volumes which are spreading to two drives and other one breaks down, could you recover any of the data from that volume and with which tools  :Question:          (this question is because I would like to know how to do it)

----------

## VoVaN

 *linuxtuxhellsinki wrote:*   

> Ok, so what would be left (or lost) if you'd loose sda at that your example ?
> 
> And if you've volumes which are spreading to two drives and other one breaks down, could you recover any of the data from that volume and with which tools          (this question is because I would like to know how to do it)

 

As I mentioned already, that was just an example... Of course, it's not possible (generally speaking) to recover your data in the case you mentioned. Anyway, I think in the right design LVM is a great tool, but this topic about design is out of the scope, IMO.

----------

## lyallp

As an additional note, with LVM, you can also use labels.  :Smile: 

----------

