01-06-2011 02:30 PM
I'm running BE 2010 (2896) on a Win2k8 Std server. I've installed RALUS (same version) on a 64-bit Ubuntu 10.04 server, and I can see that server in the BE resource list under Favorite Resources / Linux/Unix Servers. I'm authenticating as root with the correct password, but when I expand the server in the selection list, the only resource I see below it is [ROOT].
I've double-checked that the installation process created the beoper group with root as a member, but I'm not surewhat to check next.
Any and all suggestions welcome. Thanks.
Solved! Go to Solution.
01-14-2011 07:51 AM
I'm going to mark this as solved, since I've identified the cause of the problem.
The simplest way to avoid this problem in the first place is to format your drives as ext3. You will miss out on the performance gains of ext4, but BE will be able to back up your data.
If you're already well along the path of ext4 then you're SOL; converting an existing file system back from ext4 to ext3 is non-trivial and outside the scope of this discussion.
Hopefully one day Symantec will update RALUS to handle a file system that's been around for over a year now, but in the meantime, avoid ext4 if you want to be able to back up.
01-06-2011 04:41 PM
Hi Jon,
With BE 2010 Ubuntu 10.04 version is not supported for same you can refer Software Compatibility List (SCL)
http://www.symantec.com/docs/TECH137682
But still you can try few steps to give a try
1 Are you able to telnet & verify beremote is using port 10000 & there should not be any other service using this port for same use the smae cmommand to confirm
Netstat –apn |grep 10000
& then may be try to stop & start service to check
/etc/init.d/VRTSralus.init start
/etc/init.d/VRTSralus.init stop
2 Also it might be an issue with firewall
Thank You
01-08-2011 04:27 AM
Hi ,
Any updates on same
Thank You
01-10-2011 11:33 AM
Thanks for the suggestions. I have confirmed that the process is running and listening on port 10000 on both IPv4 and IPV6. I did move Webmin off of that port before I installed RALUS. I've also tried disabling the firewall, to no avail. Furthermore, I've confirmed that the same behavior exists with BE 2010 R2 (4164) and its RALUS agent, too.
01-10-2011 05:32 PM
As it has been noted earlier, Ubuntu 10.04 is not supported by BE. This means that even if you managed to back the system up, there is no guarantee that the backup can be used to restore the system and you would not be able to open a support with this configuration with Symantec Tech Support. Basically, you are on your own.
01-10-2011 05:39 PM
Hi
Thanks for your response & when you suggested you have noticed same behaviour with BE 2010 r2 in that case have you unisntalled & reinstalled the remote agent for BE 2010 r2 on ubuntu
Also you can try debuging the beremote to see what exactly is going & upload it here this is the command you can use ./beremote –-log-console
Also please click on link below to see if that helps
http://www.symantec.com/docs/TECH62696
So after this if it still doesnot work as mention above then as mention above as it is not supported & not tested by backupexec should not work
Thank You
01-13-2011 04:43 PM
Thanks for your update & great to see beremote log helped you. do close the post finally when the issue is resolved
Thank You
01-13-2011 06:56 PM
ext4! Looking at the beremote log (thanks for that suggestion) showed that DLE was failing to mount my root partition, and I wondered if that might have been caused by the ext4 format which became the default for Ubuntu from 9.10 onwards.
To confirm my hunch, I installed a duplicate 10.10 instance and manually formatted the root partition as ext3, installed RALUS, and sure enough I could see (and back up) the entire file system. I then converted the fs to ext4 and tried to access it again, and sure enough I could not see past [ROOT] just like my original problem.
While migrating from etx3 to ext4 is fairly trivial, the reverse is not. So now to figure out a way to offload my ext4 root volume to another drive, reformat as ext3, and copy it all back again. Fun times.
01-14-2011 07:51 AM
I'm going to mark this as solved, since I've identified the cause of the problem.
The simplest way to avoid this problem in the first place is to format your drives as ext3. You will miss out on the performance gains of ext4, but BE will be able to back up your data.
If you're already well along the path of ext4 then you're SOL; converting an existing file system back from ext4 to ext3 is non-trivial and outside the scope of this discussion.
Hopefully one day Symantec will update RALUS to handle a file system that's been around for over a year now, but in the meantime, avoid ext4 if you want to be able to back up.
01-18-2011 12:33 PM
I just resolved this issue with some Solaris clients, and the problem turned out to be stale NFS mounts that caused the client daemon to choke while contstructing the directory/file tree to be listed under the [ROOT] node in the Backup Selection List interface. Once it hits that mount point it aborts and returns a null/empty list to the server, I'm assuming.