Quoting webmaster@datazap.net (webmaster@datazap.net):
> Hi,
> 
> I would like to clone an Amiga hard drive. The new drive is double the
> size of the old drive. This drive will have my / and usr partition on it. The
> system is a production server and takes over a 100,000 hits a day. So, I

It's a different drive.  Without being pedantic, "clone" brings up
the image of exact duplication.  You want to "MOVE" the data from
one drive to another.  It seems minor, but leads to entirely different
techniques.

I've done this a lot over the years, for several Unixes.


TWO first paths:
1) Boot from old disk.  Setup and partition the new disk, perhaps
   even with a new/fresh install that you will toss later.  Perhaps
   test that it boots from this second disk - just as a throwaway.
   It did?  Good.  Skip past next para.

2) Less downtime:  Take your development/test box, install NetBSD
   onto it.  Make sure it boots.  Now the disks are formatted right.
   Continue.


Now you want to boot from the original disk and MOVE the data to the
new disk.  The machine can be mostly live.
"newfs" the NBSD partitions on the new disk.  Mount them under,
hmmm, /NEW/  as needed (/NEW and /NEW/usr and /NEW/var, etc).  Now
the new disk is clean and ready to be written.

You offer tar and pax.  Use dump/restore.  You tar/pax to files
that you don't have room for.  Don't use files, use pipes.

And where are your backup tapes for this "production system"
You CAN build a new machine from tapes...  If you can't, you
should be able to.  DataZap indeed.


Dump(8) each partition to STDOUT and pipe into a restore.
For the /, try
  dump 0af - / | (cd /NEW; restore -rf -)

(check the dump options, I'm looking at another BSD's manpages; level
0, autosize, to file STDOUT)

Repeat for all filesystems.  Then make what you need to make bootblocks.

STOP!  If it was in production and stuff was being written to during
the dump, take a second.  With the "new" disk mounted under /NEW...
for each filesystem run "rsync -avHx --delete / /NEW/"
(trailing / is important).  This says: without traversing mount
points, rsync and keep hard/softlinks, delete missing files and
make /NEW/ the same as /.  Do this for /usr/ & /NEW/usr/,
/var/ & /NEW/var/, etc.

Note that / really shouldn't change during production - just apps
running.  I expect logs, databases and perhaps other data to vary,
but not the configs or binaries things.  (reason # 35 why /usr
and / are not the same partition as /var/ and other data partitions).

Unmount all of /NEW, pull the disk and test boot it on your
test system.

ELSE pull the orig disk and boot from the new one.

If you don't have a test/devel system, then you do.  You just don't
have a production system.

> will need to make this work the first time with the least amount of down
> time. I think that I can clone it, but there are a couple of things that I
> am not sure of. There seemed to be alot of talk about this on several
> message boards lately, but none have answered some of my questions. I am
> going to give an example of how I think I should do this, please feel free
> to jump in and let me know if there is an easier way, or let me know if I
> am flat out wrong.
> 
> 1) partition the hard drive with HDToolBox.
> (what I am unsure of here is on the new hard drive what do I set the
> future root partition dostype to. 0x4e425207 or 0x4e425507)
> 
> 2) use newfs to put a file system on it
> 
> 3) copy the files to the new drive.
> (This is where I am really unsure. In most examples that I have seen they
> say to use dump|restore. but I can't find an example that does not use a
> tape backup system. Also, I am not sure if this method will work with
> port-amiga. Plus, I don't have enough room left on the old hard drive to