tape backup

Symantec Backup Exec Fun

Backup Exec is a great application, my personal favorite. Recently I had issues with a backup, as you can see in one of my previous posts… the backup works fine, although compression will not turn on. It is known by most Backup Exec experts that Symantec Backup Exec enables compression when the job starts(if compression is configurable), but how do YOU know if Backup Exec is doing its job and possible the drive is to blame?

Well here is the answer, its called SGMON, its a debug tool that is used to view debugging information for Backup Exec components and services. SGMON is in “C:\Program Files\Symantec\Backup Exec\SGMON.exe for Backup Exec 12.5d installations. Earlier revisions its buried in the Symantec Backup Exec folder, best bet is to just search for sgmon.exe and you’ll find it easy enough. 

Run SGMON, check off Job Engine; as below…

Click “Capture to File also. Leave SGMON running while you start a job, wait for the job to finish, next thing you need to do is locate the file. For Backup Exec 12d its located here; “C:\Program Files\Symantec\Backup Exec\Logs\servername-SGMON.log”

Do a search in the log file for compression, as below…

Once you are sure that Backup Exec is doing what it is supposed to do, and compression isn’t working as you can tell under the media tab. and the appropriate Media Set as shown below… MIND You when compression just isnt working you will see 1:1 instead of 2.3:1.

SGMON can be used for many things, you can find the official documentation here

Anyways, I’m off for now.

Any Questions you know what to do!

NS

IBM ServeRaid

Here’s an interesting issue that I came across. I have a few clients who are still using IBM Servers, the server referred to here is an x226 Server and a ServeRaid 7 controller.

The client said that he would come in to work in the morning to check the backups and he would have to put in a reason as to why the server shutdown. He mentioned that the backups have also not been working for the last week or so. Just to let you know this wasn’t my fault, the client is not managed services and it is up to him to monitor and let me know if they are having issues. Anyways back to the blog :). We came in to troubleshoot the backup and found that we could run a test backup. Just in case a backup to disk was also setup. Next morning it was reported that the backup failed again.

I went onsite and used IBM UpdateXpress, this CD provides an all in one firmware update for all supported components contained within the server. You can download it here. I Updated the Server’s BIOS, ServeRaid Bios/Firmware, and also the firmware of the drives themselves.

I also ran an app from IBM’s Site called Dumplog, this will “dump” the configuration and event logs from the ServeRaid controller, don’t try to decipher any of the info in the txt file, you need to send this to IBM and they will tell you what your next step it based on the info contained within that file. Download it here

Well to make a long story short… the server would crash when stressed with I/O. I figured it had to be the controller, so I ran the onboard diagnostics, and sure enough the ServeRaid test failed. I exported the test log to a text file so I could send it to an IBM Tech. Once the IBM Tech saw the dumplog files he was able to tell me that a specific drive was failing, although the drive was not reporting it to the controller properly, thus the global hot-spare wasn’t kicking in. I ended up running ServeRaid Manager and marking the bad drive  defunct, then I pulled the drive out of the server. The global hot-spare then kicked in and the rebuild started.

All seems well. It would have been nice if the drive just marked itself bad in the beginning and the issue would have been resolved much faster.

IBM Tech Support requires firmware and drivers to be up to date before they will really help you, so everything I did needed to be done. IBM is now sending a tech onsite to replace the drive and also the tape drive as It still didn’t work in the end. A backup to disk job was configured before going off site.

Till next time!

NS