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.
Hi,
ReplyDeletethis 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
Harry
Harry,
ReplyDeleteThanks for that I was unaware of the bracket option. I'll definitely remember that in the future.