Sunday, May 30, 2010

When Data Isn't There, But Is Really There!

OK so the title seems odd, but I had this occur recently when our UNIX Admins decided to convert a subdirectory to a file system. So they created the file system and wiped out the subdirectory expecting us to restore the data. When you would query for the backups nothing would show as having been backed up. (Let me clarify that the Admins did the change and then a week later alerted us and asked for the restore.) So the project manager asked for the restore but did not clarify the directory had gone from /opt/ar/ to being file system /opt/ar/. So any

dsmc res /opt/ar/* /opt/ar/ -pick -inactive -subdir=yes 

returned no data. What I had to do was

dsmc res /opt/* /opt/ar/ -pick -inactive -subdir=yes -pitd=

and then the data would show and I could select it manually for restore. If there is one thing I have learned with TSM is always double, triple, and quadruple check for "missing" data using various methods, chances are it is probably there. Remember the user is clueless....don't get me started on symbolic links and how users don't always know the actual location of their data.


  1. Hi,

    this may happen - what you can do is to use "{}" brackets around filespace name.
    So if the file file.txt was originally in the /opt/ mountpoint in directory /ar/ (so the path is /opt/ar/file.txt) and you have another filespace /opt/ar - which does not contain the file - then issue:
    dsmc restore {/opt}/ar/file.txt
    What I do when searching such files is the SELECT against BACKUPS/ARCHIVES table(s) to find out FILESPACE_NAME, HL_NAME and LL_NAME


  2. Harry,

    Thanks for that I was unaware of the bracket option. I'll definitely remember that in the future.