TSM DB backup to a NFS mount on a DD990

NJ88210

ADSM.ORG Member
Joined
May 14, 2003
Messages
25
Reaction score
0
Points
0
Website
http
Good Morning
I need help setting up our TSM DB to back up to a NFS mount on a Data Domain DD990. Or SAN zoned disk which wever is better. I also need to be able to access this NFS mount from a new TSM instance just incase we are in a DR situation.
 
This is relatively easy to do:

1. Make sure the DD990 has the necessary NFS setup so the TSM server can mount a share from it
2. Mount a share on the TSM server (OS side) from the DD990
3. On the TSM server, define a devclass=file for the DB Backup, something like:

define devclass dbbackup devtype=file mountl=10 maxcap=200G dir=/nfs_path/dbbackup (or something to your liking)

4. define dbrecovery: set dbrecovery <devclass_name_from_3_above> numstreams=2

I use 2 streams to backup DB for a faster backup. You can use more if you wish.

To use this same NFS share on another TSM instance, use a snapshot copy of the DB. I am hoping that you have a replicating partner for the DD990. I make the snapshot on the replicating partner. However, you can also use the same DD990 to create a snapshot.
 
Moon-Buddy
Thank you so much. We retain 14 days of DB backups, currently one of our production TSM db is 629gb (which is 7 dd990 VTL tapes). How do I make sure I have enough NFS storage available for the DB to write to. I have 132tb overall storage available, will the NFS DB backup task take whats needed?

Also do I have to zone the DR TSM instance to the DD990 in order to read the production NFS DB backup files? I'm running TSM on a AIX operating system, and I'm looking to migrate from AIX to a Linux platform and a restore DB seems to be the only way.
 
Moon-Buddy
Thank you so much. We retain 14 days of DB backups, currently one of our production TSM db is 629gb (which is 7 dd990 VTL tapes). How do I make sure I have enough NFS storage available for the DB to write to. I have 132tb overall storage available, will the NFS DB backup task take whats needed?

Also do I have to zone the DR TSM instance to the DD990 in order to read the production NFS DB backup files? I'm running TSM on a AIX operating system, and I'm looking to migrate from AIX to a Linux platform and a restore DB seems to be the only way.

Zone? You don't zone NFS mounts. Zoning is for SAN disks. NFS uses IP. On the DD990, the NFS filesystem is exported as NFS which is what your TSM server will mount as NFS.

Restoring to Linux from AIX? I have not tried this on a 6.3.X or 7.X environment as all of my TSM - PROD and DR - are on Linux.
 
How is the NFS mounts from the DD990 presented to the TSM instance for use? There has to be some kind of connection made.

Yes we are migrating off the AIX platform to a Linux OS on a IBM P8.

1) Define a file devclass to the AIX instance (perhaps to NFS shared disk to save any copying steps).
2) Take a DB backup to that file devclass.
3) Copy the contents of the TSM instance home directory to some location. This should include dsmserv.opt, volume history, device configuration, TSMDB* files and the .id file.
4) Install TSM on the pLinux machine (same version).
5) Define an empty TSM instance as the same name as the AIX instance. DBDir, Actlog, Archlog locations at the same directory locations.
6) Define a file devclass for this new instance (don't make it the same name or location as the devclass in step 1).
7) Backup the new, pristine TSM DB. This not only gives you validation that you can connect to the local TSM DB, but also that you can get back to this state as needed.
8) Backup the contents of the TSM instance directory to some location. If you need to revert to this step, you can use these files and the DB backup above to do a DR of the TSM server.
9) Stop the new TSM instance, log in as the db2 instance owner start db2 then drop database tsmdb1.
10) Make certain the File devclass and its volumes are available to the Linux machine at the same location. If this was NFS, you can just mount the exports, if it was on local file systems, you may need to copy the files.
11) List the security on the file volumes to make certain the security shows the TSM instance account as the owner. If not, chown them so they are. Make them match what was shown on the AIX instance.
12) Copy the files from step 3 into the TSM instance directory.
13) Perform a DR recovery from the backup taken in step 2.
14) Start the TSM instance and log in and validate the environment. The tape lilbrary and drive paths will be wrong, since they will be the format for AIX.
15) Assuming you have SAN connectivity to the storage devices, configure the tape devices as normal for pLinux.
16) At this point, you need to stop and evaluate what the next steps are. I would recommend evaluating the TSM instance for any errors that are unexpected.
 
On the DD990, check:

1. if the NFS is enabled: nfs status.
2. If not, enable it: nfs enable.
3. If it was enabled or not enabled, check if you had defined the clients that will access the DD990: nfs show clients
4. If there are none defined, define the desired clients (like your TSM server) to be served by the DD990: nfs add /backup <client IP address/mask>.

NFS is now active and can be mounted on the TSM server. Make sure your DD990 has NICs configured for NFS access as the IP on this NIC or NICS will be used by clients to mount NFS.
 
Hello All,

I have a same kind of setup in our environment.. here the DD to which we were taking TSM DB backup is getting decommed.. We also have replication enabled to different site on DD..

Now we need to restore the TSM DB from the replicated DD to the new TSM instance(AIX). Can some one please provide the steps to restore the TSM DB from replicated db NFS file..
 
This process is relatively simple:

1. Bring up the TSM on the replica side as identical as possible with the source side
2. Copy over the necessary files: devconfig, volhist, dsmserv.opt if you haven't
3. Mount the NFS to the replica TSM server
4. Restore the DB from the mounted NFS

Note that the replica side should be a mirror of the source for this to work. TSM thinks that the replica DB is the same as the source since it has the same path and name as written on the devconfig and volhist files.
 
Back
Top