请问，两个硬盘数据如何对拷？

mgong

disk-to-disk copy under Solaris 2.X

[1.] Run format and partition the new disk. Example disks scenario is:
      c0t3d0 (running Solaris 2.x) being copied to c0t1d0 (which will have
      the copied Solaris 2.6 slices/partitions)

      c0t3d0s0 /     ->  c0t1d0s0 /
      c0t3d0s4 /var  ->  c0t1d0s4 /var
      c0t3d0s5 /opt  ->  c0t1d0s5 /opt
      c0t3d0s6 /usr  ->  c0t1d0s6 /usr
         
[2.] For each of the partitions that you wish to mount, run newfs to
     contruct a unix filesystem.
            
     So, newfs each partition.

     # newfs -v /dev/rdsk/c0t1d0s0
     # newfs -v /dev/rdsk/c0t1d0s4
     # newfs -v /dev/rdsk/c0t1d0s5
     # newfs -v /dev/rdsk/c0t1d0s6

[3.] To ensure that they are clean and mounted properly,
     run fsck on these mounted partitions:

     # fsck /dev/rdsk/c0t1d0s0
     # fsck /dev/rdsk/c0t1d0s4
     # fsck /dev/rdsk/c0t1d0s5
     # fsck /dev/rdsk/c0t1d0s6
  
[4.] Make the mount points.
     # mkdir /mount_point

     Create mountpoints for each slice/partition, like so:
   
     # mkdir /root2
     # mkdir /var2
     # mkdir /opt2
     # mkdir /usr2

[5.] Mount the new partitions.
     # mount /dev/dsk/c0t1d0sX /mount_point

     Mount each partition (of the new disk), like so:
   
     # mount /dev/dsk/c0t1d0s0 /root2
     # mount /dev/dsk/c0t1d0s4 /var2
     # mount /dev/dsk/c0t1d0s5 /opt2
     # mount /dev/dsk/c0t1d0s6 /usr2

