Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!kiwi!zaphod!parker
From: parker@zaphod.mpr.ca (Ross Parker)
Newsgroups: comp.unix.ultrix
Subject: Re: copying "a" partitions
Message-ID: <2095@kiwi.mpr.ca>
Date: 20 Mar 90 04:07:31 GMT
References: <20692@dartvax.Dartmouth.EDU> <10238@cbmvax.commodore.com>
Sender: news@eric.mpr.ca
Reply-To: parker@zaphod.mpr.ca (Ross Parker)
Lines: 57

In article <10238@cbmvax.commodore.com>, grr@cbmvax.commodore.com
(George Robbins) writes:
> In article <20692@dartvax.Dartmouth.EDU> steve@avalon.dartmouth.edu
(Steve Campbell) writes:
> >      It used to be possible to make backup
> > copies of the root partition, 0a, by using dd(1) to copy /dev/r??0a to
> > /dev/r??1a or any other "a" partition.  This was fast (less than a minute
> > on RA81's) and on several occasions saved me many hours of work.  But now
> > with the disk partition table in the superblock, you can't use dd(1) this
> > way unless the two disks have identical partition tables, since the
> > tables get copied, too, and... 


> Yes, this is a problem.  The simple solution is just to standardize on
> parition sizes and drive types, at least between the system disk and the
> place you like to do your root backups.
> 
> I usually do an occasional tape dump and restore, but have used a pipe on
> occasion.  For a normal (7 or 15MB) root parition it's not that slow, and
> as far as I can remember doesn't require any "operator intervention"...
> 
> #! /bin/sh
> umount blah
> newfs blah blah
> mount blah
> dump 0f - / | (cd blah; restore rf -)


One additional 'gotcha' about the 'dd' method of copying a root partition:
If you're doing this on a BA123 Microvax-II, even if your partition tables
are the same, you can be in for a fair bit of work if you ever have a
power outage (and who doesn't :-( ).

We used to do this, until I found out (the hard way, of course) that the
BA123 does something slightly goofy when running power-up system checks,
namely, it checks each RD-type drive in sequence from the *high* numbered drive
down to the *low* numbered drive (eg. unit 0), and if it finds a bootable
pack (or what it deems bootable - presumably a disk with a boot block),
it will not check and will *LEAVE OFFLINE* any lower-numbered disks. When
this happened to us, we luckily had a DEC hardware guy in (doing something
else) - he was as mystified as we were at first, but after many phone calls
he finally found someone else at DEC who agreed that this was normal operation
for the BA123.

I don't know exactly what needs to be on the disk to cause the problem...
just making a file system on the 'a' partition will by default copy a boot
block there, so that can't be the only factor. It may be a combination of this
and some other factor (certainly the system doesn't understand what '/vmunix' 
is when doing power-up checks) that causes the bizarre behaviour. All I know
is that it took myself and our DEC guy about three hours to finally figure out
what the problem was.

I now use George's suggested method of dumping the root file system when I want
an on-line root backup (which isn't too often...).

Ross Parker				parker@mpre.mpr.ca
(604)293-5495				uunet!ubc-cs!mpre!parker