diskcopy from Ultra 60 to Blade 2500
Ritesh
I have a Sun Ultra 60 system on which, over the past several years, i
have set up Apache, MySQL, SVN and CVS servers, a tape backup system
and a host of other apps customized to my needs.
I'll be getting a new Sun Blade 2500 in a few days (yay!!) and i would
like to copy over the disks of the Ultra 60 to the new blank ones on
the Blade 2500, and I need help/suggestions regarding that. Both
systems have 2 disks, however, while the ones on the U60 are SCSI U160
(36 GB each), those on the B2500 are U320 (146 GB each). Also, the
ones on the B2500 are blank.
The following would be the ideal scenario: replace one of the disks on
the B2500 with the boot disk of the U60, boot off this disk and copy
the disk to the remaining blank disk on the B2500. Since the B2500
disk is four times as large as the U60 one, it will accomodate the
data from the other U60 disk also, which I can later copy to the
second B2500 disk.
It's the U160/U320 difference between the two disk types that's
bothering me. Although I haven't seen the U320 disks yet, my guess is
that those would be wider than the U160 ones, and I won't be able to
insert a disk from the U60 into the B2500 as i'm envisaging above.
The B2500 does have a internal U160 SCSI cable which I would later use
for the tape drive. Would it be possible to connect the boot disk from
the U60 to this cable and boot off of it?
Or maybe a net boot and disk copy via nfs? I would be very grateful
for suggestions and comments.
Ritesh
ThanksButNo
> Hi all,
>
> I have a Sun Ultra 60 system on which, over the past several years, i
> have set up Apache, MySQL, SVN and CVS servers, a tape backup system
> and a host of other apps customized to my needs.
>
> I'll be getting a new Sun Blade 2500 in a few days (yay!!) and i would
> like to copy over the disks of the Ultra 60 to the new blank ones on
> the Blade 2500, and I need help/suggestions regarding that. Both
> systems have 2 disks, however, while the ones on the U60 are SCSI U160
> (36 GB each), those on the B2500 are U320 (146 GB each). Also, the
> ones on the B2500 are blank.
>
> The following would be the ideal scenario: replace one of the disks on
> the B2500 with the boot disk of the U60,
No no no no no. WAAAAAAAY too much work.
Hook both machines together to a network switch, set up
their IP's addresses so that they can talk to each other
over the ethernet.
If you haven't got a network switch, buy one. A little 5 port
job is cheap, and a lot less hassle than getting a crossover
cable to go host-to-host direct. I can never find the danged
crossover cable when I need one, but the switch is always in
use and right there anyway. If you don't have a few spare
network cables lying around, pick up a few of those too while
you're at it.
Transfer the information you want from one machine to the
other using "rcp" or "scp", along with "tar" or "dd",
depending on how much you want to learn. ("dd" is supposed
to be good for disk to disk transfer, but I've never used it.)
Something like this:
On HostTiny:
Say you want the contents of /export copied over verbatim.
Recommend getting /etc/passwd and /etc/group for ownerships.
rcp /etc/group hosthuge:/tmp
rcp /etc/passwd hosthuge:/tmp
enter passwords as needed
On HostHuge:
Login as root
Edit /etc/group and incorporate new values from /tmp/group
repeat for /etc/passwd
cd /
ssh hosttiny "cd / ; tar cf - export" | tar xpvf -
eneter the password, sit back and watch the output scroll by.
Done.
Repeat for each directory that you're interested in.
Be careful of /etc, /usr and /var which may have hardware
specific files that you *won't* want copied over.
/:-/
ThanksButNo
Oh, and you might want /etc/shadow also, but you need to be
root to even *see* that file. Only, it might be configured
to not allow root to use rcp, which is Ok coz you can usually
use scp.
Alternately, once you've copied over /etc/passwd, just run
the "passwd" command for each new user to set their passwords
fresh. That may or may not be a pain, depending on how many
users we're talking about. More than 5, copy the shadow file.
Since I'm usually the only user on my toys, I just set the
password again. Customer boxes are a different story.
\:-\
Ritesh
router working in bridge mode (are you familiar with DD-WRT?). The
router has enough spare ports, so hooking up the two machines via
ethernet is not a problem. As I had mentioned in my original message,
the disks on HostHuge are blank, what I really want is essentially the
old OS (and all other data) running on the new hardware. As for
hardware specific data getting copied over, maybe a reconfigure boot
will take care of that. I had previously done a diskcopy using dd (the
entire disk, I didn't even partition the new disk) so I am inclined
towards that route. Of course the big difference between now and then
is that the two disks were then identical.
Btw, I don't think you could dd over a network: dd works at block
level, so the source and destinations have to be block devices.
Thanks a lot for taking the time to send in your suggestions. I really
appreciate...
Ritesh
ThanksButNo
>
> HostTiny is actually connected to a wireless router, the wireless
> router working in bridge mode (are you familiar with DD-WRT?). The
> router has enough spare ports, so hooking up the two machines via
> ethernet is not a problem. As I had mentioned in my original message,
> the disks on HostHuge are blank, what I really want is essentially the
> old OS (and all other data) running on the new hardware.
I guess I assumed the new machine would already have an OS
installed. My bad (never assume!)
> As for
> hardware specific data getting copied over, maybe a reconfigure boot
> will take care of that.
If the new machine comes with an OS installed, I would not
want to chance overwriting it.
I much prefer a system with the OS specially installed for
it -- I don't even want to have to worry about which files
and directories are custom-tuned to the hardware, and which
hardware-specific files were explicitly LEFT OUT -- I just
suggest being careful not to overwrite them. The *only*
source for the hardware specific stuff *might* be on the
installation CD/DVD.
>
> Btw, I don't think you could dd over a network: dd works at block
> level, so the source and destinations have to be block devices.
That should not be a problem. The network software works to
re-block the data the way it wants. Just so long as the dd
for output and dd for input match each other, the "Transport
Layer" should make everything else transparent.
>
> Thanks a lot for taking the time to send in your suggestions. I really
> appreciate...
No problemo -- this is a "comes around goes around" sort of
forum, so be sure to help others when you can!
\:-\