• Please be aware that ADSM.ORG will be going through forum software conversion and migration over the next several weeks. The cut-over date and time will be posted as we near the target date. Please visit the following link for more details ADSM News & Announcements
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

How on earth do I fix this?

ldmwndletsm

ADSM.ORG Senior Member
Joined
Oct 30, 2019
Messages
224
Reaction score
4
Points
0
I don't think I've ever run into this problem before. We have a client that used to have a /var/tmp file system, so "tmp" was not simply a directory under /var, although I think the /var file system also existed. Now, we no longer have /var/tmp as a separate file system, only /var, but there is a "tmp" directory under /var. I checked, and tmp is not a symbolic link, and there is no entry in /etc/fstab for /var/tmp (even a bind mount), only /var. There are no excludes for /var in dsm.sys.

Problem is how do I restore something under the current /var/tmp subdirectory? I believe TSM is confused and thinks that I'm trying to restore it from the old /var/tmp file space that previously existed, and the file was never backed under there.

I can see in dsmched.log that files under the current /var/tmp are being Sent during backups with no errors -- all good. Also, if I run this: "dsmc q backup /var -subdir=yes | grep tmp", I can see the files listed with the recent backup date, all Active. However, if instead I run this: "q backup /var/tmp/filepathname", it doesn't find it, so it appears that TSM is trying to find it under the old file space /var/tmp, where, of course, it was never backed up. I can run "q filespace", and I see "/var/tmp" listed with an old backup date, and, yes, I can query data under there, but nothing from the more recent backups of /var/tmp wherein tmp is now a subdirectory.

How do we resolve this mess? Sheesh! What a mess.

Actually, I don't need to restore anything under there -- don't know that we'd ever have to or would want to? -- so I'm just asking how you'd get around this type of problem if, say, it was some other scenario not involving some tmp directory where there could be something that might need to be restored.
 

ldmwndletsm

ADSM.ORG Senior Member
Joined
Oct 30, 2019
Messages
224
Reaction score
4
Points
0
Trying to track this down through internet searches proved too elusive so I gave up and decided I'd better just ask with the experts here. Yes, we could delete the /var/tmp filespace from the TSM server, but if anyone needed to restore something from that old space then we'd be in a bind, so I'm wondering if there might be some clever way, minimally to at least query the new files under /var/tmp from dsmc without TSM defaulting to the old space.

Maybe I'm just misunderstanding something obvious here?
 

ldmwndletsm

ADSM.ORG Senior Member
Joined
Oct 30, 2019
Messages
224
Reaction score
4
Points
0
Maybe you'd have to restore all of /var and then delete everything other than tmp. I guess that work work, but that would be an aggravation if the residual data outside the subdirectory of interest was huge. Still no obvious way to tell "dsmc query backup" to address the actual subdirectory and not the old filespace other than to keep it at the /var/ level and add "-subdir=yes". Hmm ...
 

ldmwndletsm

ADSM.ORG Senior Member
Joined
Oct 30, 2019
Messages
224
Reaction score
4
Points
0
It would seem that the logical means for IBM to allow you to work around this would be to simply permit the filespace id to specified instead, similar to searching for a file by inode number. I see no provisions for that with dsmc, however. But it is supported, of course for the SQL queries. Maybe I missed it in the help page for dsmc?
 

ldmwndletsm

ADSM.ORG Senior Member
Joined
Oct 30, 2019
Messages
224
Reaction score
4
Points
0
Eureka! I finally found the silly answer to this. You have to enclose the file space name in braces as:

dsmc query backup "{/var}/tmp/"

So the above command will search under the tmp directory in the file space /var, not the /var/tmp file sapce whereas either of the following two commands will accomplish the same thing for the /var/tmp file space:

dsmc query backup /var/tmp/
dsmc query backup "{/var/tmp/}"

Apparently, restoring data works the same way. I might have learned this at one time, but if so, I'd long forgotten it, and I don't recall ever having to use it.

The following IBM document discusses this:


The key is that it always picks the longest file space name matching the specified file.

I'd been searching relentlessly for this, and my recollection of braces was not literal, but just a way of representing what you would specify that's named within the braces.

Does anyone know where in the "dsmc" command Help this is discussed? Also, is there a way to dump out the Help to a file to search it?
 

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 22 19.5%
  • Keep using TSM for Spectrum Protect.

    Votes: 67 59.3%
  • Let's be formal and just say Spectrum Protect

    Votes: 15 13.3%
  • Other (please comement)

    Votes: 9 8.0%

Forum statistics

Threads
31,858
Messages
134,954
Members
21,834
Latest member
wilsocl
Top