NBU 6.0 MP4 - Backup crash because partition gets full - Not a catalog size problem !

[Julien_2]

Hi,

I run a NBU 6.0 MP4 on a local server (Win2003R2 - SP1) to backup local and network contents as well.

NBU system as well as the catalog are stored on a D: partition of 20 GB.

My catalog backup never reached more than 550 MB.

Nevertheless I experience more and more often the following problem:

- the D partition gets full so NBU jobs crash and can't backup

- I checked every folder size, especially \Veritas\Netbackup and all size are normal: I can't find out where are those used 18 GB...

- I tried to restart Netbackup Client Service and its depending services but it fails

- the only error message get, is when I access the "Activity Monitor": I get

"Unable to obtain the server list from Enterprise Media Manager server. Database Server is down (93)."

=> My only solution is to restart the whole server, so that the space on D: gets free. It happened first once in 3 months, then per month, now last crash was 3 weeks ago.

Any hint would be really appreciated.

Message Edited by Julien on 10-08-2007 07:38 PM

[DavidParker]

Check the root of D for (hidden) system files.
Perhaps VSP cache files as well.

[Julien_2]

Indeed I checked:

- no special system files

- NBU VSP cache was empty

Those crashes also never happened at same date or time.

Still investigating..

[xorsisten]

I had the same problem a while ago. It´s the logs that size up the partition. Logs starting with 51216..... in the log directory.

There is an article about how to fix this. Or you can decrease the log days from default 30 days.

http://seer.entsupport.symantec.com/docs/281360.htm

/ Anders

[Casey_King]

I had this problem when I migrated from 5.x to 6.0MP4.  Is was the 51216 logs (better known as the unified logs).  This was a logging change made in 6.0, and by default the logs are to be kept for 28 days, each day consisting of 3 log files (days and number of logs can be specified through the master server settings).  I modified my settings to only keep the last seven days of logs.

[Julien_2]

Thanks for pointing me to those 51216 logs, I changed some settings and will follow up in the future.

The root of the problem was indeed the VSP cache file on D: reaching 18 GB (explorer shows 0 KB, defrag shows 18 GB...) Default settings for cache files allow up to 30 GB, but modifying might also result in backup crash.

The tool "Unlocker" helped me to delete the file without having to restart the server this time.

Until I get my new backup server with more storage, I'll have to deal with that..

Thanks all !

[Stumpr2]

---

Julien wrote:

The tool "Unlocker" helped me to delete the file without having to restart the server this time.

---

Where did you find the tool unlocker?

[Julien_2]

Just searching on google for "unlocker" - its a free utility.

[sdo]

Julien, try restricting the size that the VSP cache is allowed to grow up to, in the client "properties" tab "VSP" (you won't find the "VSP" properties tab in the master server "properties" - it's a client based setting).  If you don't restrict the allowed maximum size, then it will always be allowed to grow up to 30GB.

See this link for more info re VSP:

https://forums.symantec.com/syment/board/message?board.id=21&thread.id=36837

[Stumpr2]

Julien,

Thanks.

[Casey_King]

I use Process Explorer to do this.  Hadn't heard of unlocker....will have to check it out.

[Stumpr2]

Casey,

same here. I have used process explorer and this was the first time I heard of unlocker.

[Julien_2]

Well, I just wanted to notify that the problem is solved, no crash anymore.

Solution was to modify the VSP maximum allowed size, in my case a little a bit lower than the default 30 GB because of my small partition hosting this file.

Thanks to you all again !

Julien