Any way to mount partitions of cloned drive without reboot?
 

I have just cloned a drive (/dev/hda) to an identical backup drive (/dev/hdb) using dd. I would now like to mount a partition (hdb5) of the backup drive without rebooting.

An inspection with fdisk shows that the partitions exist on hdb:

Device Boot Start End Blocks Id System
/dev/hdb1 * 1 13 104391 83 Linux
/dev/hdb2 14 268 2048287+ 82 Linux swap
/dev/hdb3 269 395 1020127+ 83 Linux
/dev/hdb4 396 14593 114045435 5 Extended
/dev/hdb5 396 14593 114045403+ 83 Linux


But none of the partitions show up with 'ls /dev' (i.e. only /dev/hdb is shown, not /dev/hdb5). I tried the following, based on the output of a call to MAKEDEV with the '-S' flag:

# mknod -m 0640 /dev/hdb5 b 3 69
# chown root:disk /dev/hdb5

But trying to mount gives the following:

# mount -t ext3 /dev/hdb5 /mnt/hdb5
mount: /dev/hdb5 is not a valid block device


So:
(1) Is there any way to mount hdb5 without rebooting?
(2) If I were to reboot, will the partitions get recognized automatically?
(3) If I do reboot, is hdb going to be a problem since it is bootable? (I think I want this so if hda goes bad I can just replace it with hdb)

I'm running CentOS 4.

Thanks

Hmmmm, the mknod was a nice try :)
I know nothing about CENTOS, but "modern" linux distros create entries in /dev/ on the fly.
I suspect something hasn't woken up to the fact that you have created partitions on /dev/hdb with the dd command

Normally, when something hasn't woken up to changes you restart the relevant service (eg you have changed ssh_config, you restart ssh, and the changes are picked up).

But what needs to be restared here? udev ? hal ? and I have never tried restarting one of these on a running system, as udev and hal are pretty vital!
A reboot would seem to be the easiest, but you say you do not want to do this.

Are you sure those major & minor numbers are correct?
On my machine:
Have you tried the makedev command?

Sorry, but I am now out of ideas :(
Welcome to LQ though!

Edit: I only answered your first Q. So here goes...
They usually are.
Not a problem. Grub works out what is bootable.
Grub (or your bootloader) was on hda, you dd'd hda to hdb, so now grub is also on hdb. Swap the drives & you should be fine. Try it ;)

Thanks tredegar.

Yeah, I originally tried running makedev, which created 32 devices: hdb1 - hdb32. I deleted those and just tried the mknod's that were spit out by the makedev command, for hdb1-5. So I used the major and minor numbers given by makedev, but no dice.

I've since bailed on this attempt and simply created identical partitions using fdisk and am now going to rsync the data partitions. While I may not be able to completely swap hdb in for hda if hda fails, at least the data will be backed up...

There may have been some problems with the dd copy anyway, given that the disk wasn't quiesced during the cloning process.

Exactly! You are unlikely to make a successful image if the disk is in use (and therefore the bit/byte-level data is changing = can lead to inconsistencies & chaos).

If you want to try dd again, boot from a live cd, and do the work from there, whilst the partition you are interested in is unchanging.

If you want to use rsync, then by all means use that, but again, it's better to sync a disk that is not being used - ie either run rsync from a live CD, or make sure you have a free partition on your main disk with a simple linux installation just for "housekeeping" the important partitions (which may be on different hdds). I do the latter because it is faster than running from a live CD, and it is always there on my boot menu in case of an "Oops!". If the "Oops" is so bad that I cannot boot to my rescue partition, I know I can boot from a (slower) live CD, and retrieve my data and OS, to a new hdd if necessary.

The big advantage of rsync is that after the first copy, subsequent syncs are very fast as only the differences between the two filesystems are corrected. You need to be very careful with the options to rsync though! I'll leave you to experiment, with this one warning:

You need a real test of your backup strategy:

Once you think you have a backup, pretend you have lost your data (eg take out the primary disk). Now, can you get your data / OS back?

18y ago I installed and set up a big Oracle database under SCO unix. It was stable, it ran fine it was gooood. I thought I had the (tape) backup strategy well & truly fixed, until we really needed to restore from tape after a power failure (yes, we had UPSs & generators & stuff, but there was a sufficient glitch to hose the system).

Only then did I realise that I had done it stupidly and it did not work as I expected it to. Two hours of panic later, I had resolved the issue, but I wished I had had the sense to test my backup strategy before it was needed! This doesn't mean "Can I see my backup files?", it means "Can I get my system running again without having to peek at my (supposedly failed) disk?"

So, my strategy is this:
When I think it's time for a backup (actually I think it's time after I finish this post!), I boot to my backup-distro, where I have a script to mount the partitions I need to backup and then rsync them to an external disk. Then I'm done :)

Unless the external disk fails :mad: Unlikely, but possible.

I wish I knew the backup strategy of banks / airlines etc. How do they keep their systems up and running 99.9999% of the time? They cannot just say "System going down for 10Hrs for a backup!". I think it is a complex field (and I am not an IT expert!).

Good luck with your experiments & eventual strategy.