Host-based vs. controller-based shadowing

Host-based vs. controller-based shadowing

Post by Drew Shelto » Fri, 13 Mar 1998 04:00:00



I recently bought some HSJ50's, and I was wondering if I should convert to
controller-based mirrorsets or stick with host-based shadowing (phase II).
Are there any advantages/disadvantages to controller-based mirroring?

Thanks,
Drew

==============================================================================

VMS Systems Manager                  512-356-7575
Sematech
2706 Montopolis Drive                I speak for myself only, not Sematech.
Austin, TX 78741-6499
    "There are two major products that come out of Berkeley: LSD and UNIX.
    We don't believe this to be a coincidence." - Jeremy S. Anderson
==============================================================================

 
 
 

Host-based vs. controller-based shadowing

Post by WILLIAM WEB » Fri, 13 Mar 1998 04:00:00


-I recently bought some HSJ50's, and I was wondering if I should conver=
t to
-controller-based mirrorsets or stick with host-based shadowing (phase =
II).
-Are there any advantages/disadvantages to controller-based mirroring?

-Thanks,
-Drew

-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D

-VMS Systems Manager                  512-356-7575
-Sematech
-2706 Montopolis Drive                I speak for myself only, not Sema=
tech.
-Austin, TX 78741-6499
-    "There are two major products that come out of Berkeley: LSD and
-    UNIX. We don't believe this to be a coincidence." - Jeremy S. Ande=
rson
-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D

It all depends on where you're going.

RTFM tells me that VMS 7.1 doesn't support host-based shadowing.

As part of our drive to have everything nice and Y2K compliant,
(and hardware-ready for a nationwide upgrade to 7.1), I've been
managing a project where we're replacing all of our MTI drives
nationwide (that incidentally are using host-based shadowing in
some locations) with HSDxxs/BAxxs or SWxxs/RZ2Xs.

Now it looks like I'm going to be upgrading all the HSD30s to
HSD50s and getting rid of our RF31s and RF72s as well.

(It took the proceeds from a LOT of stamps to pay for this
project) :)

----------------------------------------------------------------
William W. Webb - Senior OpenVMS Systems Support Technician
contractor: Central Management Facility/VAX Systems Support
National Information Systems Support Center, USPS


=

 
 
 

Host-based vs. controller-based shadowing

Post by fairfi.. » Fri, 13 Mar 1998 04:00:00




