> Full/Incr information is kept per client on the master server, don't
> think you'll be able to spoof it.
> 

I think mark has nailed this - it comes back to keeping it simple as well - so 
we'll move the LUN back to the original host asap.  Its nice to have a method 
of hacking all the netbackup files and directories, but in the end how reliable 
is this going to be? and how easy is it to make a small error and corrupt the 
entire netbackup database??


>  Why not just exclude the LUN on the second client, you already have a
> backup of it from the first? 

We need an incremental of the data on the LUN - its only visible on one client. 
 Hence this hair pulling exercise of trying to get the incremental to work on 
the second client.

I like your thinking Ed and Rockey:

> Typically the way this is done is to set up a virtual DNS name that follows
> the LUN and to do the backups by that name. When the LUN moves, so should
> the DNS entry. We're doing this with Windows, Linux, and Solaris clusters
> today. VMS clients, of course, doesn't need this sort of crap since the
> clusters are active/active.
> You'll still need to do one more full under the new virtual name, but after
> that your full/inc policy will work properly. 

The incremental on the second client could be rather large if the LUN has not 
been hosted for a few months, but still smaller than a full.  Looks like the 
only real solution here.


> You might also want to check to see that something isn't causing the archive 
> bits to flip after the LUN is mounted on the other client. 

I did some different ls -l, ls -lu, and ls -la. It appears the access time is 
from the last FULL so all good.
-bash-3.1$ ll
total 32
-rwxr--r--+ 1 oracle oinstall 1350 Oct 11 15:01 archlogtrans
-rwxr--r--+ 1 oracle oinstall 1197 Oct  7 12:53 archlogtrans.old
-rwxrwxr-x+ 1 oracle oinstall 1267 Sep 20 16:12 cluster_checks.sh
-rwx------  1 oracle oinstall 1436 Oct  5 14:27 filepurge
-rw-r--r--  1 oracle oinstall  258 Oct  5 15:08 filepurge.tab
-bash-3.1$ ls -lu 
total 32
-rwxr--r--+ 1 oracle oinstall 1350 Oct 11 15:01 archlogtrans
-rwxr--r--+ 1 oracle oinstall 1197 Oct  7 12:53 archlogtrans.old
-rwxrwxr-x+ 1 oracle oinstall 1267 Sep 20 16:12 cluster_checks.sh
-rwx------  1 oracle oinstall 1436 Oct  5 14:27 filepurge
-rw-r--r--  1 oracle oinstall  258 Oct  5 15:08 filepurge.tab
-bash-3.1$ ls -lc
total 32
-rwxr--r--+ 1 oracle oinstall 1350 Oct 13 16:43 archlogtrans
-rwxr--r--+ 1 oracle oinstall 1197 Oct 13 16:43 archlogtrans.old
-rwxrwxr-x+ 1 oracle oinstall 1267 Oct 13 16:43 cluster_checks.sh
-rwx------  1 oracle oinstall 1436 Oct 13 16:43 filepurge
-rw-r--r--  1 oracle oinstall  258 Oct 13 16:43 filepurge.tab



So in Summary....

Copying the STREAMS file did not work.  A scheduled Incremental continues to 
back up all files.  

Renaming the images db dir for the client and spoofing the client name in the 
bp.conf on the new client and in hosts on the master didn't work either.  
Netbackup must reverse lookup or something to verify the client is actually who 
it says it is.

Thanks all for your input.

Duncan

+----------------------------------------------------------------------
|This was sent by d AT ddmr.co DOT nz via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------


_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu