Highlighted

Adding Linux VMs

How about adding Linux VMs Servers to Backup Exec 2014?

Don't know how can I add Centos 5.x and 6.x to Backup Exec 2014 V-Ray edition. Backup Exec gives error every time I try to add the Linux VM.

 

The server was unable to complete the requested operation

belinux_0.png

Any ideas how to create friendship between backup Exec 2014 and the Linux VMs?

Many Thanks

Syed Mazhar

1 Solution

Accepted Solutions
Highlighted
Accepted Solution!

BE 2014 doors not support any

BE 2014 doors not support any version of CentOS. See the SCL below. http://www.symantec.com/docs/TECH217478 In fact, CentOS is never supported by any version of BE

View solution in original post

19 Replies
Highlighted
Accepted Solution!

BE 2014 doors not support any

BE 2014 doors not support any version of CentOS. See the SCL below. http://www.symantec.com/docs/TECH217478 In fact, CentOS is never supported by any version of BE

View solution in original post

Highlighted

After creatign firewall rule

After creatign firewall rule on CentOS to accept traffic from BE2014 server, I managed to install the agent on CentOS release 5.11 (Final) , BE 2014 is backing up CentOS with following execption error:

Click an exception below to locate it in the job log

Backup- centos-vm

The remote computer is running a previous version of the Backup Exec Agent for Windows. You must upgrade the agent for Windows to enable secure communication between the agent and Backup Exec servers.

Backup- \\centos-vm\[ROOT]Unable to open the item \\centos-vm\[ROOT]/var/lib/mysql/ibdata1 - skipped.

Unable to open the item \\centos-vm\[ROOT]/var/lib/mysql/ib_logfile1 - skipped.

Unable to open the item \\centos-vm\[ROOT]/var/lib/mysql/ib_logfile0 - skipped.

Unable to open the item \\centos-vm\[ROOT]/var/log/nagios/nagios.pid - skipped.

Unable to open the item \\centos-vm\[ROOT]/var/run/sendmail.pid - skipped.

Unable to open the item \\centos-vm\[ROOT]/var/run/iscsiuio.pid - skipped.

Unable to open the item \\centos-vm\[ROOT]/var/run/atd.pid - skipped.

Unable to open the item \\centos-vm\[ROOT]/var/run/sm-client.pid - skipped.

Unable to open the item \\centos-vm\[ROOT]/var/run/iscsid.pid - skipped.

 

Any solution for this?

Many Thanks 

Syed Mazhar

Highlighted

Yes...it is unsupported as

Yes...it is unsupported as per pkh's comment. If you log a call with Symantec you'd probably get little, or no support.

You'd need to install a version of Linux compatible with BE 2014, or perhaps look at Netbackup or another product (assuming NBU also supports CentOS).

Thanks!

Highlighted

Unsupported means that BE is

Unsupported means that BE is not tested with the product, so you are on your own.
Highlighted

Hi, What a stumbling Block,

Hi,

What a stumbling Block, BTW who said Veeam isn't right choice for VMWare Backup? frown I am running Veeam on a side trial copy and it is perfectly copying all the VMs including CentOS without any hicc ups.

Would I still be able to restore the Linux / CentoS VM, regardless of those few files?

Thanks for all your help top guns.

Syed Mazhar

Highlighted

Try disabling OFO on the

Try disabling OFO on the Linux client machine. Edit ralus.cfg on the client and set Software\Symantec\Backup Exec for Windows\Backup Exec\Engine\RALUS\DisableOFO=1

Restart the RALUS service and the exceptions may stop from appearing.

Would I still be able to restore the Linux / CentoS VM, regardless of those few files?

Honestly, the best way to confirm this would be to run an actual restore. Though, per the exception, looks like you are backing up the CentOS VM as a physical machine (using the RALUS agent) and not through the vCenter/ESX host.

Highlighted

From the previous thread: For

From the previous thread:

For plain VM backups, you don't need to install the agent, just create a new NON-GRT backup job for that VM host and do an offline/full backup.

If you want to do a GRT-enabled backup, you will have to install the VM tools for the virtualization platform, then get agent for linux installed on the VM itself.

Highlighted

Backup youre linux VM's using

Backup youre linux VM's using aget for vmware & Hyper-v -create Backup Job From Esxi or Vcenter .

in my case its always work for centos.

Highlighted

CentOS is functionally

CentOS is functionally identical to RHEL of the same release number. It is true (although incomprehensible) that Symantec refuses to support it, but that should not be a reason for us as a community to follow their bad example.

Highlighted

...since when is this a bad

...since when is this a bad example? A lot of other vendors also don't support various applications and vendors.

However, pointing this out to the OP covers them too...telling them to simply follow through isn't sound advice. They're currently having issues with this now, and Symantec wouldn't be obliged to help them with a solution.

Putting it in as an Idea would be the only recourse...

