Setting up TSM for Data Domain and Data Domain for TSM

droach

ADSM.ORG Senior Member
Joined
Jan 7, 2008
Messages
239
Reaction score
13
Points
0
Location
Cut and Shoot, Texas
PREDATAR Control23

Been playing with a pair of Data Domain (DD) 7200's and am ready to implement with TSM. Having a hard time finding any "best practice" type documentation that contains much detail. Would like to hear from anyone that has TSM and DD running in their world.

We are running TSM on Windows and will NOT be using the DD as a VTL. Will be deploying CIFS shares for TSM device classes as per EMC's recommendation.

Some questions:

  • Did you join your DD controllers to your Active Directory domain?
  • For a Primary Data Domain (DD) storage pool...collocate Y/N?, and if so, which method, NODE?
  • Reclaim threshold? EMC suggested 90%
  • MAXSIze for the device class? 50-100G was suggested
  • Separation of data - How did you partition your DD for multiple TSM servers and DDBoost? Was suggested to use a separate MTREE and CIFS share for each TSM server, but define a single Storage Unit/MTREE for DDBoost and RMAN, and a single Storage Unit/MTREE for DDBoost for SQL.

Wanted to join the DD controllers to the domain, but all our TSM servers startup under a local account. For testing I just created the same account and pw on the DD and it would allow the TSM servers to connect. Once the DD was joined to the AD domain it would no longer honor these local accounts. Could reconfigure all TSM servers to start using a domain account, but don't like the idea of TSM startup relying on the domain to be available for it to start.

As for the separation of data, don't like the idea of every database server dumping their backups into a single location for RMAN and one for SQL. Seems like you would at least want separate folders in these Storage Units/MTREE for each server to dump into.

Any other "gotcha's" or recommendations are greatly appreciated.
 
PREDATAR Control23

I have two pairs of DD on a replication setup.

I did not have these on AD since we believe in isolation of backup from the rest of the world.

We use NFS instead of CIFS since we run TSM on Linux. Personally, I don't like either one as NFS and CIFS are unreliable. I prefer direct Fiber connect but DD does not support this. VTL is NOT used. Instead we use devclass=file which is chunked at 100 GB a piece.

We use directory method for backing up data. Wintel to Wintel directory, Unix to Unix directory, etc. These are grouped further by TSM instance.

Collocation is by group.

We don't use DD Boost

Reclaim threshold is 90%
 
Last edited:
PREDATAR Control23

Moon, do you mind sharing your RMAN format specs? I am trying to get my DBA's to place their backups into seperate folders on the Data Domain and they tell me that they cannot specify a folder name in the RMAN backup command.

Doing a little research, to me it looks like the command below would put the backup files in the folder called 'serverA', but I do not pretend to be a DBA.

backup incremental level 0 filesperset 0 database format '/serverA/db_%d_%U' ;

Also, if this will work does the folder 'serverA' need to exist prior to the backup, or will RMAN create it when it runs the backup?

Thanks,
D
 
PREDATAR Control23

Moon, do you mind sharing your RMAN format specs? I am trying to get my DBA's to place their backups into seperate folders on the Data Domain and they tell me that they cannot specify a folder name in the RMAN backup command.

Doing a little research, to me it looks like the command below would put the backup files in the folder called 'serverA', but I do not pretend to be a DBA.

backup incremental level 0 filesperset 0 database format '/serverA/db_%d_%U' ;

Also, if this will work does the folder 'serverA' need to exist prior to the backup, or will RMAN create it when it runs the backup?

Thanks,
D

I don't backup Oracle data directly to the DD appliances but through TDP installed on the Oracle server. This means that RMAN uses TSM through TDP, and TSM does the rest.

As for your question, serverA must exists prior to any backup to happen. In this case, it could be the Oracle server itself with a NFS mapping to the DD appliance.
 
PREDATAR Control23

A small difference perhaps, but I've read on one of the many books that the best value for reclamation threshold is 50, so that the benefit would improve.
 
PREDATAR Control23

A small difference perhaps, but I've read on one of the many books that the best value for reclamation threshold is 50, so that the benefit would improve.

Thanks for your post Umur.

