Navigation Bar

TSM Restore Hints

Date options on restores
Using the GUI for PIT restores
Finding the tapes needed to restore a node
How do you recover files between 2 different clients?
Cross-client Windows restores
How to recover a file with spaces in the name
What is the difference between a no query restore and a standard restore?
How do you exclude files from a restore?
How to recover the Windows System Object
Restoring a Windows 2003 server using ASR
Windows 2000/NT Bare Metal Recovery Procedure
Restoring Netware Cluster files



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.

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.

To use these effectively, you have to consider when a backup was taken. For example, you want to recover d:/mydir, as it was on July 4th, 2001. The backups run overnight, and usually complete by 06:00. The command to use would be

        res d:/mydir/* -pitdate=07/05/2001 -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.

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 got 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


Finding the tapes needed to restore a node

Try the following SQL query

 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.

back to top


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 he 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 an NT box, for example.

After that, you have 2 options, you can GRANT permissions to recover between servers, or you can fool TSM by changing the dsm.opt file. Say you want to restore client A's filespaces to client B

Just go into the dsm.opt of clientB, and change the NODENAME parameter from ClientB to ClientA. You can then kick off a normal restore.

However, remember to make sure no backups of clientA run while you are busy, or the wrong data will get backed up. And, of course, remember to change the dsm.opt file back again when you are finished.

If that method looks too hairy, then the safe way is to grant access. Issue this command from the DSM prompt in serverA

    SET Access Backup * Server_B

the recovery command is

res -fromnode=serverA serverA/filename serverB/filename etc...

Cross-client Windows restores

First, you need to set restore permissions as above

With Windows, start the client command line with start dsm -nodename=xxxxxx where xxxxxx is the name of the node you are recovering from, and you are logged onto the node you are recovering to. Windows seems to be very fussy about having the exact file space name. Typically, this will be '\\servername\disk\' . For example '\\CL12482\d$\' You can get the exact file space name by running a 'query filespace' from the TSM server. Technically, you don't need quotes in these examples, but I like to give windows restores all the help I can.
You will be prompted for the TSM userid and password for the source server, before the restore will start.

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?

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.
A 'No query' restore lets the TSM server do the work: the client sends the restore file specification to the server, the server figures out the optimal tape mount order, and then starts sending the restored data to the client. The server can do this faster, and thus the time it takes to start actually restoring data is reduced. For a given restore, TSM mounts each needed tape once and only once, and reads it from front to back.

The most visible benefit of no query restore is that data starts coming back from the server sooner than it does with 'classic' restore.

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


How to restore the Windows System Object

See the Windows section for details of what Microsoft call the System State , and TSM calls the System Object.

The command is simply

  
 restore systemobject 

It will restore ALL of the System objects which were backed up, but exactly what was backed up will depend on your Windows version and setup. See the TSM backup tips section for details.

The restore systemobject command is only valid for Windows 2000, XP, and Windows.NET.

If you just want to restore the Windows NT registry system object, use the command

  restore registry entire

This command has a number of parameters which allow you to restore just part of the registry

To restore the active Windows NT eventlog, use the command

  restore eventlog entire

back to top


Restoring a Windows 2003 server using TSM ASR

Recovery pre-requisites

The main physical requirement for BMR is that the new server must have the same number of disks as the original, and each disk must be the same size, or larger than the original disks.

To run the restore, you need

  • An ASR diskette, as described in the Windows section
  • a Windows CD that is at the same operating system level, and with the same service packs, as the operating system was at when you took the ASR backup
  • a TSM client CD that is at the same level or higher as the one that was used for the backup. It must be 5.2.0 or above.
  • A network connection that supports DHCP. (Dynamic Host Configuration Protocol is an Internet protocol for automating the configuration of computers that use TCP/IP)
  • The TSM node and password for the original client

The recovery process

  1. Boot the server using the windows install CD. You will need to reply to the prompt 'Press any key to boot from CD .. ' quite quickly
  2. Once setup commences you will see a message at the bottom of the screen that says 'Press F2 to run Automated System Recovery (ASR)' Again, you need to press F2 quickly or the setup will continue
  3. Insert the ASR diskette that you created with TSM into the floppy drive when you see the prompt 'Please insert the disk labeled Windows Automated System Recovery Disk' TSM will actually have labeled this disk TSMASR
  4. Windows will then check and reformat the disk partitions and the boot volume as necessary to match the original server setup, then copy some file across.
  5. When prompted by the message 'Insert the CD labeled TSMCLI into your CD-ROM drive', do just that. This will copy TSMCLI.EXE over.
  6. You will then be prompted to mount the TSMASR diskette again, so Windows can copy over three TSMASR files.
  7. The server will reboot, you will be prompted to remove the TSMASR diskette first.
  8. You then need to put the windows install CD back into the CD drive to allow the install to continue.
  9. ASR will install the TSM client, then ask you if you want to recover from a remote TSM server, or a local backupset, and ask for the TSM userid and password.
  10. TSM will then recover the system disks from the TSM backup, the system will be rebooted, and the server will be back to its former state, except that you will have to run normal TSM restores for all the data and application drives.

Of course, all this depends on you having an up to date TSM ASR diskette. What if you didn't create one? If you are stuck, you could create an ASR diskette on another (working) machine following the instructions in the backup section. You will need to edit the tsmasr.opt and tsmasr.cmd files on the diskette to change the nodename from the working server to the one you want to recover.

back to top


Windows 2000/NT Bare Metal Recovery Procedure

I have used the procedure below to recover Windows 2000 servers, but I strongly recommend that you test and refine it to suit your environment before you have to use it for real.

  1. Build a base W2K system from same service pack level as the system you are restoring, and use the same hostname and IP address.
  2. Create the data partition(s) and change the drive letters as necessary then reboot. This all assumes that you have all this information recorded and up to date.
  3. Install TSM client and reboot.
  4. Create a new folder in %system% called 'Sysfiles'. Copy hal.dll, kernel32.dll, ntdll.dll, ntoskrnl.exe, win32k.sys and winsrv.dll to this folder. Back them up using ntbackup.exe to a file named sysfiles.bkf. Copy %system%\system32\drivers\atapi.sys to the Sysfiles folder and rename it to the same as the live server's RAID driver (eg;- pedge.sys). Back it up using ntbackup.exe to a file in the same folder called driver.bkf.
  5. Use TSM to restore the system partition and system state with the exception of boot.ini. Use 'replace all' and DO NOT REBOOT when prompted at the end of the restore.
  6. Using ntbackup.exe restore the contents of sysfiles.bkf to %system%\system32\ and driver.bkf to %system%\system32\drivers\, reboot.
  7. Boot from the W2K install CD and start the setup routine; select Install and then Repair - if Windows doesn't autodetect your SCSI or RAID card you'll need a diskette with the drivers and will need to watch for the 'press the F6 key' prompt when setup starts. Let the setup routine redetect hardware and reinstall the system files
  8. Check the LAN connections in Network Places and note the name of the working one. Run Regedit and open the following key;
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network
    
  9. Export a copy of this key to the Sysfile folder. Open the first GUID entry under this key, which should contain further GUIDs for each network adapter's connection. The first sub-key GUID entry should be for the current functioning NIC's connection. The name is noted in the connection sub-key of each entry.
  10. Delete all other GUID entries but do not delete the Connections key.
  11. Bind and configure IP correctly, if any errors are encountered uninstall and re-install the NIC first. Re-install the TSM client and restore the application and user data.

back to top

How to restore the Netware NDS

The basic restore command

The command to restore the entire NDS is simply

  restore dir.* -replace=yes

And to restore an NDS object called tsm,

  restore nds:.o=tsm.* -subdir=no

But its not that easy! NDS objects can refer to other NDS objects. Say you have an NDS object tsm, which refers to another NDS object obj2. If you are recovering the NDS, and you restore object tsm before object obj2, then tsm cannot refer to obj2. The solution is to use a 'placeholder' object, which satisfies the reference, and will eventually (or hopefully) be replaced by the real obj2 object, when the restore reaches that point in the NDS.
If you just restore part of the the NDS, it is possible that a place-holder object will never be restored, and so it will remain in the NDS tree as an object of type unknown. You then have the choice of either deleting the unknown object or restoring the real object with a selective restore. If you are running a restore, and placeholder objects already exist then TSM will not restore over them, unless you tell it to with the REPL=YES parameter. Its possible for this to happen even when restoring an empty NDS. In general, avoid partial NDS restores unless you know the NDS well enough to sort out any unresolved object references.

If you lose your SYS volume, you also lose the NDS. This command will also restore the entire SYS: volume, and the NDS

 load dsmc restore sys:* -replace=yes

If the server had volumes other then SYS, and you do not need to restore them, you need to run the Netware utility DSREPAIR to purge the file system of invalid trustees on those volumes.

Incidentally, trustees to files or folders are not recovered with the NDS as these are stored in the Netware filesystem. When you restore your data to a Netware server with an intact NDS, the trustees will be also restored. During a restore of the NDS, only the trustees to NDS objects will be restored.

back to top


Restoring Netware Cluster files

Restoring a file in a Netware Cluster is that same as any other file, except that you have to know which physical Netware server is hosting your disk. The backup section explains how to set up Netware cluster aware backups and the netware section explains how clustering works. This section explains how to set up cluster aware restores.
In this explanation, I assume that every Netware partition holds only one cluster disk. This is common practice to keep the cluster set-up simple. If you run with more than one disk on a cluster, then you need to nominate one disk in the partition to hold the tsm data. So when I talk about a cluster disk below, I really mean the cluster disk in the partition that contains the tsm data.

To use the TSM Web Client or GUI, each cluster disk will need a unique http: port. Every cluster disk will have its own dsm.opt file, and I'll assume it's located in a tsm directory, that is disk_name:/tsm/dsm.opt

For every cluster disk, add an HTTPport line in the dsm.opt file and make sure that the port names are unique. For example

on disk SALES1: in file sales1:/tsm/dsm.opt add entry HTTP 1600
on disk SALES2: in file sales2:/tsm/dsm.opt add entry HTTP 1601

Unload and reload the DSMCADs to pick up the port names.
Every Netware Partition will have a virtual IP address. Point your browser at the disk and port, using the virtual IP address of the partition, and the correct port number,

  http://123.456.78.90:1600

or the DNS entry of the disk, if you use Domain Name Services (the nslookup command will display DNS aliases if they are defined)

  http://sales1:1600

TSM will find the physical server that is hosting the disk and load up the TSM GUI and can run restores as usual. When you open the client services GUI, tsm will run an NLM on the Netware server called DSMAGENT.NLM

If you prefer command line restores, then just fire up rconsole, pointing rconsole to either the cluster disk name if it has a DNS alias, or the IP address, and then from the system console run the dsmc command, but point dsmc to the correct dsm.opt file for the disk that you want to recover from like this;

  dsmc -optfile=disk_name:/tsm/dsm.opt  

and this will connect to the TSM server as the correct node.

back to top


Copyright © Lascon Storage Ltd. 2000 to present date. By entering and using this site, you accept the conditions and limitations of use