Ah, it's a movable lun, not a multiplely-mounted lun.
If you've got an alias IP that follows the application around (and,
therefore, I assume the LUN), then tying your policy to that ip's host
or DNS name is a good way. The full/incr tracking will be following the
aliased-ip name.
The incrementals work by simply recording the time of the last full or
incremental in a table tied to the client name. Then it's a comparison
of the file's mtime value vs the last full/incremental for your current
incremental's run. (Cumu compares against full backup time,
differential against previous incremental time). This is for unix, of
course. NT uses the archive bit by default (switchable) so that
actually would work correctly no matter where it's done.
If this won't work, aliased-ip method, for your arrangement, you might
just have to bit the bullet and build the filesystem in on both clients
and just take the hit when you move it around.
-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of threeta
Sent: Thursday, November 01, 2007 2:05 PM
To: VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Incremental backs up all files
> 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
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
