home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / bit / listserv / lvmctr / 306 < prev    next >
Encoding:
Text File  |  1992-11-23  |  5.3 KB  |  102 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!ETSU.BITNET!CMS2
  3. Organization: East Tennessee State University
  4. Message-ID: <L-VMCTR%92112314040029@VM1.CC.UAKRON.EDU>
  5. Newsgroups: bit.listserv.l-vmctr
  6. Date:         Mon, 23 Nov 1992 14:02:39 EST
  7. Sender:       VMCENTER Components Discussion List <L-VMCTR@AKRONVM.BITNET>
  8. From:         Bill Williams <CMS2@ETSU.BITNET>
  9. Subject:      Re: Is anyone doing VM/Archive disaster recovery?
  10. In-Reply-To:  Message of Mon, 23 Nov 1992 09:49:10 -0500 from <MBDMD@ROHVM1>
  11. Lines: 89
  12.  
  13. On Mon, 23 Nov 1992 09:49:10 -0500 Martin J. Doyle (215) 752-2296 said:
  14. >Last week I posted a question asking for feedback on a proposed solution
  15. >from Systems Center for addressing disaster recovery concerns for
  16. >VM/Archive.  I got only 2 replies.  One response told me what they
  17. >were doing which is not an adequate for our shop's recovery requirements
  18. >and the other response basically said that Systems Center was goofy
  19. >to think people can implement what they suggested; he had worked in
  20. >two shops which both tried and failed at implementing the solution
  21. >proposed by Systems Center.  I thought System Center's solution sounded
  22. >pretty difficult to implement which is why I asked the question.
  23. >
  24. >With so few replies I have to assume one of the following:
  25. >
  26. >1) Nobody on this list in interested in this topic.  I find this hard
  27. >   to believe because most of the people on this list seem to take
  28. >   what they do too seriously to be apathetic.
  29.  
  30. There is actually an alternate to this choice: some people are just sorta
  31. stunned by  the concept because  they *forgot* to consider  the VMArchive
  32. tapes as  what they actually  are -- ARCHIVED  DATA which probably  is no
  33. longer still  resident on that precious  DASD that they backed  up, image
  34. copied in duplicate and stored offsite in bootable form.
  35.  
  36. Now the  dummy who  completely overlooked  this glaring  contradiction at
  37. this ...er a  certain unnamed site... will not be  identified for fear of
  38. embarassing myself. ...err him.
  39.  
  40. >2) Nobody is providing disaster recovery for VM/Archive.  Based on
  41. >   what is available with the product I would bet that many people
  42. >   have just given up on the possibility of recovering their
  43. >   VM/Archive data in a disaster.
  44.  
  45. We obviously  are not currently  providing this (see above  remarks.) And
  46. after the subject came up I have pondered the remarks presented and tried
  47. to imagine  just how one COULD  go about providing this  service within a
  48. reasonable framework as  provided by VMArchive. I admit  that I'm stumped
  49. as to  how it  could be  done in a  'pure' form  other than  CLOSEing the
  50. VMArchive twin volume every day and  taking it immediately to the offsite
  51. location. This flies in the face of the method I must use here -- Letting
  52. the tape volume load  to near the end before it is closed.  I do not have
  53. an abundance of  tapes -- certainly not  enough to satisfy a  pool with a
  54. 365  volumes  (assuming  a  year's  worth)  plus  enough  to  handle  the
  55. merge/purge condensation. (I'm still using round tapes.)
  56.  
  57. BTW: There is  one attribute of the merge/purge which  I find annoying --
  58. writing an  output file  (HDR1/2, EOF1/2,  tape-marks, etc.)  for *every*
  59. file  on the  input  tape set  including  a dummy  for  those which  have
  60. expired. You  lose more tape to  HDR, EOF, etc.  than you use in  data in
  61. some cases,  because at least the  data is blocked whereas  those HEADERS
  62. are  F/80 with  the standard  large  IRG eating  up enough  tape to  hold
  63. several K of data.
  64.  
  65. I suppose the best  case for me is to do a  more frequent merge/purge and
  66. store the twins of the MPU and all CLOSED volumes offsite -- risking only
  67. the data on the current open volumes.
  68.  
  69. It ain't a perfect world, but it's gonna be the best I can do.
  70.  
  71. >Which one is it?  Doesn't anybody care or are the tools provided by
  72. >VM/Archive and the architecture of the product itself so limiting that
  73. >they just rule out disaster recovery?  I personally feel that Systems
  74. >Center is out of touch with this issue and need to realize that many
  75. >people have just given up on disaster recovery of VM/Archive.  If
  76. >people can't recover their data in a disaster they just can't afford
  77. >to use the product for production data.
  78.  
  79. In thinking on this, I suppose my  suggestion for a 'quick' fix by SCI to
  80. the  problem  would be  some  VMArchive  CONFIG  options coupled  with  a
  81. suitable  special ONLINE  pool which  would  be used  to store  "today's"
  82. VMArchived data. Part of the special  CONFIG setup would be a cooperative
  83. interface (or detection) that VMBackup's SYSTEM BACKUP has backed up this
  84. ONLINE pool to the daily incremental, which has of course been TWINed and
  85. the  twin is  taken offsite.  VMArchive could  (via the  CONFIG setup  --
  86. possible coupled with  a VMBackup CONFIG special) detect  that the backup
  87. had been done and clear the ONLINE for use as the next standard backup of
  88. current archive data  use. This would allow the VMArchive  to continue to
  89. utilize his tape  pools to a reasonable level *and*  provide the recovery
  90. capability in the event of some unspeakable horror.
  91.  
  92. Please, no flames.  This is not intended  as a well designed  plan -- I'm
  93. just  thinking out  loud  and everybody  knows that  my  brain is  unduly
  94. wrinkled.
  95.  
  96.  ---------------------------------------
  97.    Bill Williams -- ETSU Systems Support
  98.     East
  99.     Tennessee             (615) 929-6853
  100.     State
  101.     University        <CMS2@ETSU.BITNET>
  102.