Quote:> I recently bought some HSJ50's, and I was wondering if I should convert to
> controller-based mirrorsets or stick with host-based shadowing (phase II).
> Are there any advantages/disadvantages to controller-based mirroring?

        I've posted a number of times on  this topic, but at the risk of
    boring everyone, here's my take on the subject, one more time.  :-)

        I depends in on your  requirements,  of  course.  Do you need to
    avoid  any  single point of failure, that is, is  availability  your
    primary criterion?  Or is making maximum use of the  the  admittedly
    expensive  controllers  more  important?  Are you doing a split-site
    cluster, for example?

        As background, we had all our  storage on HSC's, with RA9x's and
    RA7x's  dual  ported to pairs of HSC's so we had no single point  of
    failure.  We had three VAX6xxx's on the  CI  serving  the  disks  to
    about  30  VAXstations.   I think the most important problems in our
    environment were that (a) the  system  disk was shadowed and (b) the
    quorum disk could not be shadowed.  Because of (a) any system crash,
    including  workstation  crashes,  would lead to a full  system  disk
    merge.  _That_  was  always  painful!   Because  of  (b)  we  had  a
    potential  single  point  of failure...which we finessed by suitable
    choice of votes, expected_votes, and qdskvotes such that the cluster
    would maintain quorum if all CI nodes were up but we lost the quorum
    disk [comments about not needing a quorum disk in this configuration
    are noted...we need the flexibility to run the cluster with a single
    voting node up].  The  more  shadow  sets  that were merging after a
    crash, the worse it was, of course.  [And for reasons that are still
    unclear  to me, I was very difficult to do even a normal shutdown of
    a CI node without generating at least a  _few_  full  merges...some-
    thing  about one of the nodes not receiving the shutting node's last
    gasp message...]

        When we added the HSJ52/SW300 storage, I moved the VAX and (new)
    Alpha system disks to  the  HSJ's.   I've  configured  _most_ of the
    disks in the SW300 as 2-member mirror sets and I've split the mirror
    sets  between  the two HSJ's.  So I can survive a disk failure or  a
    controller failure.  I can even survive a power-supply failure,  but
    we  have only _one_ power-cord, so I'm susceptible to that circuit's
    breaker tripping (I didn't add  the  full  PS redundancy which would
    give  an additional power-cord/circuit).  Also, one can upgrade  the
    controller firmware in with a live cluster  in  this  dual-redundant
    configuration.

        The upshot is  that  I  don't  see  any  shadow merges or shadow
    copies  on the HSJ-hosted storage, and I can (and do) use one of the
    system disks  as  the  quorum  disk.   So  I've  totally  eliminated
    problems  (a)  and  (b).   At  the  same  time,  I've maintained the
    availability I had with HBVS of dual-ported, RAxx disks on redundant
    HSC's.  Performance is greatly improved,  by  the way, and even when
    there  is  a  system  crash  which results in one  or  more  of  the
    remaining  HBVS's  to  merge,  since  the  system  disk(s)  are  not
    involved,  cluster  performance  is  hardly  affected.   [NB:  since
    installing the VAXCLUSIO and  ALPCLUSIO  and associated ECO's, I see
    far  _fewer_ full merges when a system crashes...I highly  recommend
    installing it on any cluster V6.2 or V6.2-1H3 regardless of  whether
    you anticipate running with a V7.1 node or not.]

        The down side is that, at  any  one time I'm only using half the
    capacity   of  either  HSJ50.   To  use  the  full  capacity   while
    maintaining redundancy, I'd put  a  single  HSJ50  in  each  of  two
    SW300's  (or  other  cabinet)  and use HBVS to shadow volumes having
    each shadow set's two members on different a HSJ.

        So there's a cost/benefit analysis  to  be  done here.  I gather
    from  some  of Ed Wilt's posts in the past, that he chose to  remain
    with HBVS in his former  cluster,  so  you  can  rest  assured  that
    there's  nothing  inherently wrong with that approach. :-)  Also, if
    your cluster is fairly stable,  like  you don't have old VAXstations
    regularly  crashing,  and you don't have site power dropping out  on
    you once or twice a year, then the problems of shadow  merges/copies
    that made my life miserable won't necessarily be a factor for you.

        But I will say, I _really_, _really_ like my HSJ52's controller-
    based mirroring (and partitioning, etc.).  :-)

        -Ken
--

 SLAC, P.O.Box 4349, MS 46  |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309       |  Voice:    650-926-2924    FAX: 650-926-3515
 -------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...

 
 
 

Host-based vs. controller-based shadowing

Post by fairfi.. » Fri, 13 Mar 1998 04:00:00




[...much snippage...]

Quote:> RTFM tells me that VMS 7.1 doesn't support host-based shadowing.

        Nonsense.  Tell that to my little  AXP 3000/400s running V7.1 in
    a  mixed-architecture, mixed-interconnect, mixed-version  VMScluster
    (VAX/V6.2, Alpha/V6.2-1H3, Alpha/V7.1)!  Better RTFM again...

        -Ken
--

 SLAC, P.O.Box 4349, MS 46  |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309       |  Voice:    650-926-2924    FAX: 650-926-3515
 -------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...

 
 
 

Host-based vs. controller-based shadowing

Post by Dan O'Reill » Sat, 14 Mar 1998 04:00:00


My take on controller-based shadowing:

Advantages:

- You don't use CPU cycles to mirror.
- You don't use twice the I/O bandwidth to mirror.

Disadvantage:

- You can't mirror into different cabinets for fault tolerance.
- You can't mirror between different CI adapters for fault tolerance.

For most people, the disadvantages aren't that big a deal, especially
if they aren't running multiple CI controllers or storage cabs.  


