Hi everyone,

Here is my setup:

ServerA
Seagate 72GB

ServerB
Seagate 72GB

I accidentally used some other 3rd party software and used their labeling tool and labeled the root disk of serverA (now it won't boot...stupid me). ServerA and ServerB are *exactly* the same (hardware, partitions, hard-drive geometry, CPU, mobo, RAM) except for the ip configurations.

I need to clone the hard-drive in ServerB to ServerA. How would I do this? I google'd and found out that since the harddrives are the same geometry and model, you just need to do:

This copies the "backup" tag. So, I'm going to put ServerA's hard-drive into serverB. But how do I copy the boot block? If put the 2nd hard-drive back to ServerA, would it boot? Do I need to format it or label it? I'm a bit lost.

PS. I would like to do this with dd. Thank you so much!

-twantrd

dd the drives at init 1 or off a floppy. Yes, your boot information is copied.

Oh, you have to do this in single user mode? Why? Also, I don't have a floppy so that's why I'm placing the hard-drive in ServerB.

Another question is, why just /dev/rdsk/c0t0d0s2? Why not the other slices? Thanks for the help!

-twantrd

You don't need to specify the partition because you don't want to clone a partition. You want to clone a disk. And that's the hardware allocation of the disk. Btw, I'm not a Solaris guru. I thought I was replying to the linux section. But dd is the same throughout as far as I know.

And you use single user mode because you don't want any files in use as you attempt to clone them. Just SOP.

s2 is (unless you twiddle with you vtoc) spanning the whole solaris partition, so dd'ing it will effectively copy everything on the Solaris fdisk partition.
It won't restore the mbr though.
To restore it, you can do something like
or if you really want to use dd, you can try either one of:
btw, I'm assuming you are running Solaris on x86 or x64 hardware, the previous doesn't apply to SPARC.

Hi Jlliagre,

Thanks, I'll try those and test it out? Unfortunately, I can't do this in single user mode because ServerB is active serving connections. Would it be *very* unwise to do a dd when a server is under run level 3?

Also, this is on sparc. Thanks for the help guys!

bash-2.05# uname -a
SunOS jones 5.9 Generic_117171-07 sun4u sparc SUNW,Sun-Fire-V240

-twantrd

Ok, I was thinking you were running Solaris on x86 as mostly everyone on this LinuxQuestions forum is doing so.

Forget my previous advice (fdisk or writing p0), the command and the device are x86 specific.

I would be very unwise to do a dd from or to a mounted partition actually, even in single mode ... an fsck would maybe recover should you do it if you manage to stop anything running though.

If you are on SPARC, you also need to copy the label (fmthard) and boot block (installboot), parameters may differ slightly too.

See http://cspry.co.uk/computing/SUN_Bla...00_backup.html for an example of similar work.

Hi Jlliagre,

Thanks for the quick response as always . On the link you provided, they use fmthard and installboot when they are doing ufsdump/ufsrestore. But I'm using dd. The links says I don't need to do installboot as a separate step if done in dd. So far I have done:

dd if=/dev/rdsk/c1t0d0s2 of=/dev/rdsk/c1t2d0s2

Still waiting for this to be finished. Then the document says that I should probably fsck this which I will do once it's done. Then I should be good to go yes?

-twantrd

Right, slice 2 is enough to copy a whole SPARC ufs disk, unless you have an EFI labeled disk, which is unlikely.

By the way, you could have increase the copy speed by specifying a larger blocksize than the default (512 bytes), e.g. dd if=... of=... bs=128k

Too late for that one ...

Look here to see what Sun's documentation says about it:

http://docs.sun.com/app/docs/doc/805...6q7uf21?a=view

Thanks for your help. Wow, default is 512 bytes. That would take years on a 72GB hard-drive. So I killed the process and added bs=128k to it. Now, IO is much much higher and I probably saved a couple days! Thanks for the help..

-twantrd

Yes, dd default block size was set in the seventies, when 512 bytes was a serious amount of data, and 72 GB storage was requiring many thousands of hard disks ...

It never changed for upward compatibility reasons.