mcitron@phad.hsc.usc.edu (Mark Citron) (12/13/90)
I am running SCO Unix 3.2.0. I have abandoned doing unattended tar backups of my user's files in favor of cpio backups (which I hope will be kinder on my tape drive - it seems to hang often with tar). I was planning to use: find . -print | cpio -ocvB -K149000 > /dev/rct0 2> /usr/lbin/cpioback.log which will be started by crontab and which will produce a log of the backup that went on the night before. I can then peruse the log the next day and make sure everything went OK (or write a script to do that for me, daily). Do I have this backup script correct? Anything you would add? Any comments or suggestions would be welcome. -- Mark Citron mark@neurosci.usc.edu
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/14/90)
In article <28789@usc> mcitron@phad.hsc.usc.edu (Mark Citron) writes: | tape drive - it seems to hang often with tar). I was planning to use: | | find . -print | cpio -ocvB -K149000 > /dev/rct0 2> /usr/lbin/cpioback.log | | which will be started by crontab and which will produce a log of the | backup that went on the night before. | I can then peruse the log the next day and make sure everything went OK | (or write a script to do that for me, daily). | | Do I have this backup script correct? Anything you would add? Almost. You very much want the 'a' option on cpio whenever you do a backup, so you don't reset the access time. The true (user) access time is useful when you want to find files which haven't been accessed for N months and use them as candidates for the bit bucket or archiving. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
bill@unixland.uucp (Bill Heiser) (12/15/90)
>In article <28789@usc> mcitron@phad.hsc.usc.edu (Mark Citron) writes: >| >| find . -print | cpio -ocvB -K149000 > /dev/rct0 2> /usr/lbin/cpioback.log >| >| Do I have this backup script correct? Anything you would add? > I do ours a little differently -- I do a find piped to cpio like you do (but haven't used -K, I'll have to check on that one) -- but instead of directing verbose output to a logfile, I don't use -v. Instead, once the tape has been written, I rewind it and read it back, creating a journal file at that time. This way I get a journal file AND verify that I can at least read through the tape (although I don't think this actually verifies that I can restore any specific file, but I've never had that kind of problem). -- home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill bill@unixland.uucp, bill%unixland.uucp@world.std.com Public Access Unix - Esix SYSVR3 - 508-655-3848 12/24/96-HST 508-651-8733 12/24/96-PEP/V32
tim@comcon.UUCP (Tim Brown) (12/16/90)
In article <28789@usc>, mcitron@phad.hsc.usc.edu (Mark Citron) writes: > > find . -print | cpio -ocvB -K149000 > /dev/rct0 2> /usr/lbin/cpioback.log > > Do I have this backup script correct? Anything you would add? > > -- > Mark Citron > mark@neurosci.usc.edu I use tar. Have had no problems with it. I have had afio hang on me tho. Anyway this is the backup script I use everyday. Here is what I use: # Backup 1.5 90/03/03 11:25:56 # tape backup script PATH=$PATH:/usr/devbin:/etc export PATH case $1 in -d) delay=$2 ;; *) delay=300 ;; esac # notify any users echo " W A R N I N G !!! A backup to tape will be started in five (5) minutes. You will be logged off at that time if you are still here. This is necesary so no data is lost, the backup goes as fast as possible and the integrity of it is maximum. The system will take calls again when it is finished. Thank you. Administration "|wall # wait five .... sleep $delay # switch passwd files # this is something I added ... The programs in /etc/rc4.d are modeled # after those in /etc/rc3.2 etc... # I donot acutally change the run level, I played with that but now I # substitute /bin/sh for /bin/bsh (a fake shell I wrote to echo a # message and then drop the connection. The rc4.d programs also kill # any users still logged in. cd /etc/rc4.d for i in K* do $i start done # backup the files to tape cd / echo Started tape backup at `date`|tee -a /usr/devbin/Backup.log >/dev/console 2>&1 # paths_to_back contains complete paths of top level directories I # want backed up tar cf - `cat /usr/devbin/paths_to_back`|compress |dd of=/dev/rmt0 obs=1024k >/dev/console 2>&1 if [ $? -eq 0 ] then echo Finished tape backup at `date` |tee -a /usr/devbin/Backup.log >/dev/console 2>&1 else echo ERROR!!! Error during tape backup! `date` |tee -a /usr/devbin/Backup.log >/dev/console 2>&1 fi tail -2 /usr/devbin/Backup.log|mail tim # start system back up.... # put passwd back to normal, so it will allow logins. cd /etc/rc4.d for i in S* do $i stop done -- Tim Brown | Computer Connection | uunet!seaeast.wa.com!comcon!tim |
les@chinet.chi.il.us (Leslie Mikesell) (12/18/90)
In article <2630@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: > Almost. You very much want the 'a' option on cpio whenever you do a >backup, so you don't reset the access time. The true (user) access time >is useful when you want to find files which haven't been accessed for N >months and use them as candidates for the bit bucket or archiving. Unfortunately however, in the process of resetting the atime to pretend that you didn't read the file you set the ctime thus indicating an inode modification that you can't tell from some significant change like renaming or changing the owner or modes. Thus, you can't mix using the 'a' option with doing incremental backups based on ctime. The only way to get both things right is to mount the fs read-only while doing the backup or do it across a read-only network mount. Les Mikesell les@chinet.chi.il.us
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/19/90)
In article <1990Dec17.210028.10997@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: | Unfortunately however, in the process of resetting the atime to pretend | that you didn't read the file you set the ctime thus indicating an | inode modification that you can't tell from some significant change | like renaming or changing the owner or modes. Thus, you can't mix | using the 'a' option with doing incremental backups based on ctime. | The only way to get both things right is to mount the fs read-only | while doing the backup or do it across a read-only network mount. This is absolutely correct. Given the choice between not being able to check the ctime, or not being able to detect files which haven't been accessed in a year, my system administration techniques lean heavily toward finding candidates for removal. This is a good point, and although I know how it works I never thought to warn people. I'm going to write a better backup routine in December of 91. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me