Thanks!

Putting this in as an idea

Putting this in as an idea has already been done many times, in several variants, and achieved exactly nothing. One of these ideas (https://www-secure.symantec.com/connect/idea/support-ralus-centos) has been wrongly marked "Already Offered," and even requests to admit that it isn't are being ignored. The others are quietly collecting me-too dust.

While it's true that there are other vendors with comparably meager compatibility lists, I know of none going as far as not even making an effort to understand the problem before declaring "unsupported configuration, EOD". That's the bad example of paid Symantec support which we as a community shouldn't follow.

There are valid business scenarios for backing up a CentOS based Linux system with Backup Exec. (Though I admit a native Linux product like Bacula would probably be a better choice in most cases.) Backup Exec does not start to malfunction just because the Linux installation on the client is labeled CentOS instead of RHEL. The only difference is that Symantec support will hang up on you when seeing that label. OTOH there are many other reasons for Symantec support to refuse support for Linux installations. Installing the latest patches is just one of them. So even running RHEL instead of CentOS will not be the end of your woes.

Of course anyone is free to repeat "CentOS is not supported" at nauseam every time CentOS is mentioned, but please stop pretending that using CentOS is a possible cause of malfunctions or that replacing CentOS by RHEL will fix anything.

Highlighted

What do you think is involved

What do you think is involved so that a product is supported? Are you 100% sure that CentOS is 100% identical to RHEL?
Highlighted

...replied to that, as 1 of

...replied to that, as 1 of the "certain forum participants" who constantly tells people that software/hardware not on the SCL/HCL isn't supported.

Thanks!

Highlighted

What do you think is involved

What do you think is involved so that a product is supported?

Basically the ability and willingness to listen to the customer.

Are you 100% sure that CentOS is 100% identical to RHEL?

That question does not make any sense. No RHEL system is 100% identical to any other to begin with.

Highlighted

If support is just listening

If support is just listening to customers, why are you constantly complaining about lack of progress. Precisely. Since each version of RHEL and CentOS are different, does anybody had the resources to test each of them? At some point, you got to stop testing and without testing something you cannot support it
Highlighted

Precisely. Since each version

Precisely. Since each version of RHEL and CentOS are different, does anybody had the resources to test each of them?

You misread my reply. Not just each version, but each installation of RHEL is different. More precisely, the differences between two RHEL installations of the same release number can be much bigger than those between a CentOS and RHEL installation of the same release number. Differences between releases dwarf both.

At some point, you got to stop testing and without testing something you cannot support it.

Not true.

  1. You cannot test all possible configurations even for a precise single OS version and patchlevel, period. If that was a precondition for support, support would not exist.
  2. You can work with a customer to identify possible sources of a problem even if you haven't previously tested the precise configuration which that customer is running. That's what support people do all the time. BTDTGTTS.
  3. You have to draw a line somewhere as to what you do or do not want to support, but it doesn't have to be as narrow as Symantec makes it. You do not have to hang up on your customer as soon as he or she mentions something you cannot find on your compatibility list. You can very well have a look first to see if that unsupported item actually has any influence on the issue.
  4. You can work with a customer to isolate a problem he or she has with your product even if he or she has installed an OS update you haven't tested yet. In fact it is in your best interests to do so. Either the problem is caused by the update in which case you're better off knowing about it as soon as possible, or it isn't, in which case the customer would be rightly annoyed if you refuse fixing it just because that update happens to be installed.
  5. You can work with a customer to isolate a problem he or she has with your product even if he or she has installed a variant of the OS you're not familiar with. In fact Symantec support people do so regularly when confronted with my German language Windows installation. The differences between German and English Windows installations are way bigger than those between CentOS and RHEL, yet no Symantec support engineer has ever hung up on me because my Windows is German.
Highlighted

...then you need to raise

...then you need to raise this directly with Symantec if you're getting no joy on the forums. There is only so much forumites can do, and being 1 of those individuals who always quotes the SCL/HCL (you need to understand why we do so!), you'll always get that quote.

Symantec themselves should be able to help you further.

Thanks!

Highlighted

You cannot be sure that

You cannot be sure that CentOS is exactly the same as RHEL. It is also obvious that most vendors don't support all operating systems, you have to stop somewhere.

Symantec tests their products and supports them on the platforms they tested, seems logical to me...

It's true what you say that replacing CentOS with RHEL will not fix your problem (it will amaze me if it did) but Symantec will not support it until they have tested it.

It is the same as any other configuration that is unsupported by Symantec, it's just that CentOS "should" be a binary clone that this specific case is difficult to understand.

My company only uses CentOS on test environments and not in production...

Highlighted

Your are mixing support of

Your are mixing support of software fixes and CentOS. They are two different things. You say that support should look at problems with CentOS and see whether the problem is caused by using CentOS. How is he going to do this and at what level should he stop?