[Summary] Recovery backups to slightly different hardware

Thanks to everyone. [Original message at bottom.]

Essentially all had the same suggestion with slight variants -- Karl
Rossing from Federated Ins., CA; Claude Charest from Hydro-Quebec, CA;
Steve Beuttel from cox.net; Francisco from Ann Arbor, MI, US
(www.blackant.net); Michael Maciolek from world.std.com; Stan
Pietkiewicz from Statistics Canada; and Christopher Manly from Cornell
University.

I used Steve's suggestion, because he provided step by step detail that
accounted for idiosyncrasies of copying device trees:

     Assuming you're booted from the CD, and your "/" is mounted on
"/a", try:

     "cd /a"
     "mv dev <yymmdd>_dev"
     "mv devices <yymmdd_devices"
     "mkdir dev devices"
     "chmod 755 dev devices"
     "chown root:sys dev devices"
     "cd /dev; find . -depth -print | cpio -pdm /a/dev"
     "cd /devices; find . -depth -print | cpio -pdm /a/devices"
     "cd /a/etc"
     "mv path_to_inst <yymmdd_path_to_inst"
     "cp -p /etc/path_to_inst /a/etc/path_to_inst"

     Then reboot.

     -Steve-


Others suggested using devfsadm. I should probably look into that for
the future. However, Steve's method worked. I also did a touch
/a/etc/reconfigure for good measure.


---------------

Chris Hoogendyk

-
   O__  ---- Systems Administrator
  c/ /'_ --- Biology & Geology Departments
 (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst 

<hoogendyk@bio.umass.edu>

--------------- 

Erdvs 4




Chris Hoogendyk wrote:
> I have been trying to do a proof of concept and document the details to
> recover one of our critical servers in case it fails for some reason.
> (Just last month we had a building wide power snafu that caused untold
> $$$ damage. My servers survived, but the event instilled the fear of
> God, so to speak.) The server in question is a Sun Blade 100 (yeah, I
> know, it's not a Server) that is running our name services and for our
> internal network. If it goes down, the network starts falling apart.
>
> Anyway, most of our departmental servers are E250's, and we happen to
> have a few extra E250's for backup.
>
> Both of these systems are sun4u and we are running Solaris 9. I have
> backup tapes that are done using ufsdump from an fssnap snapshot piped
> through ssh to a remote tape drive on another server. I've used these to
> recover files and directories, but never had to do a full recovery. So,
> I figured I would grab a backup tape, a spare E250, plop some drives in
> it, and try to do a recovery.
>
> I started out by booting off the Solaris 9 install CD, formatting and
> partitioning c0t0d0 to match the boot drive on the Sun Blade, and then
> doing newfs and recovering all the partitions from the backup tape using
> ufsrestore. Everything seems to be there. I went into /mnt/etc and did
> `mv hostname.eri0 hostname.hme0` for each of the interfaces, 'cause I
> knew that would hit. Then I did the installboot, got back to the OK
> prompt and did a `boot disk:d` (that's where the root partition is). It
> goes through all it's stuff and finishes up with:
>
> -----------------------------
>
> Rebooting with command: boot disk:d
> Boot device: /pci@1f,4000/scsi@3/disk@0,0:d  File and args:
> Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
> FCode UFS Reader 1.12 00/07/17 15:48:16.
> Loading: /platform/SUNW,Ultra-250/ufsboot
> SunOS Release 5.9 Version Generic_118558-03
> 64-bit|\-/|\-/|\-/|\-/|\-/|\-/|\-/|\-/|\-/|\-/|\-/|\-/|\-/
> Copyright 1983-2003 Sun Microsystems, Inc.  All rights reserved.
> Use is subject to license terms.
> WARNING: status 'fail' for '/rsc'-/|\-/|\-/
> configuring IPv4 interfaces: hme0 hme0:1 hme0:10 hme0:2 hme0:3 hme0:4
> hme0:5 hme0:6 hme0:7 hme0:8 hme0:9.
> Hostname: pilot
> /dev/dsk/c0t0d0s1: No such device or address
> The / file system (/dev/rdsk/c0t0d0s3) is being checked.
> Can't open /dev/rdsk/c0t0d0s3
> /dev/rdsk/c0t0d0s3: CAN'T CHECK FILE SYSTEM.
> /dev/rdsk/c0t0d0s3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
>
> WARNING - Unable to repair the / filesystem. Run fsck
> manually (fsck -F ufs /dev/rdsk/c0t0d0s3). Exit the shell when
> done to continue the boot process.
>
>
> Type control-d to proceed with normal startup,
> (or give root password for system maintenance):
>
> -----------------------------
>
> When I went in and tried `format`, it said "no disks found".
>
> I rebooted off the cdrom, did `format`, and they are there.
>
> I actually did 2 more things in the process of debugging and getting to
> this point.
>
> I did `mount /dev/dsk/c0t0d0s3 /mnt`, went into /mnt/etc and did a
> `touch reconfigure`.
>
> I also went into /mnt/platform/SUNW,Ultra-250 and didn't find a "unix",
> whereas I did find it in /mnt/platform/sun4u. So, I did `mv
> SUNW,Ultra-250 SUNW,Ultra-250.orig` followed by a `ln -s sun4u
> SUNW,Ultra-250`. This got me past an earlier error, ... I think.
>
>
>
> So, now I'm stuck and not quite sure whether this is impossible or I'm
> just missing the magic trick. I thought since they were both UltraSPARC
> and sun4u that I would be able to do it. Any suggestions or insight
> would be much appreciated.
>
>
> ---------------
>
> Chris Hoogendyk
>
> -
>    O__  ---- Systems Administrator
>   c/ /'_ --- Biology & Geology Departments
>  (*) \(*) -- 140 Morrill Science Center
> ~~~~~~~~~~ - University of Massachusetts, Amherst 
>
> <hoogendyk@bio.umass.edu>
>
> --------------- 
>
> Erdvs 4
> _______________________________________________
> sunmanagers mailing list
> sunmanagers@sunmanagers.org
> http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers