Video Screencast Help

ralus with Backup exec 2010 R3 SP4

Created: 12 Feb 2014 • Updated: 29 Apr 2014 | 9 comments
This issue has been solved. See solution.

SUSE Linux Enterprise Server (SLES)recently upgraded to SP3, as required for continued support by vendor of support for OS.

Remote Agent broken as a result.

The error,

"GetIfADDRS(LINUX): failed err = 11"     occurs when the agent is initialised. The agent starts and immediately stops.

In these forums there is a method of editing the backup exec code using hex, that resolves the problem for at least some versions of LINUX and Backup Exec, but this would be a new venture into unknown territory for me.

 

Is any one aware of Symantec making available an official solution?

Can anyone confirm that Phil's fix works with SLES 11 SP3 and BUExec 2010 R3 Sp4?

 

All help greatly appreciated.

RRE

 

Operating Systems:

Comments 9 CommentsJump to latest comment

pkh's picture

SLES 11 is only supported up till SP1, so there is no official solution for you

SOLUTION
RE_SYMANTEC's picture

Thank you for the clear statement of official support limits.

What if I move to Red Hat? Is the latest supported?

 

RRE

pkh's picture

You can check the SCL below to see whether the version that you want to upgrade to is supported

http://www.symantec.com/docs/TECH137682

RE_SYMANTEC's picture

Thanks for that - reasonable level of support for Red Hat but certainly does not cover the latest versions. I guess I need to look at another solution - the netbackup appliances do not seem to help because they do not provide me with tape...

 

Looking at alternative vendors, with regret.

 

RRE

pkh's picture

 the netbackup appliances do not seem to help because they do not provide me with tape...

You can attach a tape library/drive to the NBU appliance.

Laurie_Downey's picture

Have you seen this tech doc: http://www.symantec.com/docs/TECH201095

This may help point you in a direction.

Laurie Downey

Backup Exec

Advanced Tech Support

Symantec Corporation

www.symantec.com

 

 

Artegic's picture

Laurie, that Tech Doc article is wrong. I have already reported so in the feedback form as well as here.

  1. The referenced patch is a Linux kernel source patch. Only people building their own kernels can apply it. The OP is using a distribution kernel and has stated he or she needs vendor support, so that is not an option.
  2. The patch is already merged in kernel release 3.0 and later. Trying to apply it again will fail.
  3. As RALUS works on kernels not containing that patch, and crashes on kernels containing that patch, it is obvious that applying it cannot solve the problem. If anything, reverting it might help. But again, that is not an option for the vast majority of Linux users running distribution kernels, including the OP. (see 1.)
  4. Running a self-compiled kernel with that patch reverted would make RALUS work, but it would still be unsupported by Symantec.
  5. Reverting the patch doesn't address the real issue anyway: RALUS trying to use the non-existing Linux ioctl operation SIOCGIFCOUNT. It just reinstates RALUS' papering over the issue by changing the error code returned by ioctl from the documented value for this case back to what RALUS expects.

HTH,
Tilman

 

RE_SYMANTEC's picture

Tillman

 

Thanks for the comments - this is pretty much what I understood but you have made it much clearer.

I have looked at other options and I must say that I am tempted to have a shot at entering the land of hex - editing the code for ralus etc - if successful i would be able to continue with my centralised backup solution. 

Final question related - is there any Symantec solution that will allow me to backup to tape both windows and relatively recent LINUX boxes?

 

RRE

 

Artegic's picture

RRE,

to my knowledge Backup Exec is the only Symantec solution coming close. Its Linux support is limited to a few specific distributions still based on kernel release 2.6, of which the only still supported ones are Red Hat Enterprise Linux 5 and 6. Even for these two, Symantec does not support the latest patch levels, but as Red Hat stays with the same kernel release during the live of a major version, updating will not actually break Backup Exec on these systems. (It'll just kill your support from Symantec.)

Patching /opt/VRTSralus/bin/libbesocket.so as described in http://blog.redweb.at/2012/08/howto-backupexec-2012-linux-agent-and-kernel-3-0-debian/ does work (if done intelligently;) and allows you to back up Linux systems running on a 3.x kernel. (Of course it'll kill your Symantec support, too.) Although I cannot say I like that solution, we are currently using it out of necessity on a CentOS 6 system running a self-compiled 3.1 kernel, and it doesn't seem to have caused any trouble so far. (CentOS isn't supported by Symantec anyway even when running the distribution kernel because it isn't called Red Hat Enterprise, so it doesn't make any difference in that respect.)

HTH2,
Tilman

PS: Please forgive any sarcasm that may have leaked into the lines above. I try to suppress it but it's hard, and I am not a native English speaker.