grk@sfsup.UUCP (G.R.Kuntz) (01/16/89)
I guess it's time to do backups :-(. I copied the cpiosize program posted recently to "gators", my 7300 and ran it do see how many disks a full backup would take. I knew it would be a lot but I was still shocked to see "96". I am looking for a way to use "compress" to save a little on that number. I tried compiling the public domain tar that was posted recently and it failed. Does anyone have a simple scheme (aka shell script) that might do this? BTW, I have 3.51a. Please reply by mail and I'll summerize. Thanks in advance. Ralph (attunix.sf.att.com!grk) -- G. Ralph Kuntz N2HBN grk@attunix.att.com
gst@gnosys.UUCP (Gary S. Trujillo) (01/18/89)
In article <4636@sfsup.UUCP> grk@sfsup.UUCP (G.R.Kuntz) writes: >I guess it's time to do backups :-(. > >...Does anyone have a simple scheme (akashell script) that might do this? > > Ralph (attunix.sf.att.com!grk) >-- > G. Ralph Kuntz N2HBN grk@attunix.att.com [I decided to post this message as a followup article, rather than sending it to Ralph directly, just to save him the bother of re-posting it himself.] Here's the script I wrote for the purpose a while back. It doesn't handle compression, but I believe it would not be hard to add it to the script. This past summer, Steve Spearman (ihnp4!ihopa!ihop3!booboo!spear) used the following line in a shell script to do compressed backups he posted to unix-pc.sources (4 Jun 88): cpio -co < $tmp 2> /tmp/ccpio.$$2 | compress | dd of=/dev/rfp021 obs=1024 count=$SIZE 2>/dev/null (I don't understand where Steve gets the magic number 1024 for the output buffer size, but the strategy looks fairly straightforward, and wouldn't be hard to integrate into what I offer below, though I am reluctant to do so yet myself, since I have discovered that already-compressed files which get compressed again as part of a archive fed to a process via a pipeline tend to mess things up to the extent that it seems to confuse compress, and it comes out compressing things in such a way as to not save much space.) What I did to get things going was to use TOUCH(1) to place an explicit timestamp (Oct 1, when I originally installed the 3.51 software) on all my original distribution files, and, after adjusting permissions, did a dump of them. I then did what I call a "pseudo-epoch" (epoch being a term that comes from DUMP(8) found in many UNIX implementations to refer to a level zero dump) of only those files in the "sys" category (defined in the script as excluding a bunch of directories) newer than those I had previously timestamped. For all other disk areas, I did a simple epoch. For each epoch or pseudo-epoch, there is a timestamp file created in the directory /etc/dumpdates: -rw-r--r-- 1 root 0 Nov 28 00:10 epoch.gst -rw-r--r-- 1 root 0 Dec 26 01:59 epoch.guest -rw-r--r-- 1 root 0 Nov 7 02:12 epoch.local -rw-r--r-- 1 root 0 Aug 19 00:00 epoch.news -rw-r--r-- 1 root 0 Dec 11 11:56 epoch.sys -rw-r--r-- 1 root 0 Oct 1 1987 epoch.sysabs I also keep a log of what I've dumped in this same directory: -rw-rw-r-- 1 root 6030 Jan 14 16:32 dumplog which has the following sort of content: idump local Mon Dec 26 01:37:03 EST 1988 idump news Mon Dec 26 01:48:04 EST 1988 idump gst Mon Dec 26 01:53:39 EST 1988 edump guest Mon Dec 26 01:59:54 EST 1988 idump sys Mon Dec 26 02:06:31 EST 1988 idump gst Mon Jan 2 16:31:16 EST 1989 idump news Mon Jan 2 16:37:52 EST 1989 idump local Mon Jan 2 16:40:53 EST 1989 idump sys Mon Jan 2 16:46:23 EST 1989 idump gst Sat Jan 14 16:09:49 EST 1989 idump sys Sat Jan 14 16:32:52 EST 1989 The script goes (via a link) both by the name "edump" (epoch) and "idump" (incremental). It takes a single argument, that being the name of the disk "area" you want to dump. For example, I typically do something like the following on a regular basis: idump local idump news edump guest (there's not much there, so I do an epoch dump) idump gst idump sys (this one's last so that the timestamp files from today's dumps in /etc/dumpdates are saved) Here is the script itself. I welcome any feedback or improvements people would like to offer, and will gladly repost the results to unix-pc.sources. Since Ralph asked the original question about dumps, he's still the best one to whom to send other solutions to the overall dump question. I'll look forward to his summary of these other solutions, so that perhaps we can take the best of each and fabricate something really spiffy! ---------------------------------(cut here)------------------------------------ if [ $# != 1 ] then echo "usage [ei]dump type" exit 1 fi ddroot="/etc/dumpdates" if [ $0 = edump ] then if [ $1 = sys ] then newer=-newer ddfile=$ddroot/epoch.sysabs fi else newer=-newer ddfile=$ddroot/epoch.$1 fi if [ -n "$newer" ] # incremental or sys epoch then # newer than what? if [ ! -f $ddfile ] then echo "cannot locate timestamp file for dump of $1" echo "$ddfile" exit 2 fi fi exclude=\'\' # initially null p1=. p2= case $1 in sys) path=/ exclude='^dev|^u/g|^u/src|^usr/local|^usr/spool|^tmp|^usr/uucppublic|^usr/man|^lost\+found|^usr/preserve|^usr/lib/news|^usr/adm|^usr/bin/DOS|^usr/mail';; gst) path=~gst exclude='^\.files|^\.nfiles';; src) path=~src;; news) path=~gnews/News;; guest) path=/u/g;; local) path=/ p1=/usr/local p2=/usr/man;; *) echo "dump keyword $1 invalid" exit 3;; esac cd $path find $p1 $p2 $newer $ddfile -depth -print | sed 's/^\.*\///' \ | egrep -v $exclude \ | cpio -ocvB \ > /dev/rfp021 # the code below creates a timestamp file if the dump is an epoch dump if [ $0 = edump ] then touch $ddroot/epoch.$1 fi echo "$0 $1 `date`" >> $ddroot/dumplog ls -l $ddroot/dumplog -- Gary S. Trujillo {linus,bbn,m2c}!spdcc!gnosys!gst Somerville, Massachusetts {icus,ima,stech,wjh12}!gnosys!gst