[ale] hd duplication --quick response requested--

John M. Mills jmills at jmills.gtri.gatech.edu
Tue Sep 8 14:51:40 EDT 1998


Ari -

That sounds like an improvement on my suggestion.

 -jmm


On Tue, 8 Sep 1998, ari wrote:

> well, if you need the computer up at all times, you most probably have a
> network card.
> 
> hook up your similar hard drive to a similar system, hook that system up to
> the network, install a base net install of whatever distribution/unix/etc is
> on the original system (if it's linux, it's still best to stick with the same
> distribution on the two systems, as distributions like redhat 5 use glibc2,
> oollllddd linux systems use a.out, etc),

I would say that was a necessity if he intends to just copy all the /etc files,
with regard to init and any directory-tree variants.  That's where I would
expect the distribution dependencies to become important.

> mount it through nfs (taking all due
> security cautions), make sure all partitions are mounted properly the way you
> want them to be, and
> 
>   cp -rdp <original system root dir> <new system root dir>
> 
> on the new system, run lilo, reboot, transfer your network cables to it, and
> voila.  the network is down for maybe 10 - 30 seconds.
> 
> if you'd rather use tar instead of cp, and use ftp to transfer one hd's info
> to the other, use

One advantage of 'tar' would be not having to export any file systems, but he
would have to establish 'rsh' priviledge on the remote.  Another advantage is
that no new installation would be required, in case he has modified the
"vanilla" setup or important base utilities.

>   tar -zcpf <dir_tree.tar.gz> <dir tree>
> 
> then transfer <dir_tree.tar.gz> over to the new system, and extract it in its
> proper place, using

Well, with the network approach the separate, compressed tar may be
unnecessary:

tar cpf - `cat <file_list>` | (rsh -l <remote_user_name> <remote_host> \
 cd <mount_point_of_new_disk_on_remote_host> ";" tar xvpf - )

and let 'er rip.  (I think the ";" avoids escaping from the remote shell, but
may be wrong on that, and it presumably depend on his [local] shell.)

Note that <file_list> should have been built from the original "/", and should
prefix each path with "./" to avoid dropping trash on the remote's fs root.

>   tar -xvzpf <dir_tree.tar.gz> -C </proper/place/>
> Note that these examples are for GNU tar and cp only... bsd variants use
> slightly different commands.
> 
> if you don't have / can't afford to have an extra system laying around for
> your mirror, it's not SO important that the original can't be off for 15 mins
> or so in the middle of the night while you replace the drive (or if you can't
> even copy the files over from another system, it might take you one or two
> hours).
> 
> ari
> 
> John M. Mills (jmills at jmills.gtri.gatech.edu) said this stuff:
> 
> > You say, "I need the computer up at all times."  Unless you are willing to
> > risk destroying the new disk, or have one of those "hot install" disk
> > holders ("hot shoes") like those by Kingston (I don't know if they do IDE
> > models, or only SCSI.), you will need to drop power to install the
> > replacement, and you probably should reboot once you've completed the
> > changeover even if you come up with a mechanism which might avoid it. 
> > 
> > As to populating the new disk, I would do the following:
> > 1) Make a master file list, and use it to tar selectively everything
> >    which needs to end up on the new disk, onto your backup medium --
> >    consult 'man tar' how to copy links without copying their target files,
> >    and how to preserve ownership and permissions.  I use 'find' on the
> >    appropriate branches, then trim by hand to get the filename file for
> >    your 'tar'.  For starters, you will probably kill the top-level entries
> >    of the form "./<blah_blah>/" (directories) and keep those of the form:
> >    "./<blah_blah>/<yip_yip>" (actual files).
> > 
> > 2) Install the new disk on a computer you _can_ shut down (or one equipped
> >    with disk "hot shoes" - you probably want to install a couple of those
> >    on your "unstoppable" platform, no?), partition it as appropriate,
> >    mount on some suitable mount point, and 'untar' the backup onto the new
> >    specimen.  For ext2 partitions, I think this is transparent, but Win95
> >    installation may require Win95 tools to copy entire.  When you're done,
> >    I expect the new disk to have everything but its boot sector ready.
> > 
> > 3) Now, stop your "unstoppable" - sorry, you should have thought of that
> >    when you hard-bolted the original disk - install the new disk in its
> >    correct address (in a "hot shoe", plus a second one for future swaps?)
> >    boot from boot floppy (and make one quickly if you don't already have
> >    one!), rerun LILO, and reboot 'for real.'  If you have doubts about the
> >    copy operation, move the original disk to an unused address and mount
> >    its partitions selectively as you work through any kinks in your clone.
> > 
> > If you don't have convenient backup facilities, you can do all this on the
> > target platform at the cost of one more shutdown/reboot cycle: just put
> > the new disk at the unused address, build it there from the installed
> > disk, then swap them.  I think it may even be possible to run LILO on the
> > new disk before you shutdown, move it to its final home address, and
> > reboot, but I don't think I ever got that right the 1st time. 

> > On Fri, 4 Sep 1998, David Hamm wrote:
> > 
> > > I have an hd that is dying I suspect.  The problem is that I need the
> > > computer up at all times.  I have backups but I'd like to duplicate the hd
> > > to another hd that is simular but not exactley the same.  Whats the
> > > easiest and fastest way to do this?

  John M. Mills, Senior Research Engineer -- john.mills at gtri.gatech.edu
  Georgia Tech Research Institute, Georgia Tech, Atlanta, GA 30332-0834
        Phone contacts: 404.894.0151 (voice), 404.894.6285 (FAX)
         "The cardinal virtues of a programmer are Laziness,
            Impatience, and Hubris." -- attr. Larry Wall 






More information about the Ale mailing list