home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / perl / 6929 < prev    next >
Encoding:
Text File  |  1992-11-10  |  4.4 KB  |  107 lines
  1. Newsgroups: comp.lang.perl
  2. Path: sparky!uunet!destroyer!cs.ubc.ca!alberta!kakwa.ucs.ualberta.ca!news
  3. From: sherwood@space.ualberta.ca (Sherwood Botsford)
  4. Subject: Re: i need help with tar and tapes drives.
  5. Message-ID: <1992Nov10.181807.23804@kakwa.ucs.ualberta.ca>
  6. Sender: news@kakwa.ucs.ualberta.ca
  7. Nntp-Posting-Host: fenris.space.ualberta.ca
  8. Organization: University Of Alberta, Edmonton Canada
  9. References: <1992Nov9.164953.20181@fnbc.com>
  10. Date: Tue, 10 Nov 1992 18:18:07 GMT
  11. Lines: 94
  12.  
  13. Joseph Alotta writes
  14. > i am trying to tar backup files to tape. 
  15. >  
  16. > i can:
  17. > 
  18. > tar cvf /dev/rst0 /data/*
  19. > tar tvf /dev/rst0
  20. > tar xvf /devrst0  filenames.
  21. > 
  22. > without much problem.
  23. > 
  24. > but since my tape is not filled up, i'd like to append new files to
  25. > the end of it.
  26. > 
  27. >  
  28. > i tried "tar rvf /dev/rst0"  but it didn't work.  seems the r option
  29. > is unsupported on my machine.  
  30. > 
  31. > i ftp'd gnutar and tried "gnutar -Avf /dev/rst0"  but that didn't  
  32. work.
  33. > i got cannot backspace errors.
  34. >  
  35. > people say i should use "mt -f /dev/nrst0 -fsf 99" to get to the end  
  36. of  
  37. > thetape and then "tar cvf /dev/nrst0 *", but i don't like having to  
  38. > remember what segments i've used on the tape and what is in each  
  39. segment.
  40. > 
  41. > can anyone help me to get gnutar to append?
  42. >  
  43. > btw, i am using a archive dat tape and a nextstation 3.0. and perl as  
  44. a
  45. > wrapper for all these commands.
  46. > 
  47. >  
  48. > thanks in advance,
  49.  
  50. Appending in my limited experience only works with 9 track tapes.
  51.  
  52. You have a significant problem with Nexts in that they have a slightly  
  53. flaky interface between the tape driver and the SCSI bus.  This results  
  54. in periodic bus device reset being sent to every device.  The disk  
  55. doesn't care.  It resets, and waits for a new command.  The tape drive  
  56. on reset rewinds the tape.  The frequency of this occurence depends on  
  57. network load, and disk activity, but running backups at night, I was  
  58. getting them about once for every 4 hours of tape operation.   
  59. Increasing nbuf has since made the problem go away, or at least become  
  60. much less frequent.
  61.  
  62. When this happens, the program writing to the tape aborts, but if  
  63. embedded in a script it will carry on.
  64.  
  65. However, that this can happen at all is bad news for anyone putting  
  66. multiple archives on a tape, as a dumb script will happily clobber the  
  67. beginning of your tape.   If you are going to do this, and if your  
  68. files are important, you have to do it right.  This means you must  
  69. check the status of the drive before each write, and on finding an  
  70. error either abort the script, or reposition the tape and start again.
  71.  
  72. What does this have to do with Perl?
  73. [Begin shameless plug...]
  74.  
  75. Well, for Nexts I wrote a set of scripts called TarChive that handle  
  76. this problem from the command line.  It gives you a bit more than you  
  77. want, and it doesn't try to append.  It does however keep track how  
  78. many archives are on a tape and keeps track of what is in each archive.   
  79. It also has a mechanism for labeling tapes, and prevents overwriting  
  80. (by the scripts anyway) by someone other than the user's tape. (Even  
  81. root can't write on your tape:  You might have left it in the drive and  
  82. forgotten that cron was going to run at 2 a.m.)
  83.  
  84. TarChive is not elegant perl.  (Not very perlescent...)  I have used  
  85. perl mostly for structure, with hoards of @message=`commandline parm`.
  86. The backup part is based on gnutar.  The SCSI status is based on  
  87. parsing the output of mt. (This makes it very unportable.  Nobody  
  88. writes mt the same way.)  Tape labels are implemented by putting a very  
  89. short tar file at the beginning of the tape.  Tape ownership is tracked  
  90. by creating a file in /usr/local/tapelabels.  Every archive is written,  
  91. then read and compared to the original.  The output of the compare pass  
  92. is send to a ~/backups/TapeLabel-datestring-dirname so that later you  
  93. don't have to read the tape to find something.  (It has a header that  
  94. tells you that this archive is file number XX on Tape TapeLabel
  95.  
  96. TarChive is rugged however.  If the drive faults, it keeps track of  
  97. what archive it was at, repositions the tape to the beginning of that  
  98. archive, and restarts the operation.  I've had busy days when the drive  
  99. faulted while in the process of repositioning the tape after a fault.   
  100. It recovered from that.
  101.  
  102. Scripts for running a full user back, or for users to backup individual  
  103. directories, for labeling and for erasing tapes are included in the  
  104. package.
  105.  
  106. TarChive is on Sonata.cc.purdue.edu 
  107.