10-06-2014 09:20 AM
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
Any ideas how to create friendship between backup Exec 2014 and the Linux VMs?
Many Thanks
Syed Mazhar
Solved! Go to Solution.
10-06-2014 09:21 AM
10-06-2014 09:21 AM
10-07-2014 08:04 AM
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
10-07-2014 08:12 AM
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!
10-07-2014 08:16 AM
10-07-2014 09:12 AM
Hi,
What a stumbling Block, BTW who said Veeam isn't right choice for VMWare Backup? 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
10-07-2014 07:54 PM
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.
10-08-2014 07:33 AM
10-10-2014 11:10 AM
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.
10-14-2014 06:51 AM
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.
10-14-2014 07:03 AM
...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!
10-22-2014 06:28 AM
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.
10-22-2014 07:39 AM
10-22-2014 11:07 AM
...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!
10-27-2014 02:10 AM
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.
10-27-2014 02:57 AM
10-27-2014 05:15 AM
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.
10-27-2014 05:18 AM
...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!
10-27-2014 06:47 AM
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...
10-27-2014 07:21 AM
From the previous thread: