SUMMARY: Backup drive 0 with another drive...

From: Dave Doherty (
Date: Wed May 05 1993 - 17:00:31 CDT

Sorry for the late summary, I wanted to try this out before I posted the summary, but I have have not had a change to do it yet.

Orignal Request:
I have a Sparc 10 that recently had a disk failure that I could not
recover from. As a result, the system was down most of the day while I
waited for then rebuilt a replacement 424MB drive 0.

Not wanting to go through that again, I ordered a spare 424MB drive that I'm going to install as a backup drive 0.

I plan on partitioning it the same way as the current drive 0. (/, /usr, /var)
                                                                a g h

My question is:

     1) What is the best way to make a bootable backup of drive 0 onto
        this new drive (sd3 for example)

     2) What is the best way to keep it current. Ideally, I would like
        some perl or csh script that I could run with cron, say at
        least once a week (not much changes on this drive).

     3) Will all this work OK - am I missing anything? The plan would
        be to simply change the boot device and boot from sd3 if sd0
        failed. The only file that I can think of that I would need to
        change is /etc/fstab to say "/dev/sd3a is /" for example rather
        than sd0a. Anything else?


I think I'm going to try one of the "dd" examples, or look into Online: Disk Suite from Sun.

Hope I got everyones reply


>From Fri Apr 23 14:35:38 1993
First, copy the partitions with 'dump', e.g.:

1) mount /dev/sd3a /mnt
        cd /mnt
        dump 0f - /dev/sd0a | restore -rf -

2) We do this sort of thing with 'rdist'.

The biggest gotcha is #3: make sure that the /etc/fstab file points
to the correct / and /usr partitions. You also need to install
boot blocks on this disk with the 'installboot' command.

>From Fri Apr 23 15:57:39 1993
Hi there,
        I think I have an easy solution for you. Let's say your new disk
is sd3 and it's the same model as sd0 (type SUN0424) you could use the
following command in your crontab:

        dd if=/dev/rsd0c bs=1024k | dd of=/dev/rsd3c bs=1024k

        This will copy the entire disk as an image (including partitioning
information). You don't have to partition the disk before using this command.

        I would suggest that instead of changing fstab, if you have a crash,
remove (or unplug) the failing sd0 and change SCSI adress of sd3 to SCSI
adress 3 (this will make it sd0). After the system has rebooted, disable
the cron command that copies the disk. Then, when your replacement disk
arrives, just plug it in as sd3 and reactivate the cron command.

>From Fri Apr 23 17:36:49 1993

I have used dd to keep a current copy of root on another drive. Use
dkinfo to see the size of the root partition (a) and make sure that the
target root copy partition is the same size. Say the size is 16080 blocks,
then dd if=/dev/rsd0a of=/dev/rsd3a bs=16080b will do it.

This could be done daily via cron. I'm assuming that /var/tmp and /tmp
are symlinked to someplace else, so root is pretty static.

>From fitz@FRC2.FRC.RI.CMU.EDU Fri Apr 23 17:40:51 1993

I believe Sun sells software which will do this on the fly. I think it
is called Online: Disk Suite or actually mirrors the
info from one drive to another.

>From Fri Apr 23 18:22:33 1993
        I believe you would also haver to change the eeprom setting to make it say sd3 rather than sd0 as your default boot device.

>From Fri Apr 23 20:58:46 1993

        Greetings from down route 9. You asked about how
you could keep two 424's identical, so that you could boot
from the redundant copy in case of failure. I wish I had
the budget to consider an approach like this...

        Before coming to HyperDesk in March, I worked as
a Unix & network consultant on Wall Street for about a
year. At two sites we had a need to quickly rollout new or
replacement workstations. We deployed a system to do this by
attaching an external disk, booting from it, duplicating it
to the internal disk, fixing up the fstab, et viola! The
whole procedure took under a 1/2 hour.

        As long as the two drives you intend to do this with
are *identical* - both Seagate ST1480N's for instance - then
you can just: boot by hand from the external, install the
appropriate partition table, dd one 'c' partition to the
other, mount the new root and fix /etc/fstab, reboot from
the internal disk.

        In these environments we checked in /etc/rc.local for
a flag that indicated the machine was unconfigred, and if so
we asked some questions, edited some files, and rebooted. In
your case I think all you'd want to do is fix /etc/fstab.

>From Sat Apr 24 07:47:43 1993

If you want to make them exact duplicates, the disks are identical, and
/dev/sd?c is a partition that covers the whole disk, then you can
        "dd if=/dev/sd0c of=/dev/sd3c bs=32k"
with sd3 unmounted (sd0 had better be in a stable state). Then fsck all
of the partitions on sd3. Finally mount sd3a and fix the fstab.

                        --- Truck

>From Sat Apr 24 13:58:06 1993

I'd go for

dd if=/dev/rsd0c of=/dev/rsd3c bs=8192k

as the answer to both these questions (the bs value is rather arbitrary
- a big value makes it go faster, but uses more memory - of course if
you set it higher than available physical memory it will probably go
*slower*). Not "optimal" perhaps, since it will copy the parts that
haven't changed too, but real fast. I recently copied my news partition
this way, ~900MB on an IPI disk, in ~15 min.

The dd will "deal" with the partition table (i.e. copy it too) for sure,
and unless I have seriously misunderstood something, should take care of
installboot too.

