Volume level snapmirror moves *all* blocks, including the snapshots. If
you create a snapshot (snap create volname mysnapshot) you have a
guaranteed intact snapshot of data on that volume for that time.
Volume snapmirror will then replicate that snapshot view on the next
transfer and stay there until you delete the source snapshot, after
which it will replicate the deletion of the snapshot view.
Once you see the snapshot you created on the destination you can be sure
it is in sync with what you are going to backup.
~JK
-----Original Message-----
From: Algo Seeker [mailto:algorithm AT gmail DOT com]
Sent: Monday, April 04, 2005 12:42 PM
To: Kennedy, Jeffrey
Cc: Tim Berger; veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] snapmirrored volumes question
I am not a NetAPP guy, How do I know that a snapshot created at Source
volume has been totoally in sync at the destination, whicl I can the
that source and destination are mirroring data all the time?
Thanks
On Apr 4, 2005 3:13 PM, Kennedy, Jeffrey <jkennedy AT qualcomm DOT com> wrote:
> 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
> >
>
|