Quote:>I recently bought some HSJ50's, and I was wondering if I should convert to
>controller-based mirrorsets or stick with host-based shadowing (phase II).
>Are there any advantages/disadvantages to controller-based mirroring?

--
Dan O'Reilly
MCI Telcommunications
Systems Engineering/BT NIP
MS 1183/117
2424 Garden of the Gods Rd
Colorado Springs, CO  80919
719-535-1418
 
 
 

Host-based vs. controller-based shadowing

Post by Michael Moron » Sat, 14 Mar 1998 04:00:00




> RTFM tells me that VMS 7.1 doesn't support host-based shadowing.

Not only does V7.1 support host-based shadowing, shadowing was essentially
rewritten for V7.1.  (it's now also in the xxxCLUSIO patch for V6.2)

-Mike (who poured a lot of sweat into the new Shadowing code)

 
 
 

Host-based vs. controller-based shadowing

Post by J.L. S » Sat, 14 Mar 1998 04:00:00


On Thu, 12 Mar 1998 16:47:37 -0500, WILLIAM WEBB


>RTFM tells me that VMS 7.1 doesn't support host-based shadowing.

Could you cite exact references from your RTFM?
I know from experience this is not a true statement... in fact, 7.1
increase the total number of possible shadowset members (not all in
the same shadowset) to 500!

Quote:>As part of our drive to have everything nice and Y2K compliant,
>(and hardware-ready for a nationwide upgrade to 7.1), I've been
>managing a project where we're replacing all of our MTI drives
>nationwide (that incidentally are using host-based shadowing in
>some locations) with HSDxxs/BAxxs or SWxxs/RZ2Xs.

>Now it looks like I'm going to be upgrading all the HSD30s to
>HSD50s and getting rid of our RF31s and RF72s as well.

>(It took the proceeds from a LOT of stamps to pay for this
>project) :)

Save the money! (and lower our stamp costs)

JLS
P.S. -- How's the ol' USPS... I almost accepted a job with them back
in '95, to work in Raleigh NC...  
------------
JLS
This is me speaking.  I figure I can say *anything*
I want... nobody every listens to me anyway.
(remove the "x-" from my address to e-mail)

 
 
 

Host-based vs. controller-based shadowing

Post by Ed Wilt » Sun, 15 Mar 1998 04:00:00





>> I recently bought some HSJ50's, and I was wondering if I should convert
to
>> controller-based mirrorsets or stick with host-based shadowing (phase
II).
>> Are there any advantages/disadvantages to controller-based mirroring?

>        I've posted a number of times on  this topic, but at the risk of
>    boring everyone, here's my take on the subject, one more time.  :-)

>        I depends in on your  requirements,  of  course.  Do you need to
>    avoid  any  single point of failure, that is, is  availability  your
>    primary criterion?  Or is making maximum use of the  the  admittedly
>    expensive  controllers  more  important?  Are you doing a split-site
>    cluster, for example?

>        As background, we had all our  storage on HSC's, with RA9x's and
>    RA7x's  dual  ported to pairs of HSC's so we had no single point  of
>    failure.  We had three VAX6xxx's on the  CI  serving  the  disks  to
>    about  30  VAXstations.   I think the most important problems in our
>    environment were that (a) the  system  disk was shadowed and (b) the
>    quorum disk could not be shadowed.  Because of (a) any system crash,
>    including  workstation  crashes,  would lead to a full  system  disk
>    merge.  _That_  was  always  painful!   Because  of  (b)  we  had  a
>    potential  single  point  of failure...which we finessed by suitable
>    choice of votes, expected_votes, and qdskvotes such that the cluster
>    would maintain quorum if all CI nodes were up but we lost the quorum
>    disk [comments about not needing a quorum disk in this configuration
>    are noted...we need the flexibility to run the cluster with a single
>    voting node up].  The  more  shadow  sets  that were merging after a
>    crash, the worse it was, of course.  [And for reasons that are still
>    unclear  to me, I was very difficult to do even a normal shutdown of
>    a CI node without generating at least a  _few_  full  merges...some-
>    thing  about one of the nodes not receiving the shutting node's last
>    gasp message...]

>        When we added the HSJ52/SW300 storage, I moved the VAX and (new)
>    Alpha system disks to  the  HSJ's.   I've  configured  _most_ of the
>    disks in the SW300 as 2-member mirror sets and I've split the mirror
>    sets  between  the two HSJ's.  So I can survive a disk failure or  a
>    controller failure.

Actually, you've got a false sense of security (albeit small).  In some
cases, you can NOT survive a disk failure.  Speaking from experience here
(sigh...), I've had a disk go bad in such a way that the it hung the SCSI
bus.  The HSJ (a -40 in this case) tried to clear the problem by crashing
itself.  Somebody wasn't thinking the situation through fully here when they
designed this, since you can guess what happens next.  The disk fails over
the redundant controller, like it should.  Oops, the bus is still hung.
Yup, the second controller crashes.  By now, the first controller is back
up, takes control of the failed disk, and crashes.  Repeat forever...  Oops,
some critical drives are on that controller pair.  Oops, there goes the
cluster.  MAJOR OOPS!  My first change window at a new job (less than a week
later), and I had the drive fail right after an install of the CLUSIO patch
that replaces the shadowing software.  Drove me nuts, and still worries me.

I worked this through with Digital for a month or so, and Digital
Engineering even took the drive for analysis.  The upshot of all this is
that the problem is there, isn't likely to be fixed, and they suggested that
I never plug the drive in again.  I sent it to them for replacement :-).

I've been torn between controller-based mirroring and host-based shadowing.
My thinking now is that I'll continue to use HBVS, and make sure that I
split drives across cabinets, not controllers (currently my cluster is
configured with both members of the shadow set in the same cabinet, sharing
the redundant controller pair).

I may have to change my thinking later this year as we go to a
disaster-tolerant cluster.  HBVS only supports 3 member shadow sets, so I
can't shadow in 2 physical locations.  I'll have to choose between 2 member
sets, one at each site, or mirroring within each site, and then shadowing
across the sites.  If I don't take the latter option, and if I do lose a
site, I've suddenly lost all shadowing, and I'd be forced to scramble to
roll in 200+GB of disk space to re-shadow everything on short notice.

Quote:>        So there's a cost/benefit analysis  to  be  done here.  I gather
>    from  some  of Ed Wilt's posts in the past, that he chose to  remain
>    with HBVS in his former  cluster,  so  you  can  rest  assured  that
>    there's  nothing  inherently wrong with that approach. :-)

Thanks.  I don't believe that there is inherently wrong with either
approach.  There are costs and benefits (and risks) associated with both
options.  The nice thing is that Digital allows us to choose which one is
right for our own individual requirements.  The tricky part is that we all
have to understand those risks and benefits to make an intelligent decision.

    .../Ed (who's playing with a new News client but isn't ready to commit
to a switch yet)

Ed Wilts
Mounds View, MN

 
 
 

Host-based vs. controller-based shadowing

Post by Larry Kilgall » Sun, 15 Mar 1998 04:00:00



> I know from experience this is not a true statement... in fact, 7.1
> increase the total number of possible shadowset members (not all in
> the same shadowset) to 500!

I bet if they were all in the same shadowset, rebuild time would be even
slower :-).

Larry Kilgallen

 
 
 

Host-based vs. controller-based shadowing

Post by fairfi.. » Sun, 15 Mar 1998 04:00:00




[snippage]

Quote:>>        When we added the HSJ52/SW300 storage, I moved the VAX and (new)
>>    Alpha system disks to  the  HSJ's.   I've  configured  _most_ of the
>>    disks in the SW300 as 2-member mirror sets and I've split the mirror
>>    sets  between  the two HSJ's.  So I can survive a disk failure or  a
>>    controller failure.

