Restoring a file on TSM for a server or share drive

— ny_wk

To restore a file in TSM (IBM Spectrum Protect, formerly Tivoli Storage Manager), open the Backup-Archive GUI on the server, expand the backup tree to the file or folder you need, optionally switch to Point-In-Time to pick an older version, then click Restore and choose the original or an alternate location. This guide walks through a clean, reliable file-level recovery on a Windows server or share drive and shows the command-line equivalent so you can script or troubleshoot it.

What TSM is and why a file restore matters

The product many admins still call TSM went through several names: Tivoli Storage Manager, then IBM Spectrum Protect, and now IBM Storage Protect. The client you interact with on a protected machine is the Backup-Archive client (often abbreviated BA client). It runs as a Windows service that performs scheduled incremental backups, sending changed files to a central Spectrum Protect server, while the GUI and command line (dsm.exe and dsmc.exe) let you pull individual files back on demand.

A TSM restore is the most common day-to-day recovery task: a user deletes the wrong document on a share drive, a deployment overwrites a config file, or a folder is corrupted. Because TSM keeps multiple versions of each file (an active version plus a configurable number of inactive ones), you can recover not just the latest copy but the file as it existed on a specific date.

Before you start: prerequisites and access

Recovery goes faster when the environment is ready. Confirm the following before attempting a TSM restore:

• Backup-Archive client installed on the target server, with the scheduler service running so the node is registered and current.
• Network access to the Spectrum Protect server — the client must reach the server defined in dsm.opt (TCP/IP address and port, default 1500).
• The correct node name. Each protected machine backs up under a node. Restoring another machine's files (for example, a share that lives on a different file server) requires the right node and, often, restoring as another node with the -FROMNode option.
• Permissions. You need administrator rights on the Windows machine and a TSM node password (or a stored/encrypted password) to authenticate to the server.

If you are restoring to a file server or share drive, run the client on that server rather than from your workstation, so the restored data lands on local volumes and NTFS permissions are preserved.

How to restore a file in the TSM Backup-Archive GUI

The graphical client is the quickest path for a one-off recovery. Follow these steps in order:

1. Log in to the server. Connect to the Windows file server with Remote Desktop Connection (mstsc.exe). Restoring locally keeps the data path short and avoids re-permissioning headaches.
2. Open the Backup-Archive GUI. From the Start menu find the IBM Spectrum Protect (or Tivoli Storage Manager) program group and launch Backup-Archive GUI. It connects to the configured server and authenticates with the node credentials.
3. Click Restore. In the main window's left pane, choose Restore. The client builds a tree of everything that has been backed up for this node.
4. Browse to File Level. Expand File Level, then drill down through the drive and folder structure to locate the exact file or folder you need. Select the checkbox next to each item to mark it for restore.
5. Pick a date with Point-In-Time (optional). By default the client shows the active (most recent) version. If you need the file as it was on a particular day, click Point In Time, set the date and time, then refresh the tree. TSM then shows the versions that existed at that moment. To see every retained version of a single file, use View > Display active/inactive files.
6. Start the restore. With your selection checked, click Restore.
7. Choose the destination. In the restore dialog, select Original location to put the file back exactly where it came from, or Following location to redirect it to a safe alternate folder (recommended when the original may still be in use). Click Restore again to begin.
8. Handle the "file exists" prompt. If the target already contains a copy, TSM asks whether to overwrite. Choose Replace to overwrite, Replace All for a folder, or skip if you do not want to clobber the current file. When in doubt, restore to an alternate location and compare.
9. Confirm completion. When the operation finishes, the client reports the number of objects restored and any failures. The file is now back on disk.

How to restore a file from the TSM command line

The command-line client (dsmc) is ideal for scripting, large batches, or when the GUI is unavailable over a slow RDP link. Open an elevated command prompt and start the interactive client:

1. Launch the client:
   dsmc
2. Restore a single file to its original location (the trailing nothing means "same path"):
   restore "D:\Shares\Finance\budget.xlsx"
3. Restore to an alternate location by giving a destination path (note the trailing backslash):
   restore "D:\Shares\Finance\budget.xlsx" "E:\Recovered\"
4. Restore an entire folder tree, subdirectories included:
   restore "D:\Shares\Finance\*" "E:\Recovered\" -subdir=yes
5. Do a point-in-time restore as the data looked on a given date and time:
   restore "D:\Shares\Finance\budget.xlsx" -pitdate=06/20/2026 -pittime=18:00:00
6. Restore the latest inactive (previous) version when the active one is bad:
   restore "D:\Shares\Finance\budget.xlsx" -inactive -latest
7. Control overwrite behavior non-interactively with -replace and -ifnewer:
   restore "D:\Shares\*" "E:\Recovered\" -subdir=yes -replace=no

