Best bet then, at least as far as I can tell, is to manually create a
snapshot on the source, wait for it to replicate to the destination,
then backup that snapshot at the destination and manually delete it when
the backup is done.
This could be scripted as well if your backup server is an admin host of
the source filer.
~JK
-----Original Message-----
From: Algo Seeker [mailto:algorithm AT gmail DOT com]
Sent: Monday, April 04, 2005 7:17 AM
To: Kennedy, Jeffrey
Cc: Tim Berger; veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] snapmirrored volumes question
The volume is volume level snapmirrored and is continuously syncing
data. I doubt my backups will finish in 24 hours. Anybody else have
any thoughts, how to backup a snapmirrored volume?
Thanks
On Apr 4, 2005 2:00 AM, Kennedy, Jeffrey <jkennedy AT qualcomm DOT com> wrote:
> If the volume is truly a volume-level snapmirror destination then I
> don't think you can do it normally.
>
> You can use a specific snapshot like nightly.0 as long as you are sure
> the backup will finish within 24 hours. Regardless of how frequently
> you snapmirror the volume nightly.0 will not change until midnight.
>
> ~JK
>
> -----Original Message-----
> From: veritas-bu-admin AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Algo
> Seeker
> Sent: Sunday, April 03, 2005 1:37 PM
> To: Kennedy, Jeffrey
> Cc: Tim Berger; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] snapmirrored volumes question
>
> 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
> >
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
|