> Actually, you've got a false sense of security (albeit small).  In some
> cases, you can NOT survive a disk failure.  Speaking from experience here
> (sigh...), I've had a disk go bad in such a way that the it hung the SCSI
> bus.  The HSJ (a -40 in this case) tried to clear the problem by crashing
> itself.  Somebody wasn't thinking the situation through fully here when they
> designed this, since you can guess what happens next.  The disk fails over
> the redundant controller, like it should.  Oops, the bus is still hung.
> Yup, the second controller crashes.  By now, the first controller is back
> up, takes control of the failed disk, and crashes.  Repeat forever...  Oops,
> some critical drives are on that controller pair.  Oops, there goes the
> cluster.  MAJOR OOPS!  My first change window at a new job (less than a week
> later), and I had the drive fail right after an install of the CLUSIO patch
> that replaces the shadowing software.  Drove me nuts, and still worries me.

        I remember this story, er, nightmare.   But I'd be interested to
    know whether this is inherent in the design of the HSJ's, or whether
    it  may be dependent upon the firmware.  Am I right that the HSJ40's
    run HSOF 3.x?  The HSJ50's  run  HSOF  5.x  (I'm  at  V5.1)  so  the
    behaviour  of  these  controllers  in  a  situation similar to yours
    _could_ be  different.   Nevertheless,  your  point  is  well taken!
    Given  a  hardware  problem, software can not be  expected  to  work
    reliably!!

        -Ken
--

 SLAC, P.O.Box 4349, MS 46  |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309       |  Voice:    650-926-2924    FAX: 650-926-3515
 -------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...

 
 
 

Host-based vs. controller-based shadowing

Post by Veli K?rkk » Mon, 16 Mar 1998 04:00:00



> My take on controller-based shadowing:

> Advantages:

> - You don't use CPU cycles to mirror.
> - You don't use twice the I/O bandwidth to mirror.

> Disadvantage:

> - You can't mirror into different cabinets for fault tolerance.
> - You can't mirror between different CI adapters for fault tolerance.

> For most people, the disadvantages aren't that big a deal, especially
> if they aren't running multiple CI controllers or storage cabs.

Additionally, monitoring host based shadow sets is "somewhat easier". You can
do it
from DCL straight. With HSx based mirror sets, you have write a bit more
complicated
tools depending even somewhat whether you have HSD/HSJ or HSZ.

_veli

 
 
 

Host-based vs. controller-based shadowing

Post by Mark D. Chanle » Wed, 18 Mar 1998 04:00:00


I agree with Dan on this.  If you are not currently using several different CI
adapters and are shadowing across them for redundancy, then go with the
controller based mirroring.

