Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Backup Exec 2012 Remote Agent for Linux does not support CentOS??

Created: 23 Dec 2013 • Updated: 02 Jan 2014 | 14 comments
This issue has been solved. See solution.

We bought Backup Exec 2012 for backing up a heterogeneous environment of Windows and Linux servers.

On one Linux target machine running CentOS 6.5 the Remote Agent for Linux systematically crashes each time we try to start it. As our own attempts to identify the problem hit a wall, we called Symantec support. However, the engineer refused to help us, claiming that CentOS was not supported.

Is that true? Symantec claims Linux support but excludes CentOS??

Operating Systems:

Comments 14 CommentsJump to latest comment

ZeRoC00L's picture

Check the SCL (Software Compatability List) if CentOS is listed.

http://www.symantec.com/business/support/index?pag...

If this response answers your concern, please mark it as a "solution"

Artegic's picture

The SCL lists, in it's "Red Hat" section, "Enterprise Linux 6.0" with Service Pack "Update 2".

As there is no such thing as a Service Pack named "Update 2", I take that to mean Red Hat Enterprise Linux release 6.2.

Is it possible that Symantec support doesn't know CentOS is the same as Red Hat Enterprise Linux?

Or does Symantec require customers to run an out-dated OS release in order to receive support?

pkh's picture

Unsupported means that Symantec does not test the OS. CentOS is not listed in the SCL so it is not supported and not tested

Artegic's picture

The support engineer we contacted doesn't seem to agree with you. To him, unsupported obviously doesn't just mean untested, but the right to refuse any help in case of a problem.

pkh's picture

the right to refuse any help in case of a problem.

Isn't this the meaning of unsupported.

Artegic's picture

That's what I thought, until you wrote that it only meant untested.

pkh's picture

I wrote, "....is not supported and not tested"

Artegic's picture

Ok, so you seem to say: Symantec support only offers help with the exact OS releases Symantec has previously tested itself and which appear literally on the SCL. Which appears to imply these answers to my questions:

- Symantec support may or may not know that CentOS is the same as RHEL but wouldn't care anyway. It isn't listed verbatim in the SCL so they won't touch any case where it is involved.

- If we switch to "official" Red Hat Enterprise Linux 6 instead, Symantec will indeed require us to stay at outdated update level 6.2 in order to receive support.

Is that correct? Do similar statements hold for Windows clients too? Ie. must I wait for a support statement from Symantec before installing a Microsoft service pack?

Thanks,

Tilman

ZeRoC00L's picture

Yes, this also applies to Windows clients. Service Packs are also listed in the SCL.

If this response answers your concern, please mark it as a "solution"

SOLUTION
Artegic's picture

Ok, thanks for enlightening me. Time to start looking for an alternative backup product I guess. sad

pkh's picture

BE's support policy is no more different than any other software. A vendor can only support what they have tested with their product. If you do find an alternative backup product which support software/hardware that the vendor has not tested do let us know. I will avoid this product

Artegic's picture

We obviously have different concepts of support.

For me, supporting platform X means: if a customer running my product on platform X encounters a problem then I will work actively with him to

  1. isolate the cause of the problem
  2. if the cause turns out to lie within my product, including an incompatibility with platform X, fix it
  3. if the problem is caused by an error the customer made, point out the fix to him
  4. if it is caused by a flaw in the platform, try to conceive a workaround for my product to work around that flaw. (Although this is delicate because a successful workaround will often been mistaken for a fix, leading to misattribution of blame.)

None of this requires that I have tested my product on the exact version and patchlevel of platform X the customer runs. In fact, experience shows that frequently the platform or at least its version level will not even matter, so refusing support upfront on the mere notice that the customer is running a later version of platform X than the last one I have tested turns out to be counterproductive.

You and Symantec see that differently. Discussing that here is probably moot. So I will leave it at that. I have all information I need to make the necessary decisions, whatever they'll finally be. It will take time, anyway, so prepare to see more of me here in the meantime. wink

As for your last sentence, I assume it is inappropriate to discuss alternative products in this forum. cheeky

Thanks for all the effort you put into this discussion. I really appreciate it.

Tilman

pkh's picture

if the cause turns out to lie within my product, including an incompatibility with platform X, fix it

How do you determine this without testing the product with the platform?

Artegic's picture

How do you determine this without testing the product with the platform?

Working with the customer has proved pretty successful for me in the past.