Craig> We discovered a perplexing problem recently (and have since
Craig> implemented a work-around solution), but I don't really like
Craig> our work-around.  I'd like to hear what others have to suggest.

Craig> The problem centered around not understanding how Networker
Craig> determines what files are to be backed up during the current
Craig> backup session.

Craig> To demonstrate the problem we were having, here is a simple example.

Craig> Lets say that on Sunday morning at 6:00am, a full backup is
Craig> performed of filesystem ABC.  On Monday morning at 6:00am, an
Craig> incremental backup is performed of the same filesystem.  During
Craig> the middle of the day on Monday, a file, lets call it XYZ, is
Craig> placed on the ABC filesystem which has a modification timestamp
Craig> of Sunday 8:30pm.

Ah, but it's not the same filesystem, it's a snapshot of another
filesystem!  That's where you're making your fundamental mistake in
your assumptions.

Craig> We have this kind of situation happen every day, because we
Craig> have a EMC symmetrix and have BCV volumes which we sync up once
Craig> a day of our production Oracle database.  A couple of hours
Craig> after the BCV sync, we backup the BCV volumes via Networker.

I would think that the best thing to do here is to backup the BCV
right after you do break it off the primary volume.

Craig> After a BCV sync has occurred (we do an establish, let the
Craig> volumes sync up, and then do a split), new files get written to
Craig> the production filesystems (and existing ones get modified).
Craig> If the modification times of these files on the production
Craig> filesystems occur after the BCV sync but predate the time that
Craig> Networker backs up the BCV (by the time Networker backs up the
Craig> BCVs the snapshot contained on the BCVs are a couple of hours
Craig> old), when the next BCV sync occurs the next morning, these
Craig> modified files on the production filesystems will be on the BCV
Craig> volumes, but their modification times will predate the
Craig> Networker backup performed the previous morning.  So the next
Craig> Networker incremental backup will not backup these files.

So the real answer here is to do the Networker backup *immediately*
after you do the BCV sync, to make your window of opportunity smaller,
so you don't miss any files.

You're hack of setting back the time will probably also work, but
making sure that you get good backups is key.

Maybe the following would work better for you:

  - sync up BCV to master volume.
  - lock down Oracle on master server.
  - break off the BCV.
  - mount to backup server.
  - start Legato backup using 'savegrp' from the script.
  - wait 60 seconds
  - unlock Oracle on master server.

This procedure will make sure that Legato starts it's backup before
your oracle DB starts writing to files again.  You don't even need to
stop read access to Oracle, just writes for the couple of minutes it
takes to get the BCVs registered, mounted and Legato's backup
started.

At least that's what I'd do, I'm not sure how much lock time you can
stand in your DB.

John
   John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
         stoffel AT lucent DOT com - http://www.lucent.com - 978-399-0479

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=