Be advised that the firmware code for the WriteBack Cache is still an ongoing
issue with all the storageworks models using WriteBack Cache.  It has caused
several problems with systems that I have supported (especially if you have
HSx40s!

Mark D. Chanley
MCI Technology Planning
Colorado Springs, Colorado


> My take on controller-based shadowing:

> Advantages:

> - You don't use CPU cycles to mirror.
> - You don't use twice the I/O bandwidth to mirror.

> Disadvantage:

> - You can't mirror into different cabinets for fault tolerance.
> - You can't mirror between different CI adapters for fault tolerance.

> For most people, the disadvantages aren't that big a deal, especially
> if they aren't running multiple CI controllers or storage cabs.


> >I recently bought some HSJ50's, and I was wondering if I should convert to
> >controller-based mirrorsets or stick with host-based shadowing (phase II).
> >Are there any advantages/disadvantages to controller-based mirroring?

> --
> Dan O'Reilly
> MCI Telcommunications
> Systems Engineering/BT NIP
> MS 1183/117
> 2424 Garden of the Gods Rd
> Colorado Springs, CO  80919
> 719-535-1418

 
 
 

Host-based vs. controller-based shadowing

Post by Jay Olso » Wed, 18 Mar 1998 04:00:00



> Be advised that the firmware code for the WriteBack Cache is still an
> ongoing issue with all the storageworks models using WriteBack Cache.
> It has caused several problems with systems that I have supported
> (especially if you have HSx40s!

Do you have any pointers to further information about these bugs? A
major client of mine had to disable writeback cache to get their
application to work properly. This was a major performance hit, and they
would like to re-enable writeback cache as soon as possible.
--

        Triton Software Group Ltd.
 
 
 

Host-based vs. controller-based shadowing

Post by fairfi.. » Wed, 18 Mar 1998 04:00:00




[...]

Quote:> Be advised that the firmware code for the WriteBack Cache is still an ongoing
> issue with all the storageworks models using WriteBack Cache.  It has caused
> several problems with systems that I have supported (especially if you have
> HSx40s!

        Now, the HSx30 & HSx40's  use  HSOF  V3.x, while the HSx50's use
    HSOF  V5.x.   Do  you have first-hand knowlege that  HSOF  V5.x  has
    writeback cache problems?  I have heard any such reports (but  I  be
    _very_ interested if there are any).

        -Ken
--

 SLAC, P.O.Box 4349, MS 46  |  DECnet:   45537::FAIRFIELD (45537=SLACVX)
 Stanford, CA   94309       |  Voice:    650-926-2924    FAX: 650-926-3515
 -------------------------------------------------------------------------
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...

 
 
 

Host-based vs. controller-based shadowing

Post by Rob You » Wed, 18 Mar 1998 04:00:00




>> Be advised that the firmware code for the WriteBack Cache is still an
>> ongoing issue with all the storageworks models using WriteBack Cache.
>> It has caused several problems with systems that I have supported
>> (especially if you have HSx40s!

> Do you have any pointers to further information about these bugs? A
> major client of mine had to disable writeback cache to get their
> application to work properly. This was a major performance hit, and they
> would like to re-enable writeback cache as soon as possible.

        HSJ40s have had severe writeback cache problems.  We had them at
        one point with 3.1 HSOF.  Without mucking around for the cover letter
        mailed out several months back ... it had something to do with
        batteries being incorrectly identified as failed.  Top that off with
        batteries actually failing (a bad batch or some such that has long
        since been taken care of) made writeback cache in HSJ40s a risk
        proposition.  The solution for us was to roll back to 2.7J-1.
        I did some research regarding this and was told 3.1J-6 or was it J-5
        was a "good" patch level.  The initial go round of 3.1 HSOF was
        *very* painful for the person that PRECEDED me ;-).

        I had to do arm twisting to turn on writeback caching for HSJ40s.
        But with RAID-5 it doesn't make sense NOT to have it.  We have been
        fine for months.  Contact Colorado as a follow-up and make sure
        at a controller level you have a *good* HSOF for writeback with
        HSJ40s that Digital Engineering approves of.

                                Rob

 
 
 

1. Host-based vs. controller-based shadowing



[...much snippage...]

        Nonsense.  Tell that to my little  AXP 3000/400s running V7.1 i=
n
    a  mixed-architecture, mixed-interconnect, mixed-version  VMScluste=
r
    (VAX/V6.2, Alpha/V6.2-1H3, Alpha/V7.1)!  Better RTFM again...

        -Ken
--

 SLAC, P.O.Box 4349, MS 46  |  DECnet:   45537::FAIRFIELD (45537=3DSLAC=
VX)
 Stanford, CA   94309       |  Voice:    650-926-2924    FAX: 650-926-3=
515
 ----------------------------------------------------------------------=
---
 These opinions are mine, not SLAC's, Stanford's, nor the DOE's...

Oops, sorry, Ken.  As usual, you're right.
I was RTFMing for our production VAXen, not for Alphas...

WWW.
=

2. FS: A500/A600 Odds & Ends...

3. Host Vs Controller based RAID 1

4. help : samba and multiple domains

5. Host-based volume shadowing out to get me again

6. please help (WIFI - VS2005&SQLserver2005)...

7. Host-based volume shadowing a system disk?

8. Check Register

9. Alternatives to Host-Based Volume Shadowing

10. Host-Based Shadowing - Potential Loss of Data?

11. host-based shadow question

12. Backup to a Host Based Shadow Set

13. New feature request for host based shadow disks -- Scrubbing