Well myquestion is stl there, should I add the snapmirrored volume in
backup selection list. I am talking about the destination volume and
the source of snapmirrored volume.

Thanks

On Apr 3, 2005 2:42 PM, Kennedy, Jeffrey <jkennedy AT qualcomm DOT com> wrote:
> 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
>