[comp.unix.xenix] Changing To Different Hard Drive Size

dpj@wybbs.UUCP (Deloy Johnson) (06/17/88)

With new and larger hard drives coming on the market almost daily the
situation of upgrading to a larger drive has been occuring more and 
more often.  
My question is :  Is there an easy way to transfer your entire system (dump)
backup onto the larger hard disk or must you use "tar" to backup any necessary 
files and then go through the tedious process of putting your operating system 
back together from the distribution disks.  

Another situation is where a hard drive fails and the replacement disk is
larger than the original -- Can you use an archive type backup tape to
restore and still make use of the entire disk?

I am currently using an Altos 386 Series 2000 running Xenix System V/386.
In the Altos "restore" script it reads the file system size (and swap size)
from the dump tape.  It then uses these numbers as parameters to "mkfs".
Can I override the numbers it gets off the tape and specify a bigger
filesystem, and if so will the operating system use the space that the 
tape doesn't fill?  I guess I'm not exactly sure what the recover program
does at it's lowest level.

Any answers or suggestions???

DPJ

caf@omen.UUCP (Chuck Forsberg WA7KGX) (06/20/88)

A dump/restor cycle should work perfectly even if the file systems are
differnt sizes.  Of course, things get tricky if you are doing this to
the root file system - you need to make a boot floppy with dump/restor,
etc.

It is also possible to do a directocopy onto a larger file system, then
change the super block to reflect the larger disk size, finally an
fask-s to regenerate the free list.  Of course, you can't increase the
number of inodes that way.  And it may take longer to learn how to do
this trick than use one of the other methods.

Since I beta test new versions of Xenix, I have learned to keep a
/usr/local directory with subdirectories that correspond to /usr/bin,
/usr/lib, etc.  This mirror tree structure contains links to the
"real" programs and files that are unique to my installation.  When I
cut over to a new version or a different disk, I dump my /u files
and /usr/local plus a few other directories, and I'm ready to pull the
big switch.  With this tactic (and a tape drive) I'm up and running
on the new environment in a few hours (modulo getting HDB uucp to
behave).

jack@turnkey.TCC.COM (Jack F. Vogel) (06/21/88)

In article <314@wybbs.UUCP> dpj@wybbs.UUCP (Deloy Johnson) writes:
>My question is :  Is there an easy way to transfer your entire system (dump)
>backup onto the larger hard disk or must you use "tar" to backup any necessary 
>files and then go through the tedious process of putting your operating system 
>back together from the distribution disks.  
 
Why do you find the installation of a couple of disks tedious?? There is no
need to go through the complete installation. What I do is install only the
basic runtime, link kit, and backup package; then relink the kernal (in order
to link the tape driver in), reboot and restore from tape. This can be done
in less than an hour provided you don't do the disk scan. Do not use tar for
complete filesystem backups, use cpio (or afio) since it handles /dev,
FIFO's ,and  empty directories whereas tar does not.

>Another situation is where a hard drive fails and the replacement disk is
>larger than the original -- Can you use an archive type backup tape to
>restore and still make use of the entire disk?
>
>I am currently using an Altos 386 Series 2000 running Xenix System V/386.
>In the Altos "restore" script it reads the file system size (and swap size)
>from the dump tape.  It then uses these numbers as parameters to "mkfs".
 
My advice is to avoid this script or something like dump (which is what it
sounds like). If you use cpio you will have no problem restoring a system
to a larger drive since it does not muck around with the superblock. For
this very reason restore will obliterate an active root file system and
running from floppy (so root isn't active) is a royal pain in the arse!!


					Hope this has been of help,



-- 
Jack F. Vogel
Turnkey Computer Consultants, Costa Mesa, CA
UUCP: ...{nosc|uunet}!turnkey!jack 
Internet: jack@turnkey.TCC.COM