hendrik@zeusa.UUCP (Hendrik Vermooten) (11/05/90)
A customer of mine has about 20 XENIX sites, with *low* level operators. Making backups is a problem: I've written software that does not allow them to boot up the machine in the morning unless it has a tape loaded. (Gross, huh? :-) A cron process then makes a backup at lunch time. They are supposed to put in the appropriate tape each day before booting. This works ok, *except* that they leave in the same (*#$#)(#%$!#@ tape, so that there aren't any generations of backups, and this has led to major problems. What I'm looking for is some program/script/anything that will check if the correctly labled tape (labled magnetically on the tape, that is) is loaded into the drive before proceeding. It would be nice if this prog could also send mail to someone (at anther site) if it "notices" that backup procedures aren't being followed. I'd appreciate any help! -------------------------------------------------------------------------- Hendrik Vermooten, ZEUS software Tel [27 12] 64-5507, FAX [27 12] 64-8382 Bang: ..!uunet!ddsw1!olsa99!zeusa!hendrik or hendrik@zeusa.UUCP --------------------- He who laughs last laughs last ---------------------
chip@chinacat.Unicom.COM (Chip Rosenthal) (11/12/90)
In article <867@zeusa.UUCP> hendrik@zeusa.UUCP (Hendrik Vermooten) writes: >A customer of mine has about 20 XENIX sites, with *low* level operators. >Making backups is a problem [...] What I'm looking for is some >program/script/anything that will check if the correctly labled tape [...] You've got a bigger problem than getting backups made - you need to fix an attitude problem. I would recommend a letter to the manager of the facility. I do not suggest that this letter beat them up over bad practices, but rather suggest a positive course of action and clearly explain the benefits to be obtained. If possible, these benefits should be in terms of cold, hard cash. For example, I've got an analogous situation with one client. They were very begrudging over my recommendation to start using passwords. They still don't have a root password. Just two weeks ago, they went out and bought another terminal because the (theoretical) system administrator wanted "to do data entry while generating reports." This is on a SCO XENIX system, which has multiscreen capability (i.e. the equivalent 12 tty's on the console). She didn't know about that. Just this week, they ran out of disk space because nobody watches the df's. The price they've paid this last month on unnecessary equipment and lost productivity would more than pay for two people to attend a XENIX training class. If I can convince them to send just one person, they win. Maybe training classes aren't a possibility for you. In this case, check out other alternatives. Check out the instructional videotapes and other programs. Your challenge is to motivate (at least) one person at this site to get responsible for these machines. You aren't going to cram anything down their throats they don't want - work on making them want it. I strongly advise you to address the attitude problem. A tape labelling program would indeed be a handy tool, but that's going after the symptoms. Unless you fix the real problem, clients like this can become lots of headache and little reward. -- Chip Rosenthal <chip@chinacat.Unicom.COM> Unicom Systems Development, 512-482-8260 Our motto is: We never say, "But it works with DOS."
jay@metran.UUCP (Jay Ts) (11/12/90)
In article <1694@chinacat.Unicom.COM>, chip@chinacat.Unicom.COM (Chip Rosenthal) writes: > In article <867@zeusa.UUCP> hendrik@zeusa.UUCP (Hendrik Vermooten) writes: > >A customer of mine has about 20 XENIX sites, with *low* level operators. > >Making backups is a problem [...] What I'm looking for is some > >program/script/anything that will check if the correctly labled tape [...] > > You've got a bigger problem than getting backups made - you need to fix > an attitude problem. I would recommend a letter to the manager of the > facility. I do not suggest that this letter beat them up over bad > practices, but rather suggest a positive course of action and clearly > explain the benefits to be obtained. I usually use the reverse approach with my clients: tell them in no uncertain terms what it costs to NOT have backups *when* (not "if") the disk crashes. I tell them if they don't protect their data, it's only a matter of time until they lose it. I'm consulting in central Florida, where high-energy lightning strikes are as common as small businesses running UNIX/Xenix without UPS's, surge protectors or even one good tape backup. The first thing I usually tell a new client is to correct these same deficiencies. If they don't wise up, I simply stop working for them, and let nature take its course. Somehow, they have to learn. I want to help them, but I'm not going to put myself in legal jeopardy by being "the last consultant to touch the machine before we lost everything". I figure if they don't care enough to take care of, and protect, their equipment and data, they are not good to do business with. > This is on a SCO > XENIX system, which has multiscreen capability (i.e. the equivalent 12 > tty's on the console). She didn't know about that. Just this week, they > ran out of disk space because nobody watches the df's. I've heard from SCO-related sources that Xenix is not guaranteed to run reliably (i.e., not lose files) when the disk is more than 85% full... > The price they've paid this last month on unnecessary equipment and lost > productivity would more than pay for two people to attend a XENIX training > class. Or RTFM... > I strongly advise you to address the attitude problem. A tape labelling > program would indeed be a handy tool, but that's going after the symptoms. I agree, but must add that a really good piece of software, and a FAST tape backup system make a LOT of difference. A lot of the reason why backups are not made is due to the inconvenient nature of performing them. I've had good luck by writing simple shell script backup systems, customized for each site and manager's likings, and installing it in their login menus. In my experience for Xenix and UNIX/386, the DC600 tape drives are much faster than the QIC drives, and this is a very important factor. > Unless you fix the real problem, clients like this can become lots of > headache and little reward. > -- > Chip Rosenthal <chip@chinacat.Unicom.COM> Well said. Jay Ts Metran Technology Tampa FL uunet!pdn!tscs!metran!jay
hendrik@zeusa.UUCP (Hendrik Vermooten) (11/14/90)
Re: my original posting about "Forcing good backup procedures" In article <1694@chinacat.Unicom.COM>, chip@chinacat.Unicom.COM (Chip Rosenthal) writes: > You've got a bigger problem than getting backups made - you need to fix > an attitude problem. That's for sure! > Just this week, they ran out of disk space because nobody watches the df's. I've written a cron/script that mails a warning. Anybody interested? > Chip Rosenthal <chip@chinacat.Unicom.COM> Thanx, Chip. I also received some mail in the same vein. Thanks to all. I didn't really describe the problem fully. These 20 systems are at separate places *hundreds of miles* away from anything. Top management of the company have made many attempts to improve the problem, and it has. It's just that there are still problems sometimes, and it would be nice to solve the problems before they actually lose data. I will impress upon them that it is an attitude program again, but they still want the labeling program. (BTW, I have received two mails with shell scripts that help solve the problem [thanx Sean Enraght-Moony and Alan Mintz]. If anybody is interested let me know & I'll post 'em) --------------------- He who laughs last laughs last --------------------- Hendrik Vermooten, ZEUS software TEL +27 12 64-5507, FAX +27 12 64-8382 Bang: ..!uunet!ddsw1!olsa99!zeusa!hendrik or hendrik@zeusa.UUCP ----------------- He whose laugh lasts longest laughs last --------------- -- --------------------- He who laughs last laughs last --------------------- Hendrik Vermooten, ZEUS software TEL +27 12 64-5507, FAX +27 12 64-8382 Bang: ..!uunet!ddsw1!olsa99!zeusa!hendrik or hendrik@zeusa.UUCP ----------------- He whose laugh lasts longest laughs last ---------------
barton@holston.UUCP (Barton A. Fisk) (11/16/90)
In article <318@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: >In article <1694@chinacat.Unicom.COM>, chip@chinacat.Unicom.COM (Chip Rosenthal) writes: >> In article <867@zeusa.UUCP> hendrik@zeusa.UUCP (Hendrik Vermooten) writes: [backup stuff deleted] > >In my experience for Xenix and UNIX/386, the DC600 tape drives are much >faster than the QIC drives, and this is a very important factor. > Excuse me. DC600's are tapes made by 3-M not the drives. QIC-24 drives use the DC-600 tapes. Let's get these straight before we make backup recommendations. -- uucp: holston!barton pseudo: barton@holston.UUCP
hendrik@zeusa.UUCP (Hendrik Vermooten) (11/27/90)
About forcing good backup procedures. I got two scripts with possible
solutions, and some mail from various people asking for them, so I
decided to post. (Thanks to sean@kcms and alan@mq).
======================================================================
From olsa99!kcms!sean Sat Nov 10 04:28:22 1990
Subject: Backup watchdog
From: Sean Enraght-Moony <root@kcms.UUCP>
Howdy do.
I have had a similar problem, although my users are a little more
intelligent. They still need reminding, however. They have a 286 XENIX
box with 60Mb tape. Normally, I think the best tape labeling mechanism
would be to use a "no-rewind" tape device, and use dd to write out a header
to the tape without rewinding. The backup would follow. To read the
header, you would use dd to read the first section of the tape (with no
rewind) and then compare it to a value in a disk file.
This is lovely if you have a no-rewind device, which their system doesn't.
What we do, then, is to have a disk file called TVOL which contains the
tape volume name. We use tar to back up, and the first file name in the
list of files to be backed up is TVOL. This way, the tape always has the
volume name as part of the data at the same place (in front of the file).
The first thing the backup script does is to work out what the tape volume
should be. The next task is to read the first part of the tar volume with dd,
and extract the volume name:
# SBE is what the volume name should be
# VOL is what the volume is
# /usr/sys_data is the directory where funny system-wide info is kept
SBE=`dd if=/usr/sys_data/backup.log bs=1 skip=29 count=9 2> /dev/null | head -1`
if [ `expr ${1:-0}` -lt `expr 1` -o `expr ${1:-0}` -gt `expr 10` ]
then
echo "Reading tape label . . ."
VOL=`dd if=/dev/rct0 skip=1 count=1 2> /dev/null | head -1`
else
case $1 in
1) VOL="BACKUP01"
;;
2) VOL="BACKUP02"
;;
3) VOL="BACKUP03"
;;
4) VOL="BACKUP04"
;;
5) VOL="BACKUP05"
;;
6) VOL="BACKUP06"
;;
7) VOL="BACKUP07"
;;
8) VOL="BACKUP08"
;;
9) VOL="BACKUP09"
;;
10) VOL="BACKUP10"
;;
esac
fi
echo $VOL > /TVOL
echo "Installed volume is $VOL, next backup should be on $SBE"
if [ "$VOL" != "$SBE" ]
then
echo "\007This is possibly the wrong volume!"
fi
while echo "Do you want to back up onto this tape (y/n)? \c" >&2
do read YN rest
case $YN in
[yY]) :
:
[ tar backup, TVOL backed up first ]
:
:
echo "`date` $VOL">>/usr/sys_data/backup.log
tail -10 /usr/sys_data/backup.log > \
/usr/sys_data/new.backup.log
rm /usr/sys_data/backup.log
mv /usr/sys_data/new.backup.log /usr/sys_data/backup.log
chmod 664 /usr/sys_data/backup.log
echo "\nFinished\n"
sleep 10
clear
break
;;
[nN]) echo "Backup aborted at user's request\n"
break
;;
*) echo "Please answer y or n" >&2;;
esac
done
A backup log is maintained in /usr/sys_data/backup.log which lists the last
10 backups. The next tape volume required is also extracted from here.
I'm sure that with a bit of modification, this would serve your needs.
Having the system mail you in the event of an error would be a piece of
cake.
I hope this is something like what you were looking for?
Regards
Sean
------------------------------------------------------------------------------
Sean Enraght-Moony: ..!uunet!ddsw1!olsa99!kcms!sean or sean@kcms
If, at first, you don't succeed, blame your vendor.
------------------------------------------------------------------------------
======================================================================
From olsa99!ddsw1!uunet!mq!alan Mon Nov 12 17:23:17 1990
From: olsa99!ddsw1!uunet!mq!alan
To: ddsw1!olsa99!zeusa!hendrik
Date: Sun Nov 11 10:16:47 1990
To: uunet!ddsw1!olsa99!zeusa!hendrik
:
# bakup.sh
#
# Script to verify correct day tape in drive before doing backup.
#
# This script is dependent on the output of dumpdir(C) as found in
# SCO XENIX 386 SVR2.3.2 and may not work with other versions.
#
# It should be called from cron instead of the normal /bin/backup. Any
# parameters from the cron line are passed to /bin/backup.
#
systemid=`cat /etc/systemid`
admmail="central!sysadm"
onsite="operator"
today=`date +%a`
# Get day of last dump on tape from dumpdir header
tapeday=`dumpdir | head -1 | awk '{ print $3 }'`
if [ "$tapeday" = "$today" ]
then
/bin/backup "$*"
exit 0
else
echo "$tapeday tape is in drive at $systemid" | mail $admmail
echo "Please put $today tape in drive and type /bin/backup $*" | mail $onsite
exit 1
fi
--
< Alan H. Mintz | Voice +1 714 980 1034 >
< Micro-Quick Systems, Inc. | FAX +1 714 944 3995 >
< 10384 Hillside Road | ...!uunet!mq!alan >
< Alta Loma, CA 91701 USA | alan@MQ.COM >
======================================================================
--
--------------------- He who laughs last laughs last ---------------------
Hendrik Vermooten, ZEUS software TEL +27 12 64-5507, FAX +27 12 64-8382
Bang: ..!uunet!ddsw1!olsa99!zeusa!hendrik or hendrik@zeusa.UUCP
----------------- He whose laugh lasts longest laughs last ---------------