Mm, I'm getting the list traffic again, how nice. :)

>> On Wed, 9 Jul 2008 12:19:37 -0500, Roger Deschner <rogerd AT UIC DOT EDU> 
>> said:

> Do not use a local filesystem. The FILE volumes used for DB backup
> should reside on an NFS-mounted filesystem, which can also be
> mounted by some other system. A separate physical location would be
> nice. This should be on the same NFS server which you also use to
> back up the Volume History and Device Config files. On all systems
> that can mount this NFS filesystem, it should be mounted at the same
> mount point as on the TSM server system. That is so the DB Backup
> volume names in the Volume History File are still valid.

> Are there any other pitfalls I am not forseeing here?


I've been carting around FILE volumes for some DB backups for a long
time.  I've got some recommendations and pitfalls for you.

First: I recommend firmly against using NFS in the critical path for
your ongoing operations.  Having the backups "elsewhere" is good, but
having them at all is critical on a minute-by-minute basis for the
running of your server.  NFS outage degrading your offsite
preparation: bad.  NFS outage killing your server because it can't
find the device to do an incremental to clear the log: production
outage.  Bad bad bad.


Second: these are just files; they don't have any particularly
delicate nature, they're not sparse, they're not scary.  I've tarred,
bzipped, folded spindled and mutilated them, and when you unfold and
unbzip, and untar them, they work just fine. This means you should
consider all the tools you might normally use for shoving or syncing
files around.

I'm currently working towards a centralized "DR" filesystem, which
gets regular updates from all the server instances, and then is in
turn synced -to- all the systems.  That means, to a first
approximation, any of my TSM servers has enough of a roadmap to begin
recovery of all the instances.

That's just my example: but the advice is to use post-facto copies to
get your belt-and-suspenders versions, rather than worrying about the
devclass being remote immediately.


Third: some database lock problems can generate a cascade of backups,
over and over again.  There are settings to help avoid this, but I
still get some situations where a box does
FULL-incr-incr-incr-incr-FULL, etc, etc, ad nauseam.  If you're
writing to filesystems, this can be a serious impact on other things
sharing the space.  Use distinct partitions as indicated for your
environment.  This might mean one per TSM server, one for all of them,
or whatever.


Finally, consider wether you might be better off doing the remote
virtual volumes thing.  I would be uncomfortable with my database
backup chain scattered amongst different device structures.  It seems
to me that your contemplated config inherits the union of the
disadvantages, with only the intersection of the advantages, of the
various methods.

If you backup to a remote server, you can do all the fun "First to
disk, then copy all over hell's half-acre, then shove to tape" stuff
we're accustomed to doing with client data.  Rational concerns about
exposure due to the egg/basket ratio ("All of my DB backups are on the
same tape!") can be addressed with a profusion of copy stgpools.  This
also gives you a simple and consistent way to manage offsites of DB
backups, instead of needing one family of procedures for offsites of
client data, and a completely separate one for offsites of -your-
data.



- Allen S. Rout