I think an even simpler solution is to change the SCSI target ID of the
backup (and the original, unless it is removed of course) - no need to
change either boot device or fstab (and doing the latter when your
original has failed will be a (minor) pain).

>From rdsun!!mikeba@uunet.UU.NET Sat Apr 24 21:08:10 1993

One method I have used in the past is to "dd" the "c" partition from
one disk to another. This makes an exact, bootable copy of the disk.
The disk should be quiescient, preferrably unmounted or in single user
mode to minimize the posibility of copying a file system that is being
modified by another process. However, if you can schedule a dd to happen
late at night or some other time when you know there is very little
activity, you should be ok. After the dd, you will have to have a script
go in and modify the fstab as you point out in 3). My experience has
been that it takes about 15 minutes to dd a sun 424 MB disk. It is very
important to set the block size high enough to maximize throughput. I
don't know what the "best" theoretical block size is, but I normally
set it to (# sectors * # heads) so that the dd copies one full cylinder's
worth of block at a time. i.e. "dd if=/dev/sd0c of=/dev/sd3c bs=712b"

Please note that dd makes an exact copy, including bootblock code,
disk label, and all fragmentation. In your case, it will work because
you have an identicle disk with the same partitioning, etc. Note also
that by dd'ing the c partition you will also copy the b partition,
but if this is too "inneficient" for you, you can issue two dd's, one
to do the a partition, one for the g.

>From ups!kalli!kevin@fourx.Aus.Sun.COM Sun Apr 25 07:15:09 1993

1) Use On Line Disk Suite and mirror it.

2) Same answer - mirror it with OLDS.

3) Not really - you will have to boot from a different device as well.

>From Sun Apr 25 15:22:16 1993

     Two gotcha's that you have to look out for are 1) make sure that
installboot has been run on the backup disk after installing or
updating the /boot file, and 2) make sure the fstab file on the backup
disk reflects the different location (i.e. s/sd0/sd3/g).

     The best way to create the backup disk is to do a dump of each
partition of the master disk and pipe it to a restore on the backup
disk. This should be done with the system in single user mode. Make
sure you run fsck on the backup partitions and remove the
restoresymtable files.

  After this, a script that fsck's each partition on the backup,
mounts it, and does an rdist from the master partition to the mounted
backup should keep them up to date. Getting the rdist to work
correctly may take the most work, because there is no convenient way
to limit rdist to only what is on the local system (i.e. ufs

>From Mon Apr 26 02:26:31 1993

How 'bout a dump | restore for each partition there is?

2) Run the above at 2 am each day, that should keep it fairly current.

I would not bother. Chances are that you would miss something. Rather,
when the failure does happen, yank out sd0, change the address of sd3, and
away you go. I think that would be easier than to find all sd-whatever
dependancies you and your users might have on that machine.

>From Mon Apr 26 10:51:42 1993

I would back it up disk-to-disk like this:

mount /dev/sd3a /mnt
mkdir /mnt/usr
mount /dev/sd3g /mnt/usr
mkdir /mnt/var
mount /dev/sd3h /mnt/var

cd /
find . -xdev -fstype 4.2 -print | cpio -paudm /mnt
cd /usr
find . -xdev -fstype 4.2 -print | cpio -paudm /mnt/usr
cd /var
find . -xdev -fstype 4.2 -print | cpio -paudm /mnt/var

This will copy all the files, preserving permissions and symbolic links, etc.
Then you have to fix up /etc/fstab like you said. But you forgot about the
boot block. It will have to be fixed as well, like this:

cd /usr/kvm/mdec
./installboot -vl /mnt/boot bootsd /dev/sd3a

These could be put in a script and called from cron whenever you want.

>From Mon Apr 26 12:45:05 1993

Dump sd0's partitions to sd1's. Do an installboot to make it bootable.

I think the simplest ways are the best. Incremental dumps and restores
sound simple.

Fstab, and exports might be candidates for a sed script to change sd0 to
sd3 where needed.

>From Jason.Hargis@PII.COM Mon Apr 26 13:28:04 1993

        Look into "Sun ONLINE: DiskSuite 1.0"

>From ted@ssl.Berkeley.EDU Mon Apr 26 14:41:16 1993

If the drives are identical, you can probably say
  # dd if=/dev/sdoc of=/dev/sd3c
When one of our drives began to fail, the Sun s.e. did that to copy
the data from that drive to the new one.

This moves the partition table and everything.

>From Mon Apr 26 19:13:13 1993

 Have a look at rdist(1). This will allow you to simply automate the
 transfer and/deletion of new/old files without a great deal of
 trouble. After running rdist simply run a simple script to modify
 /etc/fstab as below and all should be fine.

>From Thu Apr 29 08:12:56 1993

Be sure to have exactly the same parameters on both drives (same format.dat
entry, same parameters to newfs)

I would go for dump/restore:
# fsck /dev/sd0a
# dump 0{other params}f {tapedev} /dev/sd0a
# /usr/etc/newfs /dev/rsd?a
# /usr/etc/mount /dev/rsd?a /mnt
# cd /mnt
# restore rf {tapedev}

(alternative to this below)

Same dump/restore as above or
# fsck /dev/sd0a; dump 0f - | (cd /mnt; restore xf -)

3) Maybe. I have never duch this.


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:48 CDT