home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / bit / listserv / lvmctr / 308 < prev    next >
Encoding:
Text File  |  1992-11-23  |  2.2 KB  |  45 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!RYEVM.RYERSON.CA!SYST8103
  3. Message-ID: <921123.143432.EST.SYST8103@RyeVm.Ryerson.Ca>
  4. Newsgroups: bit.listserv.l-vmctr
  5. Date:         Mon, 23 Nov 1992 14:34:32 EST
  6. Sender:       VMCENTER Components Discussion List <L-VMCTR@AKRONVM.BITNET>
  7. From:         Ron Wigmore <SYST8103@RYEVM.RYERSON.CA>
  8. Subject:      Re: Is Anyone Doing VM/Archive Disastor Recovery
  9. Lines: 34
  10.  
  11. Just an 'off the top of my head' suggestion.  Most probably won't
  12. like it due to their *site specific* needs, but, given the nature
  13. and importance of data on our VMARCH tapes (how much importance do
  14. you assign to student's Archived files of nudie GIFs, etc.?), since
  15. we don't have the resources (system nor personnel) to do offsite
  16. storage of data on VMARCH tapes, the following would meet our needs
  17. without (or at least minimizing) all of the expected VMARCH/VMTAPE
  18. headaches.
  19.  
  20. Setup a dummy frontend to VMARCH and run with two VMARCH IDs.  Have
  21. everyone 'archive' to the frontend.  The frontend then actually Archives
  22. (using the ASSIGN option) the file to the 'ONSITE' VMARCH ID and to the
  23. 'OFFSITE' ID.  The 'ONSITE' ID runs the way it does on all other systems
  24. and so any problems stemming from offsite needs won't affect day-to-day
  25. usage of the 'ONLINE' VMARCH ID. ie. no irate users yelling at you due
  26. to your trying to adapt/meet your 'OFFSITE' needs.
  27.  
  28. The 'OFFSITE' ID closes off each tape as required by your sites needs (ie.
  29. Daily, Weekly, etc.).  When the tape pool for the 'OFFSITE' ID starts to
  30. run low on tapes, bring the tapes back onsite and then run a Merge/Purge.
  31. Then send the M/P'd tapes back offsite.  If you have the resources to go
  32. three months before having to do an 'OFFSITE' M/P, then you only end up
  33. with a headache every three months.  Better that than having to worry
  34. about HDR records, etc. on a Daily basis.
  35.  
  36. Given the volume of our Archive data, the number of tapes available, the
  37. maximum size of any archived files, and other such factors, I could set
  38. up a *non-impressive*, but *gets the job done* package, that would meet
  39. *our sites* needs.  And, I know, the above would not meet the needs of
  40. many sites, but it would meet ours.
  41.  
  42. Just some after lunch thoughts on a cold rainy day ...
  43.  
  44. Ron,,,
  45.