To list what versions exist before you restore, use query backup:

query backup "D:\Shares\Finance\budget.xlsx" -inactive

That shows active and inactive copies with their backup timestamps, which is the fastest way to confirm a recoverable version exists on the right date.

Restoring a share drive or another server's files

Recovering data that belongs to a different node (for example, a clustered file share or a decommissioned server's backups) uses the -FROMNode option. The node you are running as must be granted access to the source node's data on the Spectrum Protect server, which the TSM administrator sets with the GRANT ACCESS command. Then:

restore "\\fileserv01\shares\hr\*" "E:\Recovered\hr\" -fromnode=FILESERV01 -subdir=yes

For UNC paths and clustered shares, run the client on the node that currently owns the resource so file-system permissions and ownership are written back correctly.

Common pitfalls and how to avoid them

Most failed restores trace back to a handful of avoidable mistakes:

• Restoring over a file that is open. If an application has the file locked, the overwrite fails or is incomplete. Close the app, or restore to an alternate folder and copy it in afterward.
• Expecting a version that aged out. TSM only keeps as many inactive versions as the management-class policy allows (for example, two extra versions for 30 days). If the version you want is older than the policy, it is gone. Check with query backup -inactive first.
• Forgetting Point-In-Time after a deletion. Once a file is deleted on the client, its backup becomes inactive. The default view hides it. Enable Display active/inactive files or pass -inactive to see and recover it.
• Wrong destination slash. On the command line, a destination that ends in a backslash is treated as a folder; without it, TSM may interpret the path as a single target filename. Always end alternate folders with \.
• Permission loss on cross-machine restores. Restoring share data from the wrong node can drop NTFS ACLs. Run the client on the owning server and verify permissions afterward.
• Insufficient disk space. Large folder restores fail partway if the target volume fills up. Confirm free space before starting a big recovery.

How to verify the restore worked

Never assume a TSM restore succeeded just because the dialog closed. Verify it:

1. Read the summary. The GUI and dsmc both print a final tally — objects restored, bytes transferred, and any failures. Zero failures is the goal.
2. Check the client log. Open dsmerror.log (errors) and dsmsched.log in the client's installation directory for any warnings the summary glossed over.
3. Open the file. Confirm the restored document opens cleanly and contains the expected content for the date you targeted.
4. Compare timestamps and size. Right-click the file and confirm the modified date and size match the backup version you chose — this catches a silent point-in-time mix-up.
5. Validate permissions. On a share drive, confirm the NTFS permissions and ownership are intact so users can access the recovered data.

For a folder restore, spot-check several files at different depths rather than trusting a single sample.

A note on naming and modern TSM

If your menus say Tivoli Storage Manager, you are on an older release, but the restore workflow above is essentially identical on current IBM Storage Protect builds — the Restore tree, File Level, Point-In-Time, and the dsmc restore syntax all carry forward. The main modern additions are a web client and tighter integration with the operations center, but for a single-file recovery on a Windows server the steps you just followed remain the fastest, most dependable route.

Key Takeaways

• A TSM restore in the Backup-Archive client follows one path: Restore > File Level > select > choose location > Restore.
• Use Point-In-Time (GUI) or -pitdate/-pittime (CLI) to recover a file as it existed on a specific date.
• Restore to an alternate location when the original file is in use or you want to compare before overwriting.
• Run query backup -inactive first to confirm the version you need still exists within the retention policy.
• Always verify via the restore summary, dsmerror.log, file contents, timestamps, and NTFS permissions.

Frequently Asked Questions

How do I restore a deleted file in TSM?

A deleted file's backup is marked inactive and hidden by default. In the GUI, enable View > Display active/inactive files (or use Point-In-Time before the deletion); on the command line add -inactive, for example restore "D:\path\file.txt" -inactive -latest. Then restore as normal.

What is a point-in-time restore in TSM?

It recovers your data exactly as it looked at a chosen date and time, using the file versions that were active at that moment. It is the right choice after a corruption or bad change, because it ignores anything backed up afterward. Set the date in the GUI's Point In Time control or pass -pitdate and -pittime to dsmc.

Can I restore a file to a different location or different server?

Yes. In the GUI choose Following location and pick a folder; on the command line give a destination path ending in a backslash. To restore data that belongs to another node, use -fromnode=NODENAME after the administrator grants your node access on the Spectrum Protect server.

Why does my TSM restore say the file already exists?

The target folder already has a copy with the same name. Choose Replace (or Replace All for a folder) to overwrite, skip it to keep the current file, or restore to an alternate location and merge manually. On the CLI control this with -replace=yes|no and -ifnewer.

If this walkthrough helped, subscribe to YouTube @explorenystream for more hands-on system administration and backup guides.