There were many replies. This seems to be a popular topic. Thanks to all.
We have not chosen a solution yet. Since the information I have received is
useful, here it is. The original question was:
> We have two SunOS 4.1.2 systems. One is the warm stand-by for the other.
> How can I keep the / and /usr partitions on the stand-by system in sync
> with those on the main system. The use of tapes is too slow for use to
> consider. We do a level 0 dump every evening to an 8mm tape cartridge.
> We could start a clever set of piped commands to pick up modified files
> just before the level 0 dump.
>
> Please share your favorite pipe to copy modified files, e.g.
> cd /usr; find . -mumble | cpio -mumble other:/usr
A few shared their favorite piped command sequence. Here they are:
> From: seanw@amgen.com (Sean Ward)
>
> I'd try it this way. From the stand-by machine:
>
> cd /usr; rsh -n <main machine> "dump -mumble - /usr" | restore -xf -
>
> The mumble would be options for an incremental backup, such as "5uf". The "u"
> option, by updating the dump tables, would keep track of what had been changed
> since the last backup, and this also avoids the find command, which is *very*
> cpu intensive. I made some test runs to see if this would work, and it does.
I asked Sean:
> Thanks for your reply. Do you thing this would interfere with the
> daily level 0 dumps?
and he replied:
> Hmm... After reading the man page where it describes the dump levels, I think
> it would interfere with them. The way around that would be to not use the "u"
> option when doing the level 0 dumps. Since a level 0 would back up everything
> anyway, I wouldn't see that as a serious problem.
> From: Charles Butcher <charlesb@cssc-syd.tansu.com.au>
>
> cd /usr; find . -depth -print | cpio -oa | rsh other 'cd /usr; cpio -idmu'
>
> or, as long as source and target paths are the same:
>
> find /usr -depth -print | cpio -oa | rsh other cpio -idmu
> From: tph@sbctri.sbc.com (Timothy P. Henrion)
>
> Here's my favorite:
>
> cd /usr
> find . -print | cpio -pdm /net/other/usr
Many suggested that I use rdist. Though I should have remembered reading
about this somewhere, it very useful to know that many use it to do the
same thing we want to do. There were eighteen replies suggesting rdist four
of which recommended not to use the one that comes from Sun. Here are two
selected replies.
> Have you considered rdist? It is the right tool for the job.
>
> Watch out for files in / though. Some of them you don't want
> to be equal, or both machines will get the same IP address for example.
> I would strongly recommend that you use rdist, its available in standard
> SunOS. There's also a new version (shipped with BSD4.4), that you can
> get from usc.edu, look for /pub/rdist.
>
> rdist is easy to use, and it will only update files that have been changed.
> The new version is much better, I really recommend it! But the standard
> rdist is also good, and is probably sufficient for your needs.
>
> rdist is also a good security tool. Assuming you have a server you believe
> is safe, rdist'ing /etc, /usr etc. will detect if any of your clients have
> been compromised, if one or more files are different.
There were to references to Sys Admin magazine.
> From: davis%opus@uunet.UU.NET (Thomas J Davis)
>
> If you get Sys Admin magazine, there is an article about how to do this
> with a very clever perl script. The article is Disk Mirroring with NFS by
> Patrick M. Ryan. You can get the perl script he wrote to do this via
> anonymous ftp at jaameri.gsfc.nasa.gov in the directory /pub/sysadmin/mirror.
> From: Martin Achilli <ACHILLM%IMIHSRA.BITNET@vm.cnuce.cnr.it>
>
> there was an article about doing something like this with NFS on the
> SysAdmin magazine, the last one that came out
Two suggested Sun's Online Disksuite. Two others suggested dump. Here is
one of those.
> From: perryh@pluto.rain.com (Perry Hutchison)
>
> This is theoretical (untested) as I have never had occasion to actually
> attempt such a thing. Assuming / and /usr are sd0a and sd0g:
>
> dump 1f - /dev/sd0a | rsh other "cd / ; restore x"
> dump 1f - /dev/rsd0g | rsh other "cd /usr ; restore x"
>
> I am suggesting the use of "restore x" rather than "restore r" as you
> would not be restoring onto a partition freshly restored from the level
> 0 dump to which this level 1 refers.
>
> I am suggestiing the use of the block rather than the raw special file
> for dumping the root filesystem, due to the fact that the system would
> (I presume) be running multi-user and I think the block device is less
> likely to suffer from inconsistencies due to other running jobs. It
> will probably work better if /tmp is a separate partition as that is
> where a lot of the activity is and you most likely do not need such
> things copied.
Other suggestions were:
> lfu -- look in ftp.dcs.ed.ac.uk:pub/lfu/.
> I'd consider the mirror program. It uses FTP to synchronize a mirror from
> its source. Seems to me that it is suitable for your purpose, too. I use
> it (a.o.) to mirror two workstations on which I work in turn. Before I
> leave the office, I start the mirror and by the time I get home the
> workstation there is identical to the one I just left. And the other way
> around, also.
>
> The latest version of mirror is available from:
>
> src.doc.ic.ac.uk [146.169.2.1]
> directory: computing/archiving/mirror
> (shortcut packages/mirror)
>
> ftp.th-darmstadt.de [130.83.55.75]
> directory: pub/networking/mirror
> From: kmac@baosc.com (Keith McCloskey x8110)
>
> Doesn't Sun offer a high availability package that allows you to run 2 systems
> simultaneously with one being the "online" system, and the other would be the
> "hot" backup. I beleive these machines update one another via a point to point
> ethernet link. When the backup senses that the online system is down, it
> automatically reboots itself into the "online" mode.
>
> Sun Express should be able to give you more details on this.
> From: Dan Stromberg - OAC-DCS <strombrg@hydra.acs.uci.edu>
>
> You might be best off just doing a level 0 dump every evening, if the
> partitions aren't so large that it causes too long a time when the
> backup systems filesystems are inconsistent.
>
> If you want to go incremental, tho, why not use level 1 dumps?
>
> BTW, are you addressing the problem of files once created on the
> primary and later removed, sticking around (potentially) for a long
> time on the secondary?
> From: pln@egret1.Stanford.EDU (Patrick L. Nolan)
>
> Here's a little script I use to keep two filesystems on the
> same machine synchronized. You could perhaps modify it to
> handle a remote copy. It relies on the existence of a file
> which is updated every time the files are updated. Note that
> it only copies new files; obsolete ones aren't deleted.
>
> #! /bin/sh
> FROMDIR=/C/egret
> TODIR=/archive/egret
> TFILE=${TODIR}/SYNCHRONIZED
> cd $FROMDIR
> find . -depth -newer $TFILE -print | cpio -pdv $TODIR
> touch $TFILE
> From: vanbc!bchspd!bar (Bret A. Robinson)
>
> I asked a simliar question when I was on a Sun Admin course a couple of years
> ago and was tols that if the boot disks on both machines are identical, then
> the easiest and quickest way to this is used 'dd'. Try:
>
> dd if=/dev/rsd0c | rsh remote_host dd of=/dev/rsd0c
>
> This is supposed to work but have never needed to try it. Good luck.
> From: bern@kleopatra.Uni-Trier.DE (Jochen Bern)
>
> Best Way: Hang both SUNs to a dual-ported RAID Disk. Only consider this an
> Option if you REALLY care about this ...
>
> Next best Way: Use Disk Mirroring Software to keep identical Copies on the
> Disk of the primary Machine and on the Disk mounted from the secondary.
> Let the secondary Machine mount the Disk from the primary Machine during
> normal Operation, and as a normal Disk in Emergency.
>
> Well, the Remainder of your Options is a Mess of more or less clumsy
> Hacks ... I'd try to run a Level 9 Dump every <InsertFavoriteResolution>,
> writing to a named Pipe on the second Machine, which then does a Restore;
> For additional Safety, do Level 0 every Weekend or so (and make REALLY sure
> that the Level 9 Mechanism is off while restoring on the second Machine! ;-).
>
> Note that if you haul over the whole / FS, you'll have Problems because
> a Lot of /etc Files will tell the secondary Machine that it's really the
> primary one. =8-S
> From: jmclip@world.std.com (Jim R McLeanLipinski)
>
> I have come up with a fairly lengthy script to do what you just described
> basicaly it works as follows
> 1. Set up a file containing an entry for each file you want to keep in sync
> wild cards are ok
> 2. Set up cron to run the script as often as you like. I do it nightly
> 3. Each time the script runs it will check a time stamp file for each file
> that you want to keep in sync. If it has changed it will do an rcp of
> of the file to the other machine.
>
> I don't consider this to be the ideal solution because it's involves some
> set up, dosen't run in real time, and is somewhat fragile. On the
> otherhand, it works, it is very flexible, I use it to sync 14 machines with
> different sets of files, and you can have it today if you like. Just drop
> me some email if you are interested.
> From: julian@syd.dwt.csiro.au (Julian Dryden)
>
> What about mirroring a disk on the other machine?
>
> I guess you have SCSI and not IPI.
> If you had IPI you could dual port the disks easily (IPI Dual Port) but SCSI
> doesnt allow you to do that.
>
> I dont know quite what your environment looks like but you could mirror
> the disk on the other machine with DiskSuite and maybe keep the
> two machines connected to the same SCSI and arrange the disk accesses
> carefully. That is if you need rapid changeover under software control.
> There is nothing to stop you physically connecting 2 hosts to the one disk,
> only the file systems on your machines simply dont support this sort
> of contention.
>
> If you could afford the time for a physical cable swap then the mirror disk
> could simply be slipped off the production machine and onto the backup.
> This is how we do it on one of our machines here.
> From: per@erix.ericsson.se (Per Hedeland)
>
> Hmm, it would seem to me that the simplest way would be to just do a
> newfs + full restore of that tape onto the standby - you have the tape
> in any case, what does it matter how long the restore takes if it is
> "just" a standby (of course, you might need it before the restore has
> completed...).
>
> In general, just "replicating the modifications" is non-trivial - 'dump'
> with a non-0 level will indeed create a dump containig just the
> modifications, but this can't really be correctly restored on the
> standby unless you have previously done a full restore of the level 0 it
> is relative to - added/modified files will probably work OK, but not
> removed/renamed ones (you will keep everything...).
>
> If the disks holding / and /usr on both systems are identical, including
> the partition table, you might consider just dd'ing these partitions
> (using the raw disk device) across - this is very fast, but in addition
> to the requirement of identical setups requires that the file systems
> are idle, just like dump - should work fine do do it in parallell with
> the dumps.
I also got scripts from Robert J Wolf and John D Schneider. I did not
include the here because they are too long.
Thanks to:
seanw@amgen.com (Sean Ward)
davec@cs.ust.hk (Dave Curado)
pla_jfi@pki-nbg.philips.de (Karl-Jose Filler)
Leif Hedstrom <hedstrom@inf.ethz.ch>
gdmr@dcs.ed.ac.uk (George D M Ross)
tkevans@barkeep.es.dupont.com (Tim Evans)
jv@NL.net (Johan Vromans)
rwolf@dretor.dciem.dnd.ca (Robert J Wolf)
kmac@baosc.com (Keith McCloskey x8110)
Dan Stromberg - OAC-DCS <strombrg@hydra.acs.uci.edu>
Andrew@sdsu.edu (Andrew Scherpbier)
david@capmkt.capmkt.com (David Mostardi)
pln@egret1.Stanford.EDU (Patrick L. Nolan)
vanbc!bchspd!bar (Bret A. Robinson)
mwmeyer@ingres.com
dal@gcm.com (Dan Lorenzini)
waheed@symbol.COM (Faisal Waheed)
pallas@oclc.org (George Pallas)
jdschn@nicsn1.monsanto.com (John D Schneider)
bern@kleopatra.Uni-Trier.DE (Jochen Bern)
dougj@iplab.health.ufl.edu (Doug Jones)
"Richard J. Niziak" <rickn@copley.com>
jmclip@world.std.com (Jim R McLeanLipinski)
"Lack Mr G M" <gml4410@ggr.co.uk>
Juergen Peus <grobi@uni-paderborn.de> (with accents: J|rgen Pius)
Hans van Staveren <sater@cs.vu.nl>
eckhard@ts.go.dlr.de (Eckhard Rueggeberg) (with accents: Eckhard R|ggeberg)
perryh@pluto.rain.com (Perry Hutchison)
Charles Butcher <charlesb@cssc-syd.tansu.com.au>
Gordon.Rowell@nms.otc.com.au (Gordon Rowell)
davis%opus@uunet.UU.NET (Thomas J Davis)
Rafi Sadowsky <rafi@tavor.openu.ac.il>
Mike Raffety <mike_raffety@il.us.swissbank.com>
---------------
Claude Marinier
claude.marinier@dreo.dnd.ca
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:56 CDT