TSM EXPORTS

Kicking the kids out of the House

Resources
TSM 6.1 Administrators Guide,
Chapter 22
Allen S. Routs paper, Fifty Ways
Summary

http://open-systems.ufl.edu/tsm/whitepapers/50ways.html

Examples from Legg Mason

What is an export?
Exporting (and Importing) is a copy and
paste operation.
It is a tool for performing heavy
housekeeping and maintenance on the
overall backup/archive environment.

Why Export?

Decommission and/or replacement of an old

TSM server
Transition from an old library or media
Load Balancing

Moving outsized nodes to a new server

Separating a large or distinct business unit from
other clients

TSM Server level upgrade

Organizational indecisiveness

Types of Export
Several kinds and shades of Export

Server Control Information

Client Node Data

Export Node - Some or all of the backed up, archived,

space managed data

Combined Information

Export Admin - Administrator definitions

Export Node - Client node definitions
Export Policy - Policy and scheduling definitions

Export Server Policy, Admin, Node, & Node Data

Incremental Export A little off the top

The Non-Export export For things that can not be
exported.

Export Node Characteristics

Node Definition Information

EXP Node some_node FSID=* FILEData=None

User ID, password and contact info

Name of the Nodes policy domain
File compression status
Whether the user has delete authority for backed up or
archived files
Whether the client node ID is locked

File Data
EXP Node some_node FSID=* FILEData=ALl

Filespace definition and authorization rules

Any combination of Active or Inactive versions of backed up
files, archives, and space managed files

The entire syntax

>>-EXPort Node- -node_nameFILESpace=file_space_name-'
FSID=file_space_ID-'
UNIFILESpace=file_space_name-'
DOmains=domain_name-'
FILEData=+-ALl+-'
+-None-+
+-ARchive+
+-Backup-+
+-BACKUPActive-+
+-ALLActive+
'-SPacemanaged-'

FROMTime=00:00:00
FROMDate=date
TOTime=00:00:00
TODate=date
TOTime=time
EXPORTIDentifier=
export_identifier
PREVIEWImport=No/Yes
TOServer=servername
PREVIEWImport=No/Yes
MERGEfilespaces=No/Yes
-Replacedefs=No/Yes
PROXynodeassoc=No/Yes
ENCryptionstrength=AES/DES
ALLOWSHREDdable=No/Yes

Planning

Planning is important to identify and deal with

bottlenecks

Develop a reliable idea of how long the processes

will take and what resources are required.
Once you begin you will want to be able to monitor
progress effectively and be positioned to deal
setbacks...Exports dont always go smoothly
Once the project, or portions of it, are done, you will
want to be able to verify success with a minimum of
effort.
For a large export project of many nodes, record
keeping is important in tracking progress

Planning Considerations

Need a compatible TSM Server

Are matching Policy and Administrator
definitions in place on the destination server?
Time

Time allowed to export/import and resume backup

Time required to export

Can the network support the additional load

Adequate number of drives...plus some
Adequate supply of media
Impact on other processes

Planning Considerations contd

What is the scope of the effort?

How much data has to be moved
When is the best time to run the export

Need to close access to the Export node

The effect of versioning on the
destination server
Tolerance of project complexity

Methods to Export Node Data

Serial media only

These options involve discrete Export and
Import processes.
Still valid, but why bother.
If you ever need to do this, read the
commands

Network based options

These options combine the Export and

Import process into one event

Generic Export steps...

Preparation - Preview
1.
Serv1> EXport Node Some_Node FILEData=all Preview=Yes
TOServer=Serv2
Execution
1.
Lock the Client Node from changes: stop backups and do not make
administrative changes
2.
dsmadmc consolemode outfile=somenodeimport
3.
Serv1> EXport Node Some_Node FILEData=all TOServer=Serv2
Changeover and Cleanup
1.
Point the Client Node to the new server and resume backups
2.
Check your results
3.
Clean up at the old server.

Export with Mergefilespaces

Mergefilespaces=yes (not the default)

Export to an active node:

Continue backups to the Export source, begin backups to the Import

destination
When the initial Full incremental backup completes
Serv1>Export Node node_name FSID=3 filedata=all
toserver=Serv2 Mergefilespaces=yes

Export node one filespace at a time to an active node

Continue backups to the source, begin one filespace backup at the

destination
Wait until the initial Full filespace backup completes
Stop backup of that filespace at the source
Export the source to the destination.

Example - Quick Export

Move a TSM Client, NODEXYZ, from SRCSERVER to the new TSM Server
(DESTSERVER) reserved for XYZ Clients.
Step 0
Coordinate with NODEXYZ Client Administrator
Step 1
Save schedule association info in case back out of CR is required.
Step 2
Lock Client NODEXYZ on SRCSERVER and disassociate it from its backup
schedule.
Step 3
Register Node_Name NODEXYZ in Domain XYZ on DESTSERVER

Quick Export, continued

Step 4
Export all filedata for node NODEXYZ to DESTSERVER in the normal
XYZ domain (with 3 year retention)
To export from SRCSERVER to DESTSERVER
**AFTER NODEXYZ has been defined on DESTSERVER and assigned
to the desired domain**

On SRCSERVER TSM command line:

>EXPORT NODE NODEXYZ filespace=* filedata=all
toserver=DESTSERVER previewimport=no merge=yes
record the process number on both SRCSERVER and DESTSERVER to
view the results in the activity log

Quick Export, final steps

Step 5
(Must be performed by XYZ admininistrator on the Client Server
NODEXYZ)
Alter the dsm opt or dsm sys file to point to DESTSERVER so that it
looks to the correct TSM server for a backup schedule.
Step 6
XYZ admin can independently verify that data migrated using "dsmc q
backup /migrated/file".
Step 7
After the options file is changed, XYZ administrator can start backup of
NODEXYZ.
Step 8
In a week, if all is verified, delete NODEXYZ and all of its data from
SRCSERVER.

Problem Child Export Example

Load balancing
Cutting filespaces from large nodes
Exporting them piecemeal to the same server
as a new Node name
Restartable Exports

To pause the export issue Suspend Export, do not

Cancel Process!
Restart Export to resume
Query Export to see all running and suspended
restartable export operations

Export to FILE devclass on NFS

...for the special case of temporary
storage, especially for transport, there
are some enticing aspects to the idea.
To make use of remote-mounted space
for this purpose simply requires that your
organization have enough space
"somewhere". It's not even necessary
that you have the same namespace.

Export to FILE thru NFS, A. Rout

root@server_a# mount
REMOTE:/export/reallybig /mnt/a
root@server_a# dsmadmc
[...]
SERVER_A> def devc reallybigfile
FILE maxcap=100G dir=/mnt/a
SERVER_A> export node NODE_1
devc=reallybigfile filed=all

Export to FILE thru NFS, A. Rout

At this point, either on the command line or in the

activity log, you will find a list of volumes (files) that
were used for the export. Say it's one file,
0001111.exp
root@server_b# mount
REMOTE:/export/reallybig /mnt/b
root@server_b# mkdir /mnt/redherring
root@server_b# dsmadmc
[...]
SERVER_B> def devc irrelevant FILE
dir=/mnt/redherring
SERVER_B> import node NODE_1
devc=irrelevant vol=/mnt/b/0001111.exp

The Non-Export
The non-export is a data base restore.
Build a new server Server_B and use the
most recent database backup to restore
Server_A to it.
Delete everything on Server_B that
duplicates Nodes on other TSM servers
and clean up Server_A
You are left with impossible to export
data on a new server.

Non Export variant, Siamese Twins

Consider two huge, unacceptable to export nodes on one
server.
You wish to separate them, but because you are not
doing a true Export, there is no Copy operation as far
as the media is concerned.
It is necessary to COMPLETEY Collocate the nodes.

One the collocation is complete, restore the DB to each of two

new boxes.
Checkin the media for Node_A into Server_A.

Checkin the media for Node_B into Server_B.

Delete all of Node_B from Server_A

Delete all of Node_A from Server_B

The twins are separated.