[6.] Now we ufsdump each slices/partitions:
      It is often difficult to copy from one disk to another disk.  
      If you try to use dd, and the disks are of differing sizes, then
      you will undoubtedly run into trouble. Use this method to copy
      from disk to disk and you should not have any problems.

      Of course you're still on the old disk (that's where you
      booted from c0t3d0):

      # cd /
      (Just ensures that you are in the root's parent/top directory).

      # ufsdump 0f - /dev/rdsk/c0t3d0s0 | (cd /root2; ufsrestore xf -)
      # ufsdump 0f - /dev/rdsk/c0t3d0s4 | (cd /var2;  ufsrestore xf -)
      # ufsdump 0f - /dev/rdsk/c0t3d0s5 | (cd /opt2;  ufsrestore xf -)
      # ufsdump 0f - /dev/rdsk/c0t3d0s6 | (cd /usr2;  ufsrestore xf -)

      The gotcha here is that you can't really specify the directory name
      as ufsdump will interpret it as not being a block or character device.
      To illustrate this error:

      # cd /usr
      # ufsdump 0f - /usr | (cd /usr2; ufsrestore xf - )


        DUMP: Writing 32 Kilobyte records
        DUMP: Date of this level 0 dump: Wed Dec 10 17:33:42 1997
        DUMP: Date of last level 0 dump: the epoch
        DUMP: Dumping /dev/rdsk/c0t3d0s0 (tmpdns:/usr) to standard output
        DUMP: Mapping (Pass I) [regular files]
        DUMP: Mapping (Pass II) [directories]
        DUMP: Estimated 317202 blocks (154.88MB)
        DUMP: Dumping (Pass III) [directories]
        DUMP: Broken pipe
        DUMP: The ENTIRE dump is aborted

       If you want to use the directory names to simplify your command line,
       use the tar command instead of ufsdump as follows:

       Example:
      
       # cd /usr
       # tar cvfp - . | (cd /usr2; tar xvfp - )

[7.] OPTIONAL (This may be redundant BUT ensures that
      the copied files are once again clean and consistent).
      Checking the integrity of a filesystem is always highly
      recommended even if it becomes redundant in nature.
        
      Now, check and run fsck on the new partition/slices:

      # fsck /dev/rdsk/c0t1d0s0
      # fsck /dev/rdsk/c0t1d0s4
      # fsck /dev/rdsk/c0t1d0s5
      # fsck /dev/rdsk/c0t1d0s6

[8.] Edit your /mount_point/etc/vfstab file to have this disk
      bootup from the correct disk/devices c0t1d0 as opposed to c0t3d0.
   
      # cd /root2
      # vi /root2/etc/vfstab
      
      Change c0tXd0sX devices to reflect the new disk!

      #device         device                mount     FS      fsck   mount   mount
      #to mount       to fsck               point     type    pass  at boot  options
      #
      #/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2      /usr      ufs      1      yes      -
      fd                 -                   /dev/fd   fd       -      no       -
      /proc              -                   /proc     proc     -      no       -
      /dev/dsk/c0t1d0s1  -                   -         swap     -      no       -
      /dev/dsk/c0t1d0s0  /dev/rdsk/c0t1d0s0  /         ufs      1      no       -
      /dev/dsk/c0t1d0s6  /dev/rdsk/c0t1d0s6  /usr      ufs      1      no       -
      /dev/dsk/c0t1d0s4  /dev/rdsk/c0t1d0s4  /var      ufs      1      no       -
      /dev/dsk/c0t1d0s5  /dev/rdsk/c0t1d0s5  /opt      ufs      2      yes      -
      swap               -                   /tmp      tmpfs    -      yes      -
        
      :wq!

[9.] Now you must run installboot to load a new bootblk on
      that disk. Not loading a bootblk will leave this disk
      in an unbootable state as the boot strap program is
      contained within the bootblk, and this in turn is what
      loads the boot file called ufsboot after interfacing with
      the OBP (Open Boot PROM).
   
      You can do this from your current booted disk or you
      may choose to boot off from cdrom via
      ok> boot cdrom -sw (single-user mode, writeable mode
      off of cdrom's mini-root).

      If you choose to get bootblk from your current disk:

      The location of the bootblk in Solaris 2.5 or higher is under:
      /usr/platform/`uname -i`/lib/fs/ufs/bootblk
      while in Solaris 2.4 or lower it's at:
      /usr/lib/fs/ufs/bootblk
   
      # /usr/sbin/installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk    \      
        /dev/rdsk/c0t1d0s0
              
      If you choose to get bootblk from your cdrom image:
   
      ok> boot cdrom -sw

      # installboot /cdrom/solaris_2_5_sparc/s0/export/exec/sparc.Solaris_2.5 \  
        /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0txd0s0

      ANOTHER SPARC EXAMPLE:

      To install a ufs bootblock on slice 0 of target  0  on  con-
      troller  1,  of the platform where the command is being run,
      use:

      example# installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk  \
               /dev/rdsk/c1t0d0s0

[10.] Now create an alias for the other disk (this may be existent if
      it's off of the onboard/first scsi controller).
   
      ok> probe-scsi
     
          T3  original boot disk
          T1  new disk with copied slices
        
      Verify via devalias command to see current aliases:
      disk1 is for sd@1,0 which is scsi id/target 1
     
      ok> devalias   
            
      ok> setenv boot-device disk1
      ok> boot -rv
     
      (You do not necessarily need to do a reconfiguration boot as devices
      had already been created. This parameter will only be run if you attached
      new devices to your system).
      
      By default this will always boot from the new disk. If you want to boot from   
      the old disk you can manually tell it to boot to that alias, like so:
  
      ok> boot disk
      or
      ok> boot disk3
   
      (This will boot off from any Target 3/scsi id 3 internal disk).
     
      Also see INFODOC #'s 14046, 11855, 11854 for setting different
      boot devalias'es.
     
      NOTE: If the new disk encounters a problem on booting, most likely cause
            would be inappropriate devlinks so, the  course of action to
            take here is the /etc/path_to_inst, /dev, /devices fix:
         
      The following is a solution to solve problems with /dev, /devices, and/or
      /etc/path-to_inst. This routine extracts the defaults (with links intact)
      from the Solaris 2.x CD-ROM.

      ok> boot cdrom -sw

      # mount /dev/dsk/c0t1d0s0 /a    ** This step assumes your boot disk is         
                                         c0t1d0s0

      # cd /tmp/dev
      # tar cvfp - . | (cd /a/dev; tar xvfp - )
      # cd /tmp/devices
      # tar cvfp - . | (cd /a/devices; tar xvfp - )
      # cd /tmp/root/etc
      # cp path_to_inst /a/etc/path_to_inst
      # reboot -- -rv


[11.] If you plan to move this new disk you copied the OS on, you
      MUST ensure that it will be moved to a similar architecture
      and machine type as hardware address paths are usually
      different from one machine to another.