Disk Imaging

[Daniel Hales]

Good Morning OALUG,

I have recently come across the need to swap out a hard drive in my Mythbox running MythBuntu.

I have a 320GB IDE drive that I'd like to replace with a 1TB SATA hard drive and yet retain all information and mount points on the IDE drive. I'd like to make the swap without the systems knowing anymore then it now has more space then it used to.

I believe this can be done with a decent disc image creation tool, but my version of Norton Ghost is too old.

I've run some quick searches and it looks like PING or R-DRIVE image would do about the same thing for me.

I'm curious if anyone has experience with these tools, or others, and if anyone has advice for making this swap as seamless as possible?

Thanks
Dan S. Hales

[Christian Horne]

uhh, well, you shouldn't use something that will copy the partition
information, or maybe even the filesystem headers, because then then
it will be trying to use a uuid on a different drive, and in my
experience that means bad things *will* happen. however, 'cp -a
/path/to/old/hard/drive/mount/point/
/path/to/new/hard/drive/mount/point' from knoppix or similar should be
good enough for you (-a is like -r but retains permissions as well).
do this as root of course, so that root's permissions will stick
around as well. don't forget to reinstall grub to the mbr.

--the blendmaster

--
the blendmaster

[Jonathan Karras]

Doing what Christian mentions is exactly how I upgraded my drive 3
times in my MythTV box.

Plug old and new drive into another linux machine (or use knoppix).
Partition and create file systems on new HD. (I keep my video files on
a second partition so they don't fill up root. I also use JFS instead
of ext3 for that partition)
Mount old and new drives as needed.
Use cp -a as mentioned
cp -a /mnt/olddrive/ /mnt/newdrive/

Then run grub on the new drive so its bootable. Put new drive in
system and boot it up.

Jonathan

[brandon]

Christian Horne wrote:
> uhh, well, you shouldn't use something that will copy the partition
> information, or maybe even the filesystem headers, because then then
> it will be trying to use a uuid on a different drive, and in my
> experience that means bad things *will* happen. however, 'cp -a
> /path/to/old/hard/drive/mount/point/
> /path/to/new/hard/drive/mount/point' from knoppix or similar should be
> good enough for you (-a is like -r but retains permissions as well).
> do this as root of course, so that root's permissions will stick
> around as well. don't forget to reinstall grub to the mbr.
>

I always use tar, it also preserves most devices.

cd current/dir
tar -p --selinux -cf - | tar -C /new/dir -xpvf -

I'll leave it as an exercise to see what all the flags do--but this,
imho, is the safest way to copy files :)

-Brandon

[Jonathan Karras]

One other note. One time I didn't have video's I cared about and the
drive was failing. So I deleted all the movies so the DB was clean.
Then followed the procedure below but instead of cp just did a tar
file of the root until I was able to get a new drive. Then I applied
the tar file down to the new drive and all was happy.

Another thing I just did on my desktop was use rsync to copy the old
setup to a new disk. That way I could do the majority of the copy one
day. Then a in a few weeks when I was actually ready to pull the drive
I would rsync again and only do an update which was much faster. I
went from a 2 drive setup with multiple partitions to a one drive
setup with root and home partitions that way. Also like Daniel
mentions rsync will preserve the devices but that's not as much of an
issue with udev as it used to be.

Jonathan

[Jonathan Karras]

Ok sorry about the reply to my self again. But I said Daniel and meant Brandon.

Jonathan

[Aaron Toponce]

As already mentioned in this thread, if you use a disk imaging utility
of different drives, bad stuff can potentially happen. At least
theoretically. However, I personally have run disk imaging utilities to
copy one drive to many simultaneously to different computers using
multicast, and I have not had any problems.

On the flip, if you deploy a disk imaging solution to clone your drive,
then it will copy every last bit-for-bit, including the MBR containing
the partition table. That means that your 1TB drive will only be
partitioned for 320GB. And, if that 320GB drive has 4 primary
partitions, you have some work ahead of you getting the fourth
partition, presumably an extended partition, to get to the end of the
disk. Not hard, just work.

I would avoid any disk cloning utilities, like CloneZilla, Norton Ghost
and the like, and do what has already been suggested thus far.

* Boot off a live media, like Knoppix.
* Identify and mount up the old drive.
* identify, partition, format and mount up the new disk.
* Copy over the data partition for partition
* Install an MBR (GRUB, LILO, etc) to the new drive.
* Test

--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O . O . . O O O O . O O O

[Daniel Hales]

Thank you!

Sounds like I'd have wasted many hours in unnecessary imaging efforts...

Tell me if my actual setup will change any of the steps... I'm not changing the primary hard drive but a secondary storage unit mounted at /usr

Here is my setup:

frodo@frodo-desktop:~$ cat /proc/partitions
major minor #blocks name

8 0 156290904 sda
8 1 979933 sda1
8 2 58597087 sda2
8 3 2931862 sda3
8 4 93779437 sda4
8 16 312571224 sdb
8 17 312568641 sdb1
frodo@frodo-desktop:~$ df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 57677528 6884728 47862948 13% /
tmpfs 1547996 0 1547996 0% /lib/init/rw
varrun 1547996 336 1547660 1% /var/run
varlock 1547996 0 1547996 0% /var/lock
udev 1547996 160 1547836 1% /dev
tmpfs 1547996 0 1547996 0% /dev/shm
lrm 1547996 2192 1545804 1% /lib/modules/2.6.28-15-generic/volatile
/dev/sda1 964500 81512 833992 9% /boot
/dev/sda4 92306948 2383968 85234012 3% /home
/dev/sdb1 312437568 229054952 83382616 74% /usr

I intend to swap the sdb1 drive for another. sdb1 is currently an IDE drive (so the "s" in sdb1 is a surprise to me... but hey) and I will be installing a SATA drive in its place to be mounted at /usr point.

Thanks again!

Dan S. Hales

[Michael Heath]

This is even simpler to do; basically, the steps already mentioned
apply, but you don't necessarily need a LiveCD as you're not playing
with the primary drive.

However, if you're planning on removing the existing IDE from the
system when you're done, you need to watch out: theres a possibility
that Linux will remap the drives so that they have different letters.
For example, say you plug in your new drive, and it gets added as sdc.
You copy everything over, and then adjust your partition table so that
sdc is being mounted as /usr rather than sdb. You then power down the
system, and unplug the drive that was sdb - but, now that sdb is
missing, Linux might remap what WAS sdc to sdb, messing up your new
partiton table.

Other than that, it should work pretty well.

Mike Heath

[Christian Horne]

"...that Linux will remap the drives so that they have different letters."

Different Letters!? sdx comes from a spot in a slot, not a name! this
isn't C:,D:,etc!

there is a chance that real serial-whatever comes before emulated
serial-whatever (as sdb is for you) though, in which case you *may*
need to change the grub config file and /etc/fstab to match. however,
depending on the distro, it may even do this for you. most newer ones
seem to.

--
the blendmaster

[Christian Horne]

oops, duh. i meant that if you remove sdb, sdc will only become sdb if
sdc was a usb drive. otherwise, it was sdc because it was in slot 3,
not because it was drive 3.

--
the blendmaster

[Aaron Toponce]

Device letters aren't assigned based on the slot they are connected to,
but the order on which they are connected. If you plug in a drive, and
sda and sdb has already been assigned, but sdc hasn't, then it will get
sdc. If you remove sdb, sdc will stay sdc unless you remove it and
reinsert it, and which point it will then become the new sdb. While they
are not C:, D:, E:, they are treated in the same manner.

--=20
=2E O . O . O . . O O . . . O .
=2E . O . O O O . O . O O . . O

[Christian Horne]

no they arent, not for real ide anyway. scsi may do that at the
hardware level, but ide has four slots.

--
the blendmaster

[Aaron Toponce]

Christian Horne wrote:
> no they arent, not for real ide anyway. scsi may do that at the
> hardware level, but ide has four slots.

This is pre-2.6.20, when the pata driver was still used. Since then, all
IDE devices and SCSI devices are using the sata driver, which identify
the devices as /dev/sd*, and are assigned in the order on which they are
discovered on the board, not the slot number.

--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O

[Christian Horne]

oh, i didn't know the ide-scsi thing discarded the slotting
convention. my bad :)

--
the blendmaster