But now you're talking snapvault, which is very different from volume
level snapmirror.  And I thought that was what the OP's question was
about.

Snapvault only functions on the qtree level, not volume.  You can
snapvault an entire volume but you're just grabbing every qtree and
snapvaulting them en masse. That leaves the destination volume as
read-write still, snapshots not a problem then.

But if you snapmirror at the volume level, the volume itself is
read-only and therefore not snapshot'able (I'm pretty sure anyway,
haven't done volume level for a while).

~JK

-----Original Message-----
From: Tim Berger [mailto:tim.berger AT gmail DOT com] 
Sent: Sunday, April 03, 2005 12:47 AM
To: Kennedy, Jeffrey
Cc: Algo Seeker; veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] snapmirrored volumes question

On Apr 2, 2005 11:49 PM, Kennedy, Jeffrey <jkennedy AT qualcomm DOT com> wrote:
> The thing about a snapmirror *volume* is that the entire thing is
> read-only.  Unlike a volume of qtree snapmirror's where the volume is
> read-write but the qtrees are read-only.  This means no snapshots can
be
> taken of a snapmirror'd volume.  At least I'm pretty sure that's the
way
> it goes.  If not someone will speak up.

Sure can.  That's the beauty of the R200.  Snapshots "roll over", for
example, from a 960, as snapshots of the snapvaulted copy.  It would
be a a real problem if you couldn't snapshot a snapmirror or snapvault
- the process of snapvaulting would corrupt an ongoing backup.
 
[snip]

Cheers,

-Tim