Backup Central

We have a linux shell script which we use to create our offsite copypool tapes. Basically the commands are:



backup stg SQLDB_LTO4 SQLDB_COPYPOOL wait=yes



backup stg BKPLTO4POOL COPYPOOL_LTO3 wait=yes



Our primary SQL storage pool is SQLDB_DISKPOOL and it's secondary pool for data migration is SQLDB_LTO4.

Our primary backup storage pool is BKPPOOL and it's secondary pool for data migration is BKPLTO4POOL.



However I am finding that backups of SQL databases are also somehow ending up in the BKPLTO4POOL storage pool because they are then in turn being backed up into the COPYPOOL_LTO3 storage pool.

The reason I know this is that these SQL databases are very large files with very distinctive (but consistent) sizes so as soon run "q pr" and see the process copying a 185 Gb file from the BKPLTO4POOL storage pool to the COPYPOOL_LTO3 storage pool I know which SQL database file that is.



On the SQL servers I have included the SQL database folder in the Exclude-Include configuration of the normal TSM backup setup. (these databases are backed up using TDP for SQL) As well as that, SQL is running all the time so the normal TSM backup client would never be able to get a lock on these database files. I already have a backup of these SQL databases in the SQLDB_LTO4 storage pool and therefore a copy is in the SQLDB_COPYPOOL storage pool so I don't need another copy in BKPLTO4POOL and COPYPOOL_LTO3



Any idea how I can work out why a backup copy of these SQL database backups are ending up in BKPLTO4POOL and stop this from happening?





Thanks & Regards

Paul



Paul Dudley

Senior IT Systems Administrator

ANL Container Line Pty Limited

Email: <mailto:pdudley < at > anl.com.au> pdudley < at > anl.com.au















ANL - Regional Carrier of the Year 2011 - Containerisation International

ANL DISCLAIMER

This e-mail and any file attached is confidential, and intended solely to the named add
ressees. Any unauthorised dissemination or use is strictly prohibited. If you received
this e-mail in error, please immediately notify the sender by return e-mail from your s
ystem. Please do not copy, use or make reference to it for any purpose, or disclose its
contents to any person.

----- "Paul_Dudley" <pdudley < at > ANL.COM.AU> wrote:
On the SQL servers I have included the SQL database folder in the
Exclude-Include configuration of the normal TSM backup setup. (these
databases are backed up using TDP for SQL) As well as that, SQL is
running all the time so the normal TSM backup client would never be
able to get a lock on these database files. I already have a backup of
these SQL databases in the SQLDB_LTO4 storage pool and therefore a
copy is in the SQLDB_COPYPOOL storage pool so I don't need another
copy in BKPLTO4POOL and COPYPOOL_LTO3

The SQL database files themselves should be excluded rather than included since you won't get a consistent backup of them with the DB up and running, but I don't know if you do cold backups as well which would want them included. I like to include the directories and just exclude the actual database files (by extension and location) so a bare metal restore is easier. You might consider which management class you include them with if you do backup the db files cold occasionally.


Any idea how I can work out why a backup copy of these SQL database
backups are ending up in BKPLTO4POOL and stop this from happening?



It's likely you're getting the files captured by the client even with the db open. Try to exclude them in the inclexcl, or associate them with the right management class.

'Query occupancy' for the TDP node should list everything in the right storage pool.

Take a look in the BA client gui and hunt down the database files - that will tell you if they are being stored. If you can see them as individual files, and you've not made a cold backup of the database, then that's the issue. You can delete them from the ba client if you wish and are sure they're not wanted.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Xav Paice

----- "Paul_Dudley" <pdudley < at > ANL.COM.AU> wrote:
On the SQL servers I have included the SQL database folder in the
Exclude-Include configuration of the normal TSM backup setup. (these
databases are backed up using TDP for SQL) As well as that, SQL is
running all the time so the normal TSM backup client would never be
able to get a lock on these database files. I already have a backup of
these SQL databases in the SQLDB_LTO4 storage pool and therefore a
copy is in the SQLDB_COPYPOOL storage pool so I don't need another
copy in BKPLTO4POOL and COPYPOOL_LTO3

Any idea how I can work out why a backup copy of these SQL database
backups are ending up in BKPLTO4POOL and stop this from happening?


It's likely you're getting the files captured by the client even with the db open. Try
to exclude them in the inclexcl, or associate them with the right management
class.

'Query occupancy' for the TDP node should list everything in the right storage
pool.

Take a look in the BA client gui and hunt down the database files - that will tell you
if they are being stored. If you can see them as individual files, and you've not
made a cold backup of the database, then that's the issue. You can delete them
from the ba client if you wish and are sure they're not wanted.

I checked the BA GUI and the database files are not being backed up. However when I ran "q occupancy" I can see that these node names for these SQL database backups are in the wrong storage pool - BKPLTO4POOL. When I query these node names the platform is TDP MSSQL Win32, and the Optionset is SQL_SERVERS. Note that it is not all of the SQL servers that are this way, some show the correct Storage Pool via the "q occupancy" command.

How can I change the SQL Servers that are incorrect to be backed up into the correct storage pool?

Thanks
Paul






ANL - Regional Carrier of the Year 2011 - Containerisation International

ANL DISCLAIMER

This e-mail and any file attached is confidential, and intended solely to the named add
ressees. Any unauthorised dissemination or use is strictly prohibited. If you received
this e-mail in error, please immediately notify the sender by return e-mail from your s
ystem. Please do not copy, use or make reference to it for any purpose, or disclose its
contents to any person.