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?
Replies:
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
THANKS FOR ALL THE HELP!
-------------------------------------------------------------------
>From david@capmkt.com 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'.
3)
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 bl081930@moosehead.eng.canadair.ca 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 tom@yac.llnl.gov 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 something....it actually mirrors the
info from one drive to another.
-------------------------------------------------------------------
>From dbrown@lizzard.med.utah.edu 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 sjones@mercury.hyperdesk.com 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 gdonl@sunrise.ssi1.com 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 per@erix.ericsson.se 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.
3)
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!oasys.sa-htn.valmet.com!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 trinkle@cs.purdue.edu 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
filesystems).
-------------------------------------------------------------------
>From weingart@inf.ethz.ch Mon Apr 26 02:26:31 1993
1)
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.
3)
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 jdschn@nicsn1.monsanto.com 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 mharris@jpmorgan.com Mon Apr 26 12:45:05 1993
1)
Dump sd0's partitions to sd1's. Do an installboot to make it bootable.
2)
I think the simplest ways are the best. Incremental dumps and restores
sound simple.
3)
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 peters@mega.com.au 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 adh@wb.utwente.nl 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)
2)
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