🚀 go-pugleaf

On Mon, 23 Nov 1992 09:49:10 -0500 Martin J. Doyle (215) 752-2296 said:
>Last week I posted a question asking for feedback on a proposed solution
>from Systems Center for addressing disaster recovery concerns for
>VM/Archive.  I got only 2 replies.  One response told me what they
>were doing which is not an adequate for our shop's recovery requirements
>and the other response basically said that Systems Center was goofy
>to think people can implement what they suggested; he had worked in
>two shops which both tried and failed at implementing the solution
>proposed by Systems Center.  I thought System Center's solution sounded
>pretty difficult to implement which is why I asked the question.
>
>With so few replies I have to assume one of the following:
>
>1) Nobody on this list in interested in this topic.  I find this hard
>   to believe because most of the people on this list seem to take
>   what they do too seriously to be apathetic.

There is actually an alternate to this choice: some people are just sorta
stunned by  the concept because  they *forgot* to consider  the VMArchive
tapes as  what they actually  are -- ARCHIVED  DATA which probably  is no
longer still  resident on that precious  DASD that they backed  up, image
copied in duplicate and stored offsite in bootable form.

Now the  dummy who  completely overlooked  this glaring  contradiction at
this ...er a  certain unnamed site... will not be  identified for fear of
embarassing myself. ...err him.

>2) Nobody is providing disaster recovery for VM/Archive.  Based on
>   what is available with the product I would bet that many people
>   have just given up on the possibility of recovering their
>   VM/Archive data in a disaster.

We obviously  are not currently  providing this (see above  remarks.) And
after the subject came up I have pondered the remarks presented and tried
to imagine  just how one COULD  go about providing this  service within a
reasonable framework as  provided by VMArchive. I admit  that I'm stumped
as to  how it  could be  done in a  'pure' form  other than  CLOSEing the
VMArchive twin volume every day and  taking it immediately to the offsite
location. This flies in the face of the method I must use here -- Letting
the tape volume load  to near the end before it is closed.  I do not have
an abundance of  tapes -- certainly not  enough to satisfy a  pool with a
365  volumes  (assuming  a  year's  worth)  plus  enough  to  handle  the
merge/purge condensation. (I'm still using round tapes.)

BTW: There is  one attribute of the merge/purge which  I find annoying --
writing an  output file  (HDR1/2, EOF1/2,  tape-marks, etc.)  for *every*
file  on the  input  tape set  including  a dummy  for  those which  have
expired. You  lose more tape to  HDR, EOF, etc.  than you use in  data in
some cases,  because at least the  data is blocked whereas  those HEADERS
are  F/80 with  the standard  large  IRG eating  up enough  tape to  hold
several K of data.

I suppose the best  case for me is to do a  more frequent merge/purge and
store the twins of the MPU and all CLOSED volumes offsite -- risking only
the data on the current open volumes.

It ain't a perfect world, but it's gonna be the best I can do.

>Which one is it?  Doesn't anybody care or are the tools provided by
>VM/Archive and the architecture of the product itself so limiting that
>they just rule out disaster recovery?  I personally feel that Systems
>Center is out of touch with this issue and need to realize that many
>people have just given up on disaster recovery of VM/Archive.  If
>people can't recover their data in a disaster they just can't afford
>to use the product for production data.

In thinking on this, I suppose my  suggestion for a 'quick' fix by SCI to
the  problem  would be  some  VMArchive  CONFIG  options coupled  with  a
suitable  special ONLINE  pool which  would  be used  to store  "today's"
VMArchived data. Part of the special  CONFIG setup would be a cooperative
interface (or detection) that VMBackup's SYSTEM BACKUP has backed up this
ONLINE pool to the daily incremental, which has of course been TWINed and
the  twin is  taken offsite.  VMArchive could  (via the  CONFIG setup  --
possible coupled with  a VMBackup CONFIG special) detect  that the backup
had been done and clear the ONLINE for use as the next standard backup of
current archive data  use. This would allow the VMArchive  to continue to
utilize his tape  pools to a reasonable level *and*  provide the recovery
capability in the event of some unspeakable horror.

Please, no flames.  This is not intended  as a well designed  plan -- I'm
just  thinking out  loud  and everybody  knows that  my  brain is  unduly
wrinkled.

 ---------------------------------------
   Bill Williams -- ETSU Systems Support
    East
    Tennessee             (615) 929-6853
    State
    University        <CMS2@ETSU.BITNET>