The question to consider is what is in the tmp directory, and why do you think 
it needs to be deleted?

punit wrote:

> You don't need /nsr/tmp it has all temporary data that is needed by current 
> instance of savegroups & daemons, but all that is tmp, as Frank said deleting 
> will not create any problem unless you are removing it when daemons are 
> running.
> 
> Just to add, u need sec directory under tmp in case you do not want to loose 
> the current group details, by that what I mean is, if you delete sec you will 
> not be able to restart(resume) the savegroups, after restarting the daemons 
> all groups will be marked as completed (green checkbox status). sec contains 
> saveset level info i.e which savesets completed, which failed and which never 
> ran. If you restart a failed savegoup incomplete & failed savesets will run 
> again. You can always start the group which will start all clients in that 
> group and all savesets again. 


punit is correct.  In fact, there is another directory /nsr/tmp/sg that holds 
savegroup reporting information as well.  Good to keep this as it is another 
location where group reporting is stored.

For those that do ndmp backups, there are files that are named 
/nsr/tmp/FileIndex...  These hold the list of files that are backed up during 
the ndmp backup, and are committed to the client file index after the data is 
backed up.  After it is committed, then the files are removed.  So if these 
files exist and there are no ndmp backups running, then these files are useless 
and can be removed.  Good thing because these files usually consume a lot of 
space.

Another set of files that can be found in /nsr/tmp are files that start with 
"sd".  These are created when a client is backed up and it uses a global 
directive.  Though they don't take up space, they don't get automatically 
deleted either (that I've seen) and can pile up.  These can be safely removed 
when there is no backups.

My personal peeve is hearing people say that deleting /nsr/tmp is the solution 
when backups or jukebox is hung...  that NetWorker will work ok if you just 
clear tmp regularly.  If you think about it, how do you know that deleting tmp 
solve the issue, and not restarting the NetWorker application?  Isn't this 
similar to the windows solution of rebooting Windows will fix everything?


Stephanie Finnegan wrote:

> Clearing out /tmp (along with renaming the jobsdb) is a common suggestion 
> from EMC support when troubleshooting random anomalies. 


Sorry to hear that, and regrettably all too true.  It's so common that some 
users, and even tech support, suggest it either because they do it out of 
habit, or cause they don't know what's causing the problem and delete it "just 
on the chance" it might do something beneficial.

If I really had to delete tmp, then i keep the sec and sg subdirectories.  
Except to remove the accumulation of "FileIndex" and "sd", I cant think of any 
reason why you need to delete /nsr/tmp.

Indeed you better off to delete OLDER copies of jobsdb directory that 
accumulates.  They usually take up more space that what tmp uses.  Even worse 
if those old jobsdb copies are still in /nsr/res, then they will also be backed 
up as part of the bootstrap backup, causing the bootstrap to be larger than it 
really needs to be, and thus causing the bootstrap backup and recoveries to 
take longer.

+----------------------------------------------------------------------
|This was sent by wl905 AT yahoo DOT ca via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER