Deleted filespace keeps coming back

[junk2]

TSM 6.3.4 on RHEL6

For years we have been backing up the /opt/junk filesystem on a RHEL5 machine named CLIENT1.

Now, we want to stop backing up that filesystem and additionally remove existing backups of that filesystem from TSM.

/etc/inclexcl.def has been changed on CLIENT1 to say "exclude.dir /opt/junk" , and looking at dsmsched.log on CLIENT1 reveals that it is indeed being skipped when backups are performed.

In dsmadmc, i've performed DEL FILESP CLIENT1 /opt/junk and although the log says "0 objects deleted", it completes successfully, and the /opt/junk filespace no longer shows up in Q FILESP .

But, the next day, when I do a Q FILESP , /opt/junk again shows up, with the same amount of GB as before. I have done this several days in a row, and each time the filespace comes back the next morning.

What am I doing wrong?

Thanks in advance for any clues...

 

[LED888]

When there is a change in the dsm.opt and/or dsm.sys the schedule daemon need to be stop and restarted so that the new update(s) are read into memory.

Good Luck,
Sias

 

[Harry_Redl]

Hi,

"Q FILESPACE" shows data about filesystem reported by the client - it does not show amount of data in the TSM (use "q occ <node> <filespace>" instead). So if TSM client "touches" the filesystem then filespace is created (even if everything in it is excluded).
Try "exclude.fs /opt/junk" in your dsm.sys (and restart the scheduler/CAD if used - as Sias mentioned).

Harry

 

[junk2]

Thank you.... I had been misinterpreting the output of QUERY FILESPACE. The filespace was not in fact coming back. And, as you say, QUERY OCCUPANCY does what I was looking for. Thanks!