home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / bit / listserv / lvmctr / 332 < prev    next >
Encoding:
Text File  |  1993-01-11  |  2.7 KB  |  58 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!paladin.american.edu!auvm!ETSU.BITNET!CMS2
  3. Return-Path: <@VM1.CC.UAKRON.EDU:CMS2@ETSU.BITNET>
  4. Message-ID: <L-VMCTR%93011116022707@VM1.CC.UAKRON.EDU>
  5. Newsgroups: bit.listserv.l-vmctr
  6. Date:         Mon, 11 Jan 1993 15:41:53 EST
  7. Sender:       VMCENTER Components Discussion List <L-VMCTR@AKRONVM.BITNET>
  8. From:         Bill Williams <CMS2@ETSU.BITNET>
  9. Organization: East Tennessee State University
  10. Subject:      Re: VMarchive dasd crash
  11. In-Reply-To:  Message of Sat, 9 Jan 1993 03:57:06 GMT from <STAN@VM.TEMPLE.EDU>
  12. Lines: 44
  13.  
  14. On Sat, 9 Jan 1993 03:57:06 GMT Stan Horwitz said:
  15. >...stuff deleted...                                        exactly  how much
  16. >trouble will we be in if this catalog file become corrupt or destroyed?
  17. >
  18. >The archived  files will  be fine (in  this scenerio), but  we won't  have a
  19. >record  of what's  there.  We  definitely need  a backup  procedure for  the
  20. >master VMArchive catalog  file.  ...
  21. > ...           What I want to know  is if there is anyway of backing up this
  22. >single file  perhaps hourly to another  disk file just in  case the original
  23. >goes bad.  This  way, all we'l lose is an  hour's archiving activity.  Could
  24. >we just schedule a vmschedule job to  kick in every hour and do this backup.
  25. >I was told this wouldn't work, but it seems like a good idea to me.
  26.  
  27. There are several pros/cons here depending upon the size of this catalog
  28. data.  Don't forget your STAGE and ONLINE areas, too!.  How about this:
  29.  
  30. When you get ready for your hourly SUBMIT ARCHIVES you also follow
  31. through with a VMBACKUP to the VMARCH MDisks which contain the VMArchive
  32. data -- catalog, ONLINE, and with proper POST, etc. your STAGE could
  33. catch anything which might be incoming during your SUB ARCHIVEs.
  34.  
  35. The drawback is whether VMARCH will be unavailable during the VMBACKUP
  36. QUIESCE for an unacceptable period of time.  Also, this will be no good
  37. if VMBACKUP takes an hour to back up VMARCHIVE! :-)
  38.  
  39. If this idea doesn't work, you can also have a duplicate MDisks defined
  40. -- the same sizes but on a different HDA -- for the critical VMARCH
  41. MDisks, and have some special userid set up (preferrably OWNING the
  42. duplicate MDIsks) which you VMSchedule to come up with links to the REAL
  43. Mdisks and DDR them once an hour.
  44.  
  45. Both these ideas have holes, but as I hope to imply -- they are just
  46. *IDEAS* and not intended to represent a cookbook.
  47.  
  48. My *best* suggestion is to call SCI Tech Support and ask them!
  49.  
  50. I, too, am curious as to how other sites handle this situation.
  51.  
  52.  ---------------------------------------
  53.    Bill Williams -- ETSU Systems Support
  54.     East
  55.     Tennessee             (615) 929-6853
  56.     State
  57.     University        <CMS2@ETSU.BITNET>
  58.