I have two (old) identical servers running RHEL5. One has failed and I have decided to clone the other to restore the failed box.

I ran dd with this command on the healthy server from a live CD: the process ran without issue and reported that the amount of data I would have expected was successfully copied to the external HDD. I can view the contents of the drive from file manager, doesn't look like anything useful to me, but there is data.

When I move that HDD to the failed machine and want to copy it back (running live CD) that server does not even see the drive.

Did I miss something in the dd process? I have never done this before. Thanks for any input.

You copied disk to a partition, should be "...of=/dev/sdb" (assuming the target disk is the same or larger).

ah man. ok so adding that 1 made it a partition? rather than a dd data file?

As I understood the sdb1 was the mount point of the drive, and should have been the target? but the 1 should not be apart of the of= target?

sda is an entire drive. When you dd it you dd some areas like bootloader and maybe other places. It is a copy of the readable area of the entire disk.

While you can copy it to a second drive (sdb) and further copy it to a partition on that second drive it ends up being putting the wrong data in the wrong place.

If you do really want to make an exact copy of sda it makes me further wonder one important thing. You don't want to clone a booted drive. You usually clone a disk by booting to some live media. Then the drives need to be correctly identified as to source and destination. sda may not be source.

Booting to clonezilla may work and should be more safe.

Even without knowing anything about whole thing this should raise a red flag as not logical. You want to clone, then you do it sda1 to sdb1 (partition to partition) or sda to sdb (drive to drive), otherwise it can't be a clone.

Are the disk drives "identical?"

The disk drives do not have to be "identical".
The destination must be equal or larger in size as the partitions sizes can be adjusted after the fact to fit the physical space.

To the OP.
It seems you wanted to make a disk image that then could be copied back to the drive in the second system.

My suggestion is that you have two choices.
1) Do a direct disk to disk copy by connecting both drives in the same machine and doing the copy with "dd if=/dev/sda of=/dev/sdb bs=64M " as it seemed you intended to do with the command you used.
2) The alternative, which will take at least twice the time, would be to use dd to create an image file of the source disk then write back from the image to the destination disk.
Creating the image involves having a drive mounted with adequate disk space to contain the image, then creating the image with dd using a command like
then writing the image file to the destination disk with
Note that I added a bs (block size) part to the command. The default block size for dd is 512 bytes and adding the part as I did means it takes 128000 reads at default size to equal one read with the bs=64M option added to the command. A major saving in time for reading and writing the disk image.

Not at all - data is just data. The OP states it is merely temporary usage to allow the target disk to be moved over and the image copies off. Most might use an output file, but it's certainly not required.
The issue is:What does this mean - it doesn't mount or it doesn't appear as a device node under /dev ?. Let's see relevant lines of dmesg on the target machine.

This was the process I was going for. I will retry adding the .img

hmmm. I am not sure what to look for in dmesg. I did a dmesg | grep sda and got the following:

I would expect sda1,2,5,6,7 based on the partitions of the other system. but I dont know about 3 and 4. I do not see the drive when I do a df -h, and from the graphical interface the device is not present in "Other Locations" of the file manager, as the other system is.

would I expect the drive to look like sdb1 in /dev?

From the liveCD on the target let's see

1 members found this post helpful.

I cant copy text from the source, so I have attached a screen snip.

Attached Thumbnails

 

If none of the drive partitions are attached to the file system (mounted) then the file system utilities like df and the file manager will not be able to see them.

You could use the command "mount" to see what is actually mounted and active.
You can use "sudo fdisk -l" to list all disks the computer has configured and their details, including sizes and partitions defined as well as the type of filesystems on the partitions.

In my earlier post I noted the "of=/mountpoint/image.img".
This is actually a file to be created at some location in the file system you choose, not a literal "/mountpoint/". You will need to select where to create that actual image file and it will have to be in a part of the existing file system, not a device (unless you are doing a disk to disk copy)

Looking at the image you posted, the live USB you booted from appears to be /dev/sdc.
/dev/sda appears to be a fully configured drive, with sda4 being the extended partitions and sda5-7 appear to be extended partitions. /dev/sdb has one partition but no details are given. "sudo fdisk -l" will give more info than "lsblk" (and in a different way).

I am guessing that sda may be the drive you are copying from and sdb may be the drive you are wanting to copy to. If this is the case then the command you used earlier was (almost) correct.
"dd if=/dev/sda of=/dev/sdb bs=64M" would be a good way to do the actual disk to disk copy.

If you want to do the copy disk to image then when running the live image you will need to attach another disk that you can mount and actually copy a disk image to. The live image you are booted to only has the amount of memory in the system that you can write to, and that certainly will not be enough for a full disk image to be stored.

I beg to differ.
If that thumbnail was from the target, then the disk has been recognised, but /dev/sdb1 can't be mounted as it's the dd'd image. Given statements in the first post, this will restore that image onto the target - simply reversing the initial command.

1 members found this post helpful.