50% is what I use for tape storage pools, but for disk-based storage pools on the Data Domain EMC's recommendation is different. I am running with EMC's recommendation (and Moon-Buddy's) of 90% and it seems to be working ok.
 
PREDATAR Control23

Thanks for your post Umur.

50% is what I use for tape storage pools, but for disk-based storage pools on the Data Domain EMC's recommendation is different. I am running with EMC's recommendation (and Moon-Buddy's) of 90% and it seems to be working ok.

90% is the recommended reclamation threshold for devclass=file.

Even IBM endorses this.
 
PREDATAR Control23

Hey Moon-buddy, just curious...what does your RMAN backup commands look like?

After allocating four channels I have these commands:

sql 'alter system switch logfile' ;
backup filesperset 1 incremental level 0 format '%d_dbf_t%t_s%s_%p'
(database include current controlfile) ;

backup filesperset 1
format '%d_arc_t%t_s%s_%p'
(archivelog from time 'SYSDATE-1' not backed up 1 times delete input);

backup
format '%d_ctl_t%t_s%s_%p'
(current controlfile);

Basically, we just added the 'filesperset 1' parameter to our existing RMAN commands...except for the control file backup.
 
PREDATAR Control23

Sorry droach, I don't have access to the Oracle servers to see what the script looks like.
 
Last edited:
PREDATAR Control23

I have similar setup as moon-buddy, TSM server on linux, with DD ( NFS mode), Devclass=File, Size 100GB volumes.
Except, I still make copies onto LTO tapes & Send them offsite. Now, I got funding to put in a 2nd DD at DR site and thus I will eliminate tapes from the environment.

I am thinking of doing "Collection" replication with DD as it is light weight, and does a synchronous mirror. But my concern is what happens if I have to perform TSM DB restore on the Cold TSM server connected to the DR Data Domain and make that Prod. After I copy the volhist and issue dsmserv restore db, will it then see the DBB volume paths the same way it is laid out on the primary DD? After I start doing DBB backups to Data Domain, Path will be /xxx/yyy/DBvolzzz.dbb will I be able to see this exact path on the DR Data Domain? Thx!
 
PREDATAR Control23

I have similar setup as moon-buddy, TSM server on linux, with DD ( NFS mode), Devclass=File, Size 100GB volumes.
Except, I still make copies onto LTO tapes & Send them offsite. Now, I got funding to put in a 2nd DD at DR site and thus I will eliminate tapes from the environment.

I am thinking of doing "Collection" replication with DD as it is light weight, and does a synchronous mirror. But my concern is what happens if I have to perform TSM DB restore on the Cold TSM server connected to the DR Data Domain and make that Prod. After I copy the volhist and issue dsmserv restore db, will it then see the DBB volume paths the same way it is laid out on the primary DD? After I start doing DBB backups to Data Domain, Path will be /xxx/yyy/DBvolzzz.dbb will I be able to see this exact path on the DR Data Domain? Thx!

I solved this dilemma by scripting and snapshots. The script does a daily snapshot of the primary site's Data Domain TSM DB backup into the replication DD device.

The script further mounts the snapshot, looks for the DRM RP File, expands it, and extracts the needed files and restores the TSM instance (I restore 3 TSM Instances daily) into the DR site. This is all automated. Thus, I have daily DR TSM instances ready to go in the event of a disaster in the DR site.

This has been in place for more than 3 years now.

As you can see, the path (as /xxx/yyy/DBvolzzz.dbb) is immaterial since this is decoded - and needed - at the DR site. It is just a question of understanding your data and how to work on it.
 
PREDATAR Control23

Hi Marclant- I cannot do HADR as you cannot perform "client-side" duplication when sending data to Data Domain.
Are you suggesting I just turn on HADR only for TSM DB backup and let DD - DD replicate. Also, my TSM DB is about 300+GB and will take a while to sync in w/ DR TSM using suggested log shipping on limited pipe.

I think the best scenario is to enable TSM client side dedup and setup TSM node replication with automatic failover. But given that I am using a target dedup appliance it cannot be done.

That leaves me to do what moon-buddy has setup on this env. It would be a blessing if he can share the script he is using to do this as I have a very similar environment.
 
PREDATAR Control23

Are you suggesting I just turn on HADR only for TSM DB backup and let DD - DD replicate. Also, my TSM DB is about 300+GB and will take a while to sync in w/ DR TSM using suggested log shipping on limited pipe.
HADR is for the DB only. You have to prime the DB on the standby server first by restoring it, then after that it's just replicating the logs and applying them. DD takes care of replicating your data.
 
PREDATAR Control23

That leaves me to do what moon-buddy has setup on this env. It would be a blessing if he can share the script he is using to do this as I have a very similar environment.

Sorry but I cannot share the script as this is part of company rules.

However, I can guide you on how to put one together.

Primary site:

1. Setup the DD device to replicate to the DD on the DR site
2. Setup the TSM on the primary side to backup the DB to the DD device (through NFS) plus the RP, volhist and devconfig files.

DR site:

1. Setup the DD device to receive replication from the primary site
2. Setup a TSM instance that has the same configuration as the original TSM instance
3. Create a script that:

- will create snapshots of the primary DD into the DR DD
- mount (NFS) the snapshots into the DR TSM server - the snapshots are normally created by the DD device with dates in it
- the date-defined snapshots will be a placeholder to easily determine which DBB volumes are needed for recovery

4. append to the script TSM restore functions:

- extract the necessary data from the RP File, etc
- restore the TSM instance via dsmserv restore ... (since the DB, logs, configuration, etc. can be seen by the DR instance via the snapshot mounts)

After this works, you can put this into CRON and you have an automated recovery mechanism.
 
PREDATAR Control23

ok I was able to setup Data Domain at my DR site, Put up a cold Stand-by TSM server. I am performing Mtree level replication to the DR Data Domain. In case I lose entire primary site, I can restore the cold server from DBB vol
and then make the Primary stg pool pointing to the DR DataDomain MTREE. That should work with continuation of backups in a DR.
Thinking out loud, Pls correct me if I wrong, but what happens when just a few volumes or a volume gets damaged on Primary Stg pool ( NFS path /DD Primary/Vol1.BFS) needing restore.
I will not be able to use TSM restore vol command as I do not have a copy stg pool now, so do I have manually copy those particular volume from the DR Data Domain mounted to host as I cannot choose a file ( volume) from Data Domain to be replicated back, have to replicate the entire Mtree.
 
PREDATAR Control23

Since the DD replicates continuously your DR volume(s) will probably also be corrupted. If not, you could try as you mentioned and copy the "clean" volume/file from your DR mtree to a temp landing zone, then copy from there to your primary mtree. Then run an audit volume on it from your primary.
 
Top