Re: "snapshot" backup and HBVS - VMS

This is a discussion on Re: "snapshot" backup and HBVS - VMS ; helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) wrote on 12/11/2007 03:46:07 AM: > In article > , Rob > writes: > > > Phillip, it sounds like you're using a HSG or EVA array for your data > > already, as ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Re: "snapshot" backup and HBVS

  1. Re: "snapshot" backup and HBVS

    helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)
    wrote on 12/11/2007 03:46:07 AM:

    > In article
    > <6db9ef31-8aa6-47cb-8aba-a8577cee1d79@p69g2000hsa.googlegroups.com>, Rob
    > writes:
    >
    > > Phillip, it sounds like you're using a HSG or EVA array for your data
    > > already, as you use the term 'Snapshot'.

    >
    > Don't read too much into that. The question is quite general and could
    > just as well apply to my hobbyist system with physical SCSI disks
    > connected to VAXstations. I just used the term "snapshot" to indicate
    > that I don't need a backup which is restorable to an arbitrary point in
    > time, but rather one which is restorable to a daily "snapshot".
    >
    > > If so, I don't understand why you don't use the array to create the
    > > copy for you?

    >
    > Let me phrase it another way. This is ALMOST what I want: Once a day,
    > mount a third member into the shadow set, let it get updated via
    > minicopy, then dismount it (at this special time, a clean dismount is
    > possible). That's my "snapshot". A day later, repeat. Since the
    > changes get updated via minicopy, it's fast enough. This is OK as far
    > as it goes, but it doesn't go far enough---because the snapshot backup
    > is just one disk. Yes, I could make a copy of that, but that would be a


    > full copy and would thus take too long. Also, depending on how I do it,


    > the next minicopy update might no longer work.
    >

    ITSM it was suggested that the third member cosist of a 2-spindle
    mirror-set
    from the SAN. Then, if you need to use the third volume, you split it
    into
    two separate 1-spindle LUNs and mount them as a shadow-set pair. Now you
    have recovered with a shadowset, and your only problem is getting a new
    2-spindle mirror-set from the SAN copied into the shadow-set, and that
    seems
    to require a full copy, but you have your 2-disk shadow set back.
    That's really close to what you seem to need.

  2. Re: "snapshot" backup and HBVS

    In article
    ,
    norm.raphael@metso.com writes:

    > ITSM it was suggested that the third member cosist of a 2-spindle
    > mirror-set
    > from the SAN. Then, if you need to use the third volume, you split it
    > into
    > two separate 1-spindle LUNs and mount them as a shadow-set pair.


    Will that force a full copy?

    > Now you
    > have recovered with a shadowset, and your only problem is getting a new
    > 2-spindle mirror-set from the SAN copied into the shadow-set, and that
    > seems
    > to require a full copy, but you have your 2-disk shadow set back.
    > That's really close to what you seem to need.



  3. Re: "snapshot" backup and HBVS

    helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:

    >In article
    >,
    >norm.raphael@metso.com writes:


    >> ITSM it was suggested that the third member cosist of a 2-spindle
    >> mirror-set
    >> from the SAN. Then, if you need to use the third volume, you split it
    >> into
    >> two separate 1-spindle LUNs and mount them as a shadow-set pair.


    >Will that force a full copy?


    No.

    However, you have to be careful with the MOUNT command since the disks
    will have the same label as the shadowset they came from but different
    VMS device names, which will not match the names in the SCB.

  4. Re: "snapshot" backup and HBVS

    In article , moroney@world.std.spaamtrap.com
    (Michael Moroney) writes:

    > helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    >
    > >In article
    > >,
    > >norm.raphael@metso.com writes:

    >
    > >> ITSM it was suggested that the third member cosist of a 2-spindle
    > >> mirror-set
    > >> from the SAN. Then, if you need to use the third volume, you split it
    > >> into
    > >> two separate 1-spindle LUNs and mount them as a shadow-set pair.

    >
    > >Will that force a full copy?

    >
    > No.
    >
    > However, you have to be careful with the MOUNT command since the disks
    > will have the same label as the shadowset they came from but different
    > VMS device names, which will not match the names in the SCB.


    Precisely. In the case that I have to resort to the backup, then of
    course the first time I make a new backup copy, it has to be a full
    copy. There is no way around that. However, even if the contents are
    the same, if I split a mirror set and then mount it as a shadow set, as
    far as VMS is concerned this is a new shadow set---VMS doesn't know that
    the contents are identical. Surely it's not enough to just say No when
    asked if a full copy should be done?!


  5. Re: "snapshot" backup and HBVS

    helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:

    > However, even if the contents are
    >the same, if I split a mirror set and then mount it as a shadow set, as
    >far as VMS is concerned this is a new shadow set---VMS doesn't know that
    >the contents are identical.


    Sure it does. When you issue a $ MOUNT, MOUNT looks at the SCB and sees
    the disk is a shadowset and acts appropiately. If you issue a
    $ MOUNT /SHADOW=(member1,member2), MOUNT sees the two members are
    consistent (since the SCBs are identical and that of a shadowset member,
    or had better be!) so it knows it can form a shadowset with no copy
    required, as long as they were full members when removed from the original
    shadowset. However the shadowset members listed in the SCB will *not*
    match the names of the former RAID set members so you have to be careful
    not to specify parameters such as /INCLUDE.

    > Surely it's not enough to just say No when
    >asked if a full copy should be done?!


    It'll know that no copy is necessary.

  6. Re: "snapshot" backup and HBVS

    In article , moroney@world.std.spaamtrap.com
    (Michael Moroney) writes:

    > helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    >
    > > However, even if the contents are
    > >the same, if I split a mirror set and then mount it as a shadow set, as
    > >far as VMS is concerned this is a new shadow set---VMS doesn't know that
    > >the contents are identical.

    >
    > Sure it does. When you issue a $ MOUNT, MOUNT looks at the SCB and sees
    > the disk is a shadowset and acts appropiately.


    Of course. However, if the two disks had been part of a mirror set
    (i.e. controller-level shadowing), then, as far as VMS is concerned,
    they have nothing to do with a HBVS shadow set until they are mounted.

    > If you issue a
    > $ MOUNT /SHADOW=(member1,member2), MOUNT sees the two members are
    > consistent (since the SCBs are identical and that of a shadowset member,
    > or had better be!) so it knows it can form a shadowset with no copy
    > required, as long as they were full members when removed from the original
    > shadowset.


    If they are full members when removed, THEN set up as part of a
    controller-based mirror set, THEN remounted as a shadow set, will that
    still work?

    > However the shadowset members listed in the SCB will *not*
    > match the names of the former RAID set members so you have to be careful
    > not to specify parameters such as /INCLUDE.


    Yes, that part is clear.


  7. Re: "snapshot" backup and HBVS

    helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:

    >In article , moroney@world.std.spaamtrap.com
    >(Michael Moroney) writes:


    >> helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    >>
    >> > However, even if the contents are
    >> >the same, if I split a mirror set and then mount it as a shadow set, as
    >> >far as VMS is concerned this is a new shadow set---VMS doesn't know that
    >> >the contents are identical.

    >>
    >> Sure it does. When you issue a $ MOUNT, MOUNT looks at the SCB and sees
    >> the disk is a shadowset and acts appropiately.


    >Of course. However, if the two disks had been part of a mirror set
    >(i.e. controller-level shadowing), then, as far as VMS is concerned,
    >they have nothing to do with a HBVS shadow set until they are mounted.


    Why do you say that? If the mirror set was part of a shadowset, the SCBs
    of the members will be that of a shadowset member. If the mirror FW does
    what it is supposed to, the entire drives (specifically the SCBs) will
    be identical. Disks with identical SCBs will be considered valid shadowset
    members.

    The RAID metadata is not relevant. If it's on disk blocks, it'll be on
    blocks not even visible to VMS.

    >> If you issue a
    >> $ MOUNT /SHADOW=(member1,member2), MOUNT sees the two members are
    >> consistent (since the SCBs are identical and that of a shadowset member,
    >> or had better be!) so it knows it can form a shadowset with no copy
    >> required, as long as they were full members when removed from the original
    >> shadowset.


    >If they are full members when removed, THEN set up as part of a
    >controller-based mirror set, THEN remounted as a shadow set, will that
    >still work?


    Since the RAID firmware will certainly copy one disk to the other, I
    see no purpose of the first step.


  8. RE: "snapshot" backup and HBVS



    > -----Original Message-----
    > From: Phillip Helbig---remove CLOTHES to reply
    > [mailto:helbig@astro.multiCLOTHESvax.de]
    > Sent: December 16, 2007 5:57 AM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: Re: "snapshot" backup and HBVS
    >
    > In article ,
    > moroney@world.std.spaamtrap.com
    > (Michael Moroney) writes:
    >
    > > helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to

    > reply) writes:
    > >
    > > > However, even if the contents are
    > > >the same, if I split a mirror set and then mount it as a shadow set,

    > as
    > > >far as VMS is concerned this is a new shadow set---VMS doesn't know

    > that
    > > >the contents are identical.

    > >
    > > Sure it does. When you issue a $ MOUNT, MOUNT looks at the SCB and

    > sees
    > > the disk is a shadowset and acts appropiately.

    >
    > Of course. However, if the two disks had been part of a mirror set
    > (i.e. controller-level shadowing), then, as far as VMS is concerned,
    > they have nothing to do with a HBVS shadow set until they are mounted.
    >
    > > If you issue a
    > > $ MOUNT /SHADOW=(member1,member2), MOUNT sees the two members are
    > > consistent (since the SCBs are identical and that of a shadowset

    > member,
    > > or had better be!) so it knows it can form a shadowset with no copy
    > > required, as long as they were full members when removed from the

    > original
    > > shadowset.

    >
    > If they are full members when removed, THEN set up as part of a
    > controller-based mirror set, THEN remounted as a shadow set, will that
    > still work?
    >
    > > However the shadowset members listed in the SCB will *not*
    > > match the names of the former RAID set members so you have to be

    > careful
    > > not to specify parameters such as /INCLUDE.

    >
    > Yes, that part is clear.


    Phillip,

    When using controller RAID devices with HBVS, you do not ever break the
    controller RAID - it always stays together.

    However, from an OpenVMS view, it simply looks like a single hard drive.

    Hence, when OpenVMS thinks you are down to a single device, it is really
    the HW raid set, so you are protected from a single drive failure in
    a single volume HBVS set.

    Another advantage with this is that drive rebuilds after failure are done
    at the HW RAID controller level and hence does not impact PCI buses, FC
    adapters, or any host based cycles.

    The only problem with this strategy is that it sometimes works to well
    i.e. a single drive fails in a set and no one notices it. Then a few
    months later, a second drive fails and then that's it - everyone out
    of the pool ..

    :-)


    Regards

    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-592-4660
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.






  9. Re: "snapshot" backup and HBVS

    In article , moroney@world.std.spaamtrap.com
    (Michael Moroney) writes:

    > >> > However, even if the contents are
    > >> >the same, if I split a mirror set and then mount it as a shadow set, as
    > >> >far as VMS is concerned this is a new shadow set---VMS doesn't know that
    > >> >the contents are identical.
    > >>
    > >> Sure it does. When you issue a $ MOUNT, MOUNT looks at the SCB and sees
    > >> the disk is a shadowset and acts appropiately.

    >
    > >Of course. However, if the two disks had been part of a mirror set
    > >(i.e. controller-level shadowing), then, as far as VMS is concerned,
    > >they have nothing to do with a HBVS shadow set until they are mounted.

    >
    > Why do you say that? If the mirror set was part of a shadowset, the SCBs
    > of the members will be that of a shadowset member. If the mirror FW does
    > what it is supposed to, the entire drives (specifically the SCBs) will
    > be identical. Disks with identical SCBs will be considered valid shadowset
    > members.


    OK, worth a try.

    > The RAID metadata is not relevant. If it's on disk blocks, it'll be on
    > blocks not even visible to VMS.


    OK.


+ Reply to Thread