Path: utzoo!utgpu!cunews!bnrgate!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: uaisun4!mrl@uunet.uu.net (Mark R. Ludwig)
Newsgroups: comp.sys.sun
Subject: Re: Automated Dumps
Keywords: Miscellaneous
Message-ID: <2670@brchh104.bnr.ca>
Date: 28 Apr 91 19:20:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 45
Approved: Sun-Spots@rice.edu
X-Original-Date: Fri, 26 Apr 91 10:35:16 PDT
X-Refs:  Original: v10n86
X-Sun-Spots-Digest: Volume 10, Issue 91, message 10
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

In article <2593@brchh104.bnr.ca>, stubblef@stl-08sima (Glenda Stubblefield) writes:
>I need to develop the means to
>do automatic backups, both full and incrementals, through cron during off
>hours.  

I do not know if it is possible to bring the system down to single-user
and then back up to multi-user mode in a hands-off fashion, at least on a
Sun (I know it *is* possible on DEC's Ultrix, because their Operator Shell
program manages to bring the system down to single-user mode and not get
killed itself.  I assume there is kernel or ``init'' support for this
which I also assume is not present in SunOS.)

If your requirements include doing *all* filesystems, the above problem
precludes a complete, hands-off solution, but I know it *is* possible to
do "user" disks without much problem.  Several things are important, but
paramount are that you must unmount the filesystem (optimally including
the NFS clients, if any) to ensure it is quiescent, and run ``fsck -p'' on
the filesystem to make sure it's nice and clean before backing it up to
tape.  The trick to getting NFS clients to unmount the disk(s) is the
``showmount -a'' command which you can use to generate a command you can
issue via ``rsh'' on the client to unmount the filesystem.  If your users
are sloppy and forget to logoff, you need a sentinel to kill them so the
decks will be clear by the time you try to unmount the disks.  If they
have background jobs running, that's another problem.  At our site, those
jobs get priority, and the backup simply skips the disk(s) it cannot
unmount.

After the backup finishes, re-mounting the disks on the NFS clients is
only simple if all the information is in ``fstab'' so you can issue a
command of the form ``mount nfs_server:/filesystem_export_name'' without
needing to know the name of the mount point on the client or any mount
options.  If you use quotas, remember to turn them on again after mounting
the disk(s).  For completeness, you might want to check the quotas too.
(I have yet to understand why, but occasionally quotacheck actually
corrects a problem on our Sun-3 disk, even if the system had not crashed
since the last quotacheck.)

Regarding the ``root'' and ``usr'' filesystems, if your environment is
like ours, the only activity of any interest is user mail and system logs.
You can copy or ``tar'' those directories to one of the other "user"
disks, from which it will be backed up indirectly.  I backup the ``root''
and ``usr'' filesystems irregularly, generally after I've done some
substantial work to the system configuration.  Since ``usr'' is read-only,
that one's even easier to manage.