glidden@morgoth.UUCP (03/24/87)
I received enough request for the following to warrant posting, so here goes. If you try anything suggested here, let me know what happens. First, here is my original message: In article <128@morgoth.UUCP> glidden@morgoth.UUCP (Ken A. Glidden) I wrote: Sept. 1986 > We have a uVAX II running Ultrix 1.2. I'd like very much to use >the crontab to start up a shell script late at night to perform >a dump. Specifically I'd like the shell script to "simulate" >single user mode by preventing any logins, killing any processes which >have the potential to alter the disk during the dump, and preventing >any processes which may alter the disk during the dump from starting >while the dump is in progress. Once finish the script should undo all >its protections and allow business as usual. > > Before I press on I'd like to ask, "ANYONE ALREADY DONE THIS?" >"DOES ANYONE KNOW OF A REASON I SHOULDN'T DO IT THIS WAY?" > >--Ken Now for the anthology of very interesting responses... ============================================================================ Date: Mon, 15 Sep 86 09:38:58 est From: adelie!ll-xn!seismo!munnari!trlvlsi.trl.oz!tyers (Peter Tyers) Subject: unattended dump Im working on just this now. I have a script that simulates single user, bans logins, umounts the file system and error checks. It requires a few more days work before Im ready to mail it to net.sources ------------------------------------------------------------------------------ P Tyers, Telecom Australia Research Laboratories ACSnet tyers@trlvlsi.oz (Australian Computer Science Network) CSnet tyers@trlvlsi.oz ARPAnet tyers%trlvlsi.oz@seismo.arpa UUCP {decvax,vax135,eagle,pesnta}!mulga!trlvlsi.oz!tyers PaperMAIL: P Tyers, Telecom Australia (Research), P.O Box 249, Clayton, VICTORIA 3168, AUSTRALIA =-=-=-=-=-=-=-=-=-=-=-=-= Date: Mon, 15 Sep 86 09:34:09 -0200 From: adelie!ll-xn!seismo!enea!erialfa!kjelle (Kjell Eriksson) Subject: Re: Automatic unattended execution of 'dump' ? Organization: Ericsson Information Systems AB, Kista, Stockholm, SWEDEN Why SIMULATE single user mode. Why not go into single user. We do that every night here with our Suns. Here is an outline how we do it: Cron executes a script that creates a file that indicates the reason for the shutdown was backup. In our case '/etc/backup/backupflag'. The script then Executes shutdown +5. When the system goes singleuser the first thing it does is to execute the file /.profile (or is it /.login). In it you put a test for the file above. if test -f $backupflag; then runbackup; How do you get up into multiuser again? You do an exec on some program. When it terminates it is equivalent to ^D to the su shell. Of course I didn't invent this my self. But the script behind runbackup are mine. Kjell E. -- Kjell Eriksson Phone: + 46 8 7937844 Telefax: 7509851 Ericsson Information Systems AB Telex: 15968 ericki s S-163 98 Stockholm UUCP: ...!mcvax!enea!erix!erialfa!kjelle SWEDEN kjelle@erialfa.UUCP =-=-=-=-=-=-=-=-=-=-=-=-= Date: Mon, 15 Sep 86 09:12:05 GMT From: adelie!axiom!linus!philabs!prls!ems (Gordon Vickers) Subject: Re: Automatic unattended execution of 'dump' ? Organization: Philips Research Labs, Sunnyvale, California I don't think you're going to be able to 'simulate single user mode' but maybe you really don't need to go to such pangs. We are running Ultrix 1.2 on a Vax 750. A couple of weeks after the 1.2 update, when I was confident that all system files were O.K., we did a level zero dump. Now I use cron every night to start up a shell script that tar(1)'s frequantly accessed directories. The script is similar to: date > /usr/adm/tars tar /.??* /etc && echo "tar / " >>/usr/adm/tars cd /usr && tar adm/ games/lib/ spool/ && echo "tar /usr" >> /usr/adm/tars cd /a && tar ./* && echo "tar /a" >>/usr/adm/tars date >> /usr/adm/tars There may be some comprimise with this method ( many prefer dump ) , but for something that is going to be automatic, and occur while others are logged on, I'd suggest using tar(1). I have found my solution ( tar(1) via shell script) to be quite adequate. ------------- fold, spindle, mutilate at will ------(it's your CRT) ---- Gordon P. Vickers, (408) 991-5370, Signetics Corp., PO Box 409, M/S 69, Sunnyvale, Ca 94086 {allegra,decvax,ihnp4}!philabs!prls!ems or {ucbvax,decwrl,ihnp4,allegra}!amdcad!amdimage!prls!ems [ In this correspondance, I am representing myself and no others. I am not part of the PRLS group, but they are nice enough to allow me to TIP(1) to an account on their machine so I can send/receive email.] =-=-=-=-=-=-=-=-=-=-=-=-= Date: Mon, 15 Sep 86 21:43:22 -0100 From: adelie!ll-xn!seismo!kuling!martin (Per-Erik Martin) Subject: Re: Automatic unattended execution of 'dump' ? Organization: Dep. of Computer Systems, Upsala University, Sweden No, I haven't already done that and I can't think of a reason why you sholdn't do it that way. But I would be appreciative if you could forward any responses you may get since I have the same problem here (we have a Sun-3 running BSD4.2). Currently I let cron run the 'daily' backup late at night and hope that is works. When running the total backup I have to reboot the system in single user mode... So I really need something like TOPS-20's '^Ecease (timesharing)' command, both for unattended and attended backups. /PEM -- Per-Erik Martin, Computing Science Dep., Uppsala University, Sweden UUCP: martin@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!martin) =-=-=-=-=-=-=-=-=-=-=-=-= Date: Tue, 16 Sep 86 10:18:36 +0100 From: adelie!ll-xn!seismo!enea!erix!per (Per Hedeland) Subject: Re: Automatic unattended execution of 'dump' ? Why bother to simulate instead of doing "the real thing"? We do our dumps that way, using som little magic in /.profile which is read by the single- user shell; when that shell dies, the system goes back up to multiuser. Has worked very well for a long time now on our 4.2BSD system. I can send details if you're interested. Regards Per Hedeland {seismo,mcvax}!enea!erix!per or per@erix.uucp =-=-=-=-=-=-=-=-=-=-=-=-= Date: Mon, 15 Sep 86 10:15:03 edt From: adelie!ll-xn!seismo!NLM-VAX.arpa!randy (Rand Huntzinger) Subject: Re: Automatic unattended execution of 'dump' ? Organization: National Library of Medicine, Bethesda, Md We do this here, except we don't simulate single user mode, we actually shut the system down, do the dump, and restart it automatically. We use disk to disk dumps, but you could just as easily write to tape. We've got a slightly bigger system (a 780 with 4 RA81's and soon a CDC9772), so our job is more complex than yours might be, but you can get the drift. We only use this for daily incremental dumps of the file systems which must always be online and read/write when the system is up. Other file system are backup up with the system up and the file system mounted read only. Because our monthly full backups require multiple tapes, we have to do this manually. Here's how our scripts work: 1. A trigger script, setdump, is run by crontab. It runs the shutdown program with the -r option (reboot). This schedules the system shutdown for 5AM (a good time for us). It also creates a file, /etc/dodump. 2. When the system shuts down, it is automatically rebooted, and starts through the system initialization. After the file system check, we added code to execute the shell script, dumpdd, if the file /etc/dodump exists. If this "trigger file" doesn't exist, the dump script is skipped and the system reboots normally. 3. The /etc/dumpdd script calls dump create backup files on our "scratch" file system. When it finishes, it removes the /etc/dodump file. This disables the dump mechanism until setdump schedules another one. 4. With the system up, we use a script, dumpdt to copy the dump files to tape and delete the dump files from disk. [It uses dd to do the copy] Our scripts are relatively robust. We've attempted to make sure we get a good backup if possible. For example, the dumpdt script doesn't let you delete the dump files from disk until it has checked the tape (reread it). The dumpdd program renames files several times so the script can be interrupted (for example, by a system crash) and still get a good copy. The process is essentially this: 1. Do the set of backup files we're to create (named filesystem.level) already exist? If so, they weren't written to tape yesterday. Rename them to filesystem.level.old to give us another chance to back them up. 2. For each filesystem to be dumped, do the following. a. Does a file name filesystem.level.y exist? If so, skip the dump of this file. [This means that the dump was interrupted after the backup of this filesystem was completed] b. Dump the file system to a file named filesystem.level.x. c. Sync the disks. This makes sure the output file and the /etc/dumpdates files are up to date on the disk. d. Rename filesystem.level.x to filesystem.level.y. This indicates that the dump of this filesystem is complete. 3. When all the file systems have been dumped, rename all the filesystem.level.y files to simply filesystem.level. Remove the trigger file and exit. On exit, the system will come back up. There are a few more wrinkles to this script, it computes the dump level from the day of the week. If the user types ^C or the dump program fails, the script exits and the system comes back up, and so forth. ============================= If you can do a full backup on a single tape, your backup obviously be much simpler. But this gives you an idea of some of the issues we had to address. If you want a copy of our scripts, I can send you one. Rand Huntzinger =-=-=-=-=-=-=-=-=-=-=-=-= Date: Tue, 16 Sep 86 15:30:49 -0200 From: adelie!ll-xn!seismo!enea!erialfa!kjelle (Kjell Eriksson) Subject: Re: Automatic unattended execution of 'dump' ? >DEC tells me Ultrix won't allow cron to execute a script with shutdown >in it. To not allow cron to execute a shell script with shutdown in it may be a good idea. It *is* a little suspect. But it shouldn't complain if you have 'su root' in cron and everything is owned by root and not writable by any other. But then, DEC moves in mysterious way. Sun has no such "security features", at least not in 2.0. What if ...., You hid the shutdown a few subshells away from cron? Provided the the scrips run a superuser they wuold have had to make some very large changes to aviod that *any* (grand)child of the cron daemon ran a shutdown. Or do they check in shutdown that it is connected to a controlling terminal. There should be some primitives also, like 'reboot'. Happy hacking and don't give up! Kjell E. =-=-=-=-=-=-=-=-=-=-=-=-= Date: Mon, 15 Sep 86 15:40:47 PDT From: adelie!ll-xn!lll-crg!sun!rdh (Robert Hartman) Subject: Re: Automatic unattended execution of 'dump' ? Organization: Sun Microsystems, Inc. I think that you can put the "dump" command-line in the file /etc/rc.local, and then use a "shutdown -r" command in your crontab to fire it off (in single-user mode) as part of the procedure to come back up multi-user. -bob. =-=-=-=-=-=-=-=-=-=-=-=-= Date: Wed, 17 Sep 86 13:23:32 +0100 From: adelie!ll-xn!seismo!enea!erix!per (Per Hedeland) Subject: Re: Automatic unattended execution of 'dump' ? > I would appreciate receiving details of your magic with >./profile. We are new to UNIX and I'm not sure of what your >approach is. Well 'magic' was perhaps an exaggeration, however I think the technique isn't altogether common. I believe you said you had an Ultrix system, so this should work for you too (init and single/multi-user switch is a bit different in sys III/V etc, I think). The basic idea is: - Put the dump commands in a particular file. - Force the system down to single-user. - When the single-user shell (/bin/sh) starts up, it will source /.profile - The code in /.profile looks for the particular file, and if it finds it, executes the commands therein, and causes the single-user shell to die. - When the single-user shell dies, the system comes back up to multi-user (i.e. what happens when you give ^D in single-user). There are some things involved in order to prevent the system from hanging: 1) Shutdown may hang (at least in 4.2) if a user has ^S'ed his terminal (or equivalent; we have paging in the tty driver...). We use 'wall' + 'sleep' + 'kill' instead. 2) Dump will "hang", or rather keep asking for help, in case of tape errors etc. The 'notty' cause dump not to have a controlling terminal (/dev/tty) to ask on, and it gives up altogether. This, too, might be different in Ultrix. In the sharchive below, 'sdump' is the command that requests a dump, single_dump is run from crontab every night: 30 2 * * * sh /etc/single_dump , .profile is /.profile, and notty.c takes away the controlling terminal. You will of course have to tailor the dump commands etc. to suit your needs. Good Luck! --Per # This is a shell archive. Remove anything before this line, then # unpack it by saving it in a file and typing "sh file". (Files # unpacked will be owned by you and have default permissions.) # # This archive contains: # sdump single_dump .profile notty.c echo x - sdump cat > "sdump" << '//E*O*F sdump//' TAPE=/dev/rmt20 DEN=6250 BLOCK=40 TIME=0230 SFILE=/sdump if [ "$#" -lt 1 ] then echo "Usage: sdump file_systems" exit 5 fi for file_system in $@; do grep -s $file_system /etc/fstab if [ $? -ne 0 ]; then echo "Unkown file system $file_system" exit 10 fi done echo "/etc/fsck -p" > $SFILE for file_system in $@; do echo "/usr/local/bin/notty /etc/dump 0ufdb $TAPE $DEN $BLOCK $file_system 2> /dev/console" >> $SFILE done echo "mt offl" >> $SFILE chmod 400 $SFILE //E*O*F sdump// echo x - single_dump cat > "single_dump" << '//E*O*F single_dump//' if test -r /sdump then echo "system going down for dump in 3 minutes" | wall & sleep 180 cp /sdump /single_shot rm /sdump kill 1 fi //E*O*F single_dump// echo x - .profile cat > ".profile" << '//E*O*F .profile//' echo 'erase ^?, kill ^U, intr ^C' stty dec PATH=/etc:/usr/ucb:/bin:/usr/bin:. export PATH HOME=/ export HOME export TERM # For doing dumps etc in single user and then returning to multi : # If there is a file /single_shot owned by root and created today, # source it, remove it, and return to multi-user # (Assumes, of course, that root doesn't have /bin/sh as login shell) if [ -f /single_shot ] then set x`ls -l /single_shot` owner="$3" ctime="$5 $6" set `date` if [ "$owner" = root -a "$ctime" = "$2 $3" ] then . /single_shot umount -a exec mv -f /single_shot /single_done else rm -f /single_shot fi fi //E*O*F .profile// echo x - notty.c cat > "notty.c" << '//E*O*F notty.c//' /* * exec command without controlling tty * usage: notty command [args] */ #include <sys/ioctl.h> main(argc,argv) int argc; char **argv; { int fd; if ( (fd = open("/dev/tty", 2)) >= 0 ) { ioctl(fd, TIOCNOTTY, 0); close(fd); } execvp(argv[1], &argv[1]); /* exec failed */ perror(argv[1]); exit(1); } //E*O*F notty.c// exit 0 =-=-=-=-=-=-=-=-=-=-=-=-= Date: Wed, 17 Sep 86 19:28:45 pdt From: Stewart Levin <cca!decvax!hanauma!stew> Subject: Re: dumps Why log users off at all? The only reason I know is the fear that their activities will corrupt the dump output (e.g. tape) so it can't be restored. We use the following simple script to verify dump integrity. All our dumps have been done multiuser here for over five years without problems: /etc/dump.verify.s: #! /bin/sh # dump.verify.s # # script to verify that we can restore the last file on a dump tape # # # Note that this only checks the first virtual tape thoroughly # # # Get the name of the last file on the tape # # Tape is already rewound # mt -f /dev/rmt16 rewind fn=`/etc/restore tG | sort -n | tail -1 ` echo fn = $fn # # Set to fail if $fn is not set [-u], and assign words in fn to $1, $2, etc. # set -u $fn # # Restore the last file on dump # echo dump.verify: restoring file $2 if /etc/restore xmG $2 << EOD 1 yes EOD then if rm -f $1 then echo echo dump.verify: verification succeeded echo exit fi fi echo echo dump.verify: ****** VERIFICATION FAILED *********** echo exit =-=-=-=-=-=-=-=-=-=-=-=-= Date: Fri, 19 Sep 86 11:54:33 edt From: harvard!earvax!das (David Steffens) Subject: Re: Automatic unattended execution of 'dump' This is in response to your article <128@morgoth.UUCP> in net.unix-wizards. I have a package of utilities to run unattended overnite dumps. It was built for an Ultrix 1.1 system but should also work on an Ultrix 1.2 system. Unfortunately, some of this stuff requires source changes to Ultrix utilities and the whole implementation is probably more complex than you really need. Furthermore, I haven't got it all nicely tied up in a package that I can mail to you. However, if you can't get what you need from anyone else, give me a call (after 2pm is best) and we may be able to work something out. ----- {harvard,mit-eddie,think}!eplunix!earvax!das David Allan Steffens 243 Charles St., Boston, MA 02114 Eaton-Peabody Laboratory (617) 523-7900 x2748 Mass. Eye & Ear Infirmary =-=-=-=-=-=-=-=-=-=-=-=-= From: jason%violet.Berkeley.EDU@BERKELEY.EDU (Jason Venner) Subject: atomatic dump. Date: 17 Sep 86 16:52:14 GMT If you had the ofiles program that was posted to the net a file back, you could run that on each file system you wanted to dump, and kill the pid's that had the file system open. Then you can unmount each file system one by one and dump them in total safety, without needing to log everone off..... then when you are done, remount them. You will need to make sure to restart all of your system deamons when you are done. cron opens /usr/lib update opens / lpr opens /usr/spool/lpr accounting has /usr/adm/acct open =-=-=-=-=-=-=-=-=-=-=-=-= Date: Thu, 18 Sep 86 08:12:01 -0200 From: adelie!ll-xn!seismo!enea!erialfa!kjelle (Kjell Eriksson) Subject: Automatic dumps! I could mail you my scripts. They are terribly complicated. I can write a control file to specify dump levels etc. Or do you want the joy of doing it you self? Kjell E. =-=-=-=-=-=-=-=-=-=-=-=-= Date: Mon, 15 Sep 86 19:25:31 PDT From: ll-xn!caip!lll-lcc!leadsv!cae780!tektronix!tekgen.TEK.COM!dickj (Dick Jackson) Subject: Re: Automatic unattended execution of 'dump' ? Organization: Tektronix, Inc., Beaverton, OR. I regularly run dump through a shell script at night without taking the system to single user mode and have never had any problems. This is a fairly straightforward script that uses dump and tar to get all the file systems onto one tape. If you want it, e-mail me at the address below and I can send it to you. Have you found any way to make dump do multiple file system dumps on one tape? If you have a way without using tar I sure would like to know what it is. Regards, Dave White Grass Valley Group, Inc. ...!tektronix!davew@gvgpsa.UUCP or ...!ucbvax!ucdavis!davew@gvgpsa.UUCP =-=-=-=-=-=-=-=-=-=-=-=-= From adelie!ll-xn!cit-vax!nike!lll-crg!seismo!umcp-cs!chris Wed Sep 24 17:19:27 EDT 1986 >From: chris@umcp-cs.UUCP (Chris Torek) Subject: Re: Automatic unattended execution of 'dump' ? Date: 21 Sep 86 22:56:13 GMT Organization: University of Maryland, Dept. of Computer Sci. Unfortunately, just about every process might alter the disk. About the only way to do this would be to kill everything, then start only trusted processes. Indeed, the easiest way to do this would be to run shutdown. If your root shell is /bin/sh, you could then put this in /.profile: PATH=/bin:/etc; export PATH if [ -f /etc/autodump ]; then sh /etc/autodump rm -f /etc/autodump exit 0 fi # rest of /.profile For /bin/csh, use set path = (/bin /etc) if (-f /etc/autodump) then sh /etc/autodump rm -f /etc/autodump exit 0 endif # rest of /.cshrc You can then have cron copy a script to /etc/autodump and run shutdown. When the machine goes to single user mode, the shell will read .profile or .cshrc and run autodump, then remove the script and exit, bringing the machine back up in multi-user mode. This, like all unattended dump schemes, can run into one problem: Dumps do not always succeed. If the dump fails, dump will attempt to get help; this too will fail, and I am not certain just what will happen after that. It should be easy enough to find out: just leave the tape drive off line and force a run. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu =-=-=-=-=-=-=-=-=-=-=-=-= From adelie!ll-xn!nike!lll-crg!seismo!nbires!isis!udenva!wedgingt Fri Sep 26 11:07:17 EDT 1986 >From: wedgingt@udenva.UUCP (Will Edgington/Ejeo) Date: 24 Sep 86 16:52:11 GMT Organization: U of Denver In article <3528@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >If your root shell is /bin/sh, you could then put this in /.profile: > > PATH=/bin:/etc; export PATH > if [ -f /etc/autodump ]; then > sh /etc/autodump > rm -f /etc/autodump > exit 0 > fi > # rest of /.profile > >For /bin/csh, use > > set path = (/bin /etc) > if (-f /etc/autodump) then > sh /etc/autodump > rm -f /etc/autodump > exit 0 > endif > # rest of /.cshrc Both the 'exit 0's above want to be 'kill $$'s instead. Exit called in either a .profile, a .cshrc, or a .login will merely exit the file and continue the regular interactive shell, waiting for input from the terminal (in this case, the console). I use this 'feature' of exit in my .cshrc and .login to avoid running them if I answer 'no' to a prompt my .cshrc gives. We do dumps 'auotmatically' by telling our operators to pick a certain choice on their menu (they log in as UID 0, but into a *very* restricted shell), which runs shutdown after echoing 'backup' into a certain file. Then, in /.profile, we have a test of the contents of that file; if it is 'backup', it runs a shell script '/etc/local/backup' which tells the operators which tape(s) to mount before it starts /etc/dump, the output of which is redirected using tee to both the console and /tmp/dump.out (or some such). /bin/awk is then used to see if the dump failed by checking for 'DUMP IS DONE' in /tmp/dump.out. If it failed, it's redone via a goto in /etc/local/backup; if not, the awk script enters a line in /etc/local/dump.inv(entory) listing the file system, mount point, number of tapes required, the date from /etc/dumpdates (or where ever /etc/dump puts it), the label(s) put on the outside of the tape, etc. After the dumps are done, /etc/local/backup exits, returning control to /.profile. If it exited 0, /.profile assumes the dump(s) worked and does a 'kill -9 $$' (which is probably excessive, but you don't want it to fail ...). If /etc/local/backup exits other than 0, /.profile echos 'Backup failed; leave machine down and call so and so at 8am.' to the console. Thus, the operators know exactly what to do at every step and *they never see Unix directly*, so we don't have to train them in it. I am about to totally rewrite our /etc/local/backup to be more generic about which disks are backed up and how often, whether or not it's over the ether- net using rdump, etc., or I would post it. Anyone who wants any of the programs described above should send me mail; if I get enough requests, I'll post everything when I get it in decent shape. Note that it is (and will be) only dependent on /etc/dump in a very small section of /etc/local/backup; if you System V people want to use it with cpio(1) or tar(1), it should be fairly easy. -- ------------------------------------------------------------------------ |"Input!"|"Number 5 is Alive!!"|"Beautiful software"|"Not disassemble!!" ------------------------------------------------------------------------ Will Edgington|Computing and Information Resources, University of Denver (303) 871-2081|BusAd 469, 2020 S. Race, Denver CO 80208 (work)|"Input!!" (303) 759-9071|5001 E. Iliff, Denver CO 80222 (home)|"Where's Input?!!?" {{hplabs,seismo}!hao,ucbvax!nbires,boulder,cires,cisden}!udenva!wedgingt COMING SOON: wedgingt@eos.cair.du.edu, wedgingt@eos.BITNET ( == udenva ) =-=-=-=-=-=-=-=-=-=-=-=-= From adelie!ll-xn!scubed!sdcsvax!sdcc6.UCSD.EDU!ir450 Mon Sep 29 02:24:58 1986 Date: Wed, 24 Sep 86 18:15:42 PDT Subject: Re: Automatic unattended execution of 'dump' ? Organization: Lab for Mathematics and Statistics @ UCSD Well, the most obvious reason is that dump will backup any files changed since the last backup. So even if some files are changed, they will get backed up the next day. Just specify a larger dump number each time the program is run. We use a shell script which keeps track of what the last dump number was, adds one to it and then runs dump. It also loops after 9, so that we get a full dump every 10 dumps. Unless you have special circumstances, you don't need to do anything fancy, just let the program handle all the details. Brian Keves ARPA: keves%ra@sdcsvax.ucsd.edu Lab for Math and Stats UUCP: sdcsvax!ra!keves UCSD, La Jolla, CA PHONE: 619-450-6421 Any opinions expressed are my own and are not the opinions of my employer. =-=-=-=-=-=-=-=-=-=-=-=-= From adelie!ll-xn!cit-vax!mangler Wed Oct 8 10:12:46 EDT 1986 >From: mangler@cit-vax.Caltech.Edu (System Mangler) Date: 5 Oct 86 11:05:04 GMT Organization: California Institute of Technology Summary: multi-user dumps In article <1316@jade.BERKELEY.EDU>, mwm@dunsel.berkeley.edu (Mike Meyer) writes: > Of course, the problem of needing extra tapes, what to do if the dump > or reboot dies, etc. are still there. Me, I'd just dump the stuff late > at night with active file systems and not worry about it. We run dumps > of active systems (at 4-6 in the morning), and have more trouble with > tapes going bad than we do with the file systems being active. 4.[123]bsd /etc/dump requires a human response on /dev/tty if the slightest thing goes wrong. Executing such a program from crontab or /etc/rc is just asking for trouble. Restore is even worse. When dumps take hours on a machine that must be up continuously, such as the sole gateway for an entire campus or the server for all your Suns, there is no choice but to dump active filesystems. We cope by hiring a sophomore to do dumps when activity is light (6 am), and we do them as quickly as possible, so that a minimum of activity transpires during the dump. The activity has messed up lengthy full rdumps; so has media problems. We compensate by doing more full dumps. It's not an issue for daily dumps, where the probability and consequences of a bad dump are both far less. Don Speck speck@vlsi.caltech.edu seismo!cit-vax!speck =-=-=-=-=-=-=-=-=-=-=-=-= From adelie!harvard!wanginst!decvax!uucp Tue Oct 14 01:51:21 1986 Date: Mon, 13 Oct 86 17:14:08 EDT From: harvard!wanginst!decvax!ncoast!greggt Subject: Shell script dump I am a student assistent here at The University of Akron and I have been trying to help the person who is currently doing backups, he would like to do the same thing you described in your posting to usenet. We would be greatfully be happy if such a program exists and would appreciate any help on your part for helping us obtain it. We would also greatly appreciate just the ability to bring "down" the system to a point where people would be logged off and ALL background proccesses which would normally be wiped out when brought down to single user mode just placed into a sleeping state and then back up the system and then revive the programs. If you can help us out in any way PLEASE reply. Any messages that you receive via Mail or News please forward them to me (I hardly have the chance to read news at all anymore). Also please tell me about your system, because we are currently running Ultrix too. Gregg Thompson P.S. Have or know of any drivers or filters to run a LN03 laser printer using tektronix (sp) graphic commands (like a plotter???) =-=-=-=-=-=-=-=-=-=-=-=-= From adelie!necntc!husc6!seismo!cmcl2!phri!bc-cis!preis Thu Nov 13 09:31:38 EST 1986 >From: preis@bc-cis.UUCP (David Preisler) Subject: WANTED: tape backup program for vax780/unix 4.2 bsd Date: 12 Nov 86 16:52:13 GMT We would like a semi-intelligent automated tape backup/recovery program that needs little or no human assistance for at least a week - Places all partitions on one tape and places each day consecutively - so that tapes are stored by week rather then by day. It should also be self starting ( like the Mr Clean utility ). Of course full backups will still have to be done by hand. It's such a good project I would write one myself but I have a full course load already. =-=-=-=-=-=-=-=-=-=-=-=-= Posted-Date: Tue, 3 Mar 87 16:54:53 est Date: Tue, 3 Mar 87 16:54:53 est From: harvard!ll-xn!seismo!mnetor!watmath!dvlmarv!alanm (Alan Matsuoka) To: morgoth!glidden Subject: Re: Automatic unattended dumps Newsgroups: comp.unix.questions,comp.unix.wizards In-Reply-To: <337@morgoth.UUCP> Organization: Develcon Electronics, Toronto I'd be interested in the responses you got. We're an Ultrix site and I know what sort of a pain it is. About five years ago I worked for a 4.1 BSD site and we did two things. 1) We has oodles of disk space so we ran shadow file systems that were dd'ed onto every night. This way, we didn't have to run dumps on an active file system. 2) When we had a system that didn't have that luxury we removed the shadow file system and created a concatenated dump on a raw file system that we used as a spare. We ran those dump overnight as well. The concatenated dump was dd'ed off onto tape after that. Right now, we have one machine that has a shadow file system is updated by a shell script that runs overnight with a transfer to another system over an ethernet. -- -------------------------------------------------------------------------------- Alan Matsuoka, Develcon Electronics, 515 Consumers Road, Suite 500 Willowdale, ON Canada M2J 4Z2 uucp: ...watmath!dvlmarv!alanm phone: (416) 495-8666 =-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-= Date: Wednesday, 4 Mar 1987 14:05:54-PST From: decvax!decwrl!nabeth.dec.com!alan (Alan Rollow It's kind of fun to be extinct ) To: necntc!adelie!morgoth!glidden Subject: Re: Automatic unattended dumps Ken, How have things been going since the DECStart? Did you get on the V2 Field Test? Are you still doing picnics on Thursday? I still think it's a great idea, but we have too many people here... I saw your posting to comp.unix.{questions,wizards} about automatic dumps and took exception to the statement that Ultrix can't do it. The support people may have said that it can't be done, but I know better. Below is a shell script that will arrange for the a standalone script to be created and the system shut down. With the proper mods to /.profile it will run the script when it starts up the single user shell and return the system to multi-user when it's done. A shell programming guru should make the script bullet proof, but it gets you the basic idea. You may re-post this to the net if you want to. The script should be runnable from crontab, but I'll leave that as an exercise to reader. Please notice that the dump command is commented out in this version. I did that to speed up testing. As always this is UNSUPPORTED software provided out of the kindness of my heart and written in reponse to the challange. Since the support moved, I've become a system manager for the workstations (VMS and Ultrix) here in Colorado Springs. I kind of miss the DECstarts and customer visits, but it still pays for CD's. Alan Rollow The "Late" Ultrix Support Group CSC/CS - - - - - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - - - - #! /bin/csh # # By: Alan Rollow, Digital Equipment Corporation. # # This shell script is designed to build a standalone script, # and shut the system down so that the standalone script will # be run. Modifications to /.profile will arrange for the # to system to be brought back up multi-user when the script # is completed. # # This script is not supported by either the author or DIGITAL. # No warranty is express or implied. # # The script may be redistributed at no charge as long as the # author is given proper credit. # # Put the standalone script into /standalone.script # cat <<EOF > /standalone.script # # Put your standalone commands here. The file /.profile will # need to be modifed to check for the existance of /standalone.script # and execute it. The script will have to remove itself and # then exec a command for the system to return to multiuser. # # Use: # # if [ -f /standalone.script ] ; then # /standalone.script # exec echo 'All done.' # fi # echo 'Beginning standalone script.' # # Unmount all the file systems. The "-v" switch causes umount # to be verbose. # /etc/umount -va # # Check the file systems. # /etc/fsck -p # # Command(s) to backup the file systems. # #/etc/dump 0un / # # Forceably remove the standalone script. # /bin/rm -f /standalone.script EOF # # Make the script runnable. # chmod 755 /standalone.script # # Shutdown in 'n' minutes. # /etc/shutdown +1 "Test shutdown script" =-=-=-=-=-=-=-=-=-=-=-=- Posted-Date: Fri, 06 Mar 87 13:00:43 +0000 To: morgoth!glidden Subject: Re: Automatic unattended dumps Newsgroups: comp.unix.questions,comp.unix.wizards In-Reply-To: <337@morgoth.UUCP> Organization: Comp. Sci. Dept., Reading Univ. UK. Date: Fri, 06 Mar 87 13:00:43 +0000 From: Robert Holt <harvard!ll-xn!seismo!mcvax!reading.ac.uk!Robert.T.E.Holt> In article <337@morgoth.UUCP> you write: >In September 1986 I posted a query concerning performing "automatic unattended >dumps". > >I finally took the time to compile the responses and ended up with a 30K file! >It makes for interesting reading though. It includes pointers, possibilites, >suggestions, problems, and a few scripts. (Thanks to all those who responed.) > >Anyone interested? If there is enough interest I'll post, but I'm reluctant >to do so now because of the size of the file. Could you please send me a copy of the above mentioned file. We are very interested in doing unattended dumps. At the moment we have a 'home grown' operators script which requires somebody to be present, but it copes with the cycling levels of the dumps and the rotation of numbered tapes automatically, it also has some useful security features from stopping the operator from breaking in as root. If you want a copy of this script just let me know & I'll see what I can do. Thanks. Robert. ________________________________________________________________________________ Robert Holt UK JANET : robert@onion.cs.rdg.ac.uk Dept. of Computer Science ARPA : robert%onion.cs.reading.ac.uk@ucl-cs.arpa University of Reading Reading, Berks RG6 2AX, England phone : (0734) 755863 ________________________________________________________________________________ ========== LIVE: Ken A. Glidden, (617) 969-0050 ARPA: adelie!morgoth!glidden@harvard.HARVARD.EDU UUCP: {harvard | ll-xn | mirror | axiom}!adelie!morgoth!glidden