home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / bit / listserv / lvmctr / 305 < prev    next >
Encoding:
Text File  |  1992-11-23  |  2.3 KB  |  46 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!MSU.BITNET!19277MAK
  3. Message-ID: <L-VMCTR%92112311520577@VM1.CC.UAKRON.EDU>
  4. Newsgroups: bit.listserv.l-vmctr
  5. Date:         Mon, 23 Nov 1992 11:09:21 EST
  6. Sender:       VMCENTER Components Discussion List <L-VMCTR@AKRONVM.BITNET>
  7. From:         Margaret King <19277MAK@MSU.BITNET>
  8. Subject:      Re: Is anyone doing VM/Archive disaster recovery?
  9. In-Reply-To:  Message of Mon, 23 Nov 1992 09:49:10 -0500 from <MBDMD@ROHVM1>
  10. Lines: 34
  11.  
  12. >1) Nobody on this list in interested in this topic.  I find this hard
  13. ....
  14. >2) Nobody is providing disaster recovery for VM/Archive.  Based on
  15. ....
  16. >Which one is it?
  17.  
  18. At our site we are not taking Archive twins offsite.  It would be a good
  19. thing to do someday but we will probably never take them offsite every day.
  20. We currently have a scheme where we close tapes every three days and then
  21. Merge/Purge them together, in order to optimize tape usage - our VMARCH
  22. usage is so variable that we couldn't figure out a good DSSLIMIT (to avoid
  23. both nearly-empty tapes and continuation reels) any other way.  It took a
  24. while to get that set up and we are still fine-tuning it.  I suppose we
  25. might be able to work offsite twins into this scheme but I agree that the
  26. product is not exactly designed for that.  If you are going to start doing
  27. routine Merge/Purges for combining tapes, bear in mind that it wants an
  28. expired file in the set somewhere or it won't change the database.  At least
  29. that's how it worked when we set up our Merge/Purge scheme, and we have a
  30. VMSCHEDULE job that archives dummy files with very short retention periods
  31. just to take care of this.
  32.  
  33. You said they told you to mark the twins missing.  I don't know if it is
  34. related, but it reminds me of the situation where we had to set up VMBACKUP
  35. to only do one recall at once so that it would not wind up insisting that
  36. a (vaulted) VMBACKUP twin tape be mounted.  I think it would be nice if
  37. Systems Center would have configuration options in VMBACKUP and VMARCHIVE to
  38. say "Don't call for twins on recalls until further notice".
  39.  
  40. We have heard that they are reworking VMARCHIVE so we are waiting to see what
  41. the next one looks like.  VMBACKUP 5.1 was certainly a world apart from
  42. VMBACKUP 4.2.
  43.  
  44. Margaret King
  45. Michigan State University
  46.