TSM Restore Hints

The links below take you to sections within this document


BASIC RESTORES

Date options on restores

Date options on restores can be a bit confusing. The first thing to remember, especially if you move between companies, is that there are various different date formats available in TSM. The date format is set in the TSM OPT file used by the TSM server. The default format is MM/DD/YYYY, other possibilities are DD-MM-YYYY, YYYY-MM-DD, DD.MM.YYY & YYYY.MM.DD. The easiest way to find out which option is in use is to run a 'query backup' on a small directory and that will show you existing backups with dates.

There are three different types of date available for restores

TODATE will restore all ACTIVE and INACTIVE files backed up BEFORE the date specified
FROMDATE will restore all ACTIVE and INACTIVE files backed up AFTER the indicated date.
PITDATE will restore only the files that were ACTIVE on the day specified.

All three of these commands have associated time parameters TOTIME, FROMTIME and PITTIME, which default to 23:59:59. You would usually use todate and fromdate together to restore data that was backed up between a range of dates and times. You cannot use PITDATE in combination with TODATE or FROMDATE.
To use PITDATE effectively, you have to consider when a backup was taken. For example, you want to recover d:/mydir, as it was on July 4th, 2011. The backups run overnight, and usually complete by 06:00. The command to use would be

res d:/mydir/* -pitdate=07/05/2017 -pittime=07:00:00 -subdir=yes

You specify 07:00 on July 5th., to catch backups of files changed on July 4th., and that will get your directory back to as it was on the evening of July 4th. The only caveat is that a PITDATE restore will not delete any files created after the restore date.

PITDATE is slower than -FROMDATE & -TODATE, though it restores less data. That is because the -PITDATE option uses a different 'No-Query' Restore protocol. Your copygroup retention parameters determine how far back you can go with PITDATE. If you want to be able to take a server, or a directory back in time for 60 days, then you need to code

VEREXISTS=NOLIMIT
VERDELETED=NOLIMIT
RETEXTRA=60
RETONLY=60

back to top


How to recover a file with spaces in the name

Enclose the filepath in quotes. For example

restore "\\server name\c$\\PROGRAM FILES\COMMON FILES\file name.ext"

This applies in any circumstance where you have to specify files by name.

back to top


What is the difference between a no query restore and a standard restore?

TSM has two types of client restore, a 'classic' restore or a 'no query' restore. TSM will automatically decide which restore type to use, a Classic restore is used if the restore parameters specify any of 'latest', 'inactive', 'pick', 'fromdate' or 'todate' and a No Query restore is used for an unrestricted wildcard source file specification.

In a standard restore, the client queries the server for all objects that match the restore file specification. The server sends this information to the client, then the client sorts it so that tape mounts will be optimized. However, the time involved in getting the information from the server, then sorting it (before any data is actually restored), can be quite lengthy. Once the restore list is built, TSM requests the files from the server in groups where the group size is based on the TXNBytelimit setting on the client and the TXNGroupmax setting on the server. This used to work fine but can be a real problem if the file system cotains millions of files as it uses up client memory and so will cause system paging and performance issues.

A 'No query' restore lets the TSM server do the work: the client sends the restore file specification to the server, and the server starts restoring files as soon as it has found enough for a group, while at the same time building eligible files for the next group. The most visible benefit of no query restore is that data starts coming back from the server sooner than it does with 'classic' restore.

However, some Tivoli Storage Manager customers with large client file systems have reported performance problems when the NQR technique is used and only a few files qualify as restore candidates. It could take the TSM server up to an hour to search its database tables for eligible files before any are sent to the client. It is possible to force such a restore to use the classic method by specifiying the "-latest" option as part of the restore command or by selecting the 'Disable No Query Restore method' check box in the client GUI.

back to top


How do you exclude files from a restore?

It is possible to do this using an undocumented command. All the usual caveats for undocumented commands apply: Test it first before you use it for real, and it it goes wrong, don't expect to get any support.

The command is

EXCLUDE.RESTORE file.name

back to top


Finding the tapes needed to restore a node

This is a common question and I've never seen a good answer. The following SQL query will show you all the backup tapes used by your node, but your restore will just want a sub-set of them. If anyone has a better answer I'd like to hear it.

select distinct node-name,volume-name,stgpool-name from volumeusage where node-name='xxxxx'

You need to change the xxxxx to your node name, and it will be case sensitive. If you just need to restore one filespace, you can limit this down by adding "and filespace_name='filespace_name'" to the end of the query above.

back to top


ADVANCED OPTIONS

Using the GUI for PIT restores - the files are missing!

There are two ways to run Point-in-time (PIT) restores; from the command line and from the GUI. However if you use the GUI you might find that it does not display any files for a given date, even though you know that backups exist.

The problem is down to the way the GUI works. It does not display a list of all available backups and versions for a client, as this would take too long to build and probably cause memory shortages on the client. You are initially presented with a list of available file spaces, and you have to drill down through the file spaces and directories to get a list of backups available in a given directory.

However if there is no retained backup of a directory then you cannot click on it to see the backups within it. Directory backup retention does not depend on the number of backup versions kept, but they get the management class within the policy domain that has the highest 'Retain only version' setting. It is possible that the management class (MC1) with the longest RETONLY setting will only keep one backup version, while you may have another class (MC2) that keeps twenty versions, but with a smaller RETONLY setting.

So consider the following scenario. You backup your directories to MC1 by default, but you bind all files in the /audit/ directory to the MC2 management class

Apr 01 - run the your first backup, the directories will all get MC1 management class and all the audit files get the MC2 management class.

Apr02-06, further backups of audit files, up to 6 backup versions retained, depending on how often the files change

Apr07, change the AUDIT directory and it gets backed up again, the first version expires

Apr08-12, more backups of audit files, up to 12 backup versions now retained.

Apr13, decide to recover the AUDIT directory back to Apr 04, run a PIT restore through the GUI, but you can't see anything as the directory backup from Apr01 has expired but you know that backups of files exist as they have a 20 day retention!

The short term solution is to use the command line as this does not rely on the ability to display directories before it can display its files and subdirectories.

If you want to use the GUI then the long term strategy is to make sure you keep enough backup versions of your directories by assigning them to a suitable management class. Set one up with VEREXISTS=NOLIMIT, VERDELETED=NOLIMIT, and RETEXTRA='n' where 'n' is the number of days that you must be able to go back with the GUI to do a PIT restore. You could set RETEXTRA to NOLIMIT of course but that could be expensive in terms of database usage

back to top


How do you recover files between 2 different clients?

The first thing to note is that the clients must both be the same platform. You cannot recover a file backed up from a UNIX box to a Windows box, for example. Be aware that if you try to access UNIX backup data from a Windows client using the virtualnode option below, you may prevent all access to the UNIX backup data.

By far the easiest way is to invoke your command line or gui with the virtualnode option. This does not disturb any of the existing client configuration and will not affect backups. Navigate to your TSM directory on the client you want to restore to, usually \program files\tivoli\tsm\baclient\ (Windows) or \usr\tivoli\tsm\client\ba\bin64\ (AIX) and run one of the following commands.

dsmc -virtualnodename=sourceclient
dsm -virtualnodename=sourceclient

The first command opens the tsm command line, the second command opens the TSM GUI. The sourceclient is the name of the client that you want to restore files from, and TSM will always prompt you for its password. You will then be able to query all the backups on the source client, but when you run a restore, you must give TSM a target location on your current server, or it will restore to the original client.

Another option is to use the 'fromnode' parameter, which allows you to query backups that exist on ClientB while you are logged onto ClientA, and then restore those files from ClientB to ClientA.

restore d:\data\appdir\* -fromnode=ClientB

However for this to work you need to use the SET ACCESS command to allow one client to see the backups from the other. You can set the access globally so that all the backups can be seen and restored, or you can limit it to a subset of directories. The syntax can vary for the 'set access' command depending on directory structures.

If you want to access a directory on ClientB from ClientA and that directory does not have a sub-directory under it then use the following commands on ClientB

set acc backup d:\data\appdir ClientA
set acc backup d:\data\appdir\* ClientA

If you want to access a directory on ClientB from ClientA and that directory has sub-directories, but you only want to give access to the root directory use

set acc backup d:\data\appdir\* ClientA

If you want to access a directory on ClientB from ClientA and you want to grant access to all sub-directories but not the root directory use

set acc backup d:\data\appdir\*\* ClientA

If you want to access a directory on ClientB from ClientA and you want to grant access to the root directory and all sub-directories use

set acc backup d:\data\appdir\* ClientA
set acc backup d:\data\appdir\*\* ClientA

back to top


TROUBLESHOOTING TSM RESTORES

ANS1314E File data currently unavailable on server

This message sometimes crops up with Oracle restores, basically it means that TSM was unable to access the data, not necessarily that the backup data does not exist. I suggest that first you check to see if you had problems with tape drives. The specific error messages can be many pages above or below the ANS1314E messages, so the best way to check is to search the activity log for error messages "ANR8779E unable to open drive". If you have a faulty tape drive, you will see a number of errors for that drive. Vary the drive offline and retry your restore.

If your drives are OK, then the next suspect is a faulty tape, but you need to know exactly which tape you were trying to use. The ANR1314E message should list the file that it could not get. You need to match that file to a tape and one way to do it is to run the following commands. These commands assume that you are looking for a backup of a file called no.restore.txt, from a node called WIN_SERVER001. These commands can also be used to investigate archive recall problems. First you need to find the OBJECT_ID of the file you are after.

select object_id from backups where node_name='WIN_SERVER001' and ll_name='no.restore.txt'

That command will return an object ID, something like 123456789. Next, you need to run a show command which tells you which volume that object is on. Like all show commands, this command is unsupported. Substitute your own object ID.

show bfo 0 123456789

This command may return a tape volume name, like 'Volume Name: E12334', or it may return a disk file name as a super bit object, like 'Super-bitfile:0.12345' In this case you would re-run the show command with 12345 as the object, and it will return the disk file name.
Once you know which tape or disk file was required, you can run commands like 'query volume' to check the volume status, 'query content ... damaged=yes' to check that the backup is OK, or audit the volume to attempt to fix any problems.

back to top