Thanks for all the answers, I am going to try this first thing
tomorrow morning. Just to be clear the plan is:
FilerA:/vol/vol0 is mirrored to FilerB:/vol/vol0_sm
On Filer A
snapcreae vol0 snapshot_4_backup_vol0
Inthe backup policy the path is
Client: FilerB
Path: /vol/vol0_sm/.snapshot/snapshot_4_backup_vol0
Hope this works
Thanks
On Apr 4, 2005 8:53 PM, Kennedy, Jeffrey <jkennedy AT qualcomm DOT com> wrote:
> 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
> > >
> >
>
|
