Video Screencast Help

Wrong file- & directory names with Ralus 2010

Created: 27 Apr 2011 | 11 comments

Hello,

I have trouble with the backup/restore of an Linux based server. The server is running Debian Squeeze ( 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 GNU/Linux) with the newest Symantec Backup 2010 Linux Agent (ralus=4164.115.153090, mdm=MDM_v0.0.5071.HF11, vxms=VxMS_v4.4-036).

The Backup seems to run without problems. When I make the file selection, everything is ok and the filenames are displayed correctly.:

The job runs without errors. But when I want to restore files, the file- & directory names are corrupted:

The backup server is a Windows 2008 r2 machine with Backup Exec 2010 r2 an all updates/fixes.

Does anybody has an idea what the reason for this behaviour could be?

Thanks!

Volker
 

Comments 11 CommentsJump to latest comment

Sush...'s picture

Just checked the Software Compatibility List (SCL) and found that Debian Squeeze ( 2.6.32-5) is actually not supported with BE 2010 R2.

Correct me if I am wrong by rechecking the SCL from following link:

http://www.symantec.com/docs/TECH137682 : Backup Exec 2010|2010 R2 Software (SCL)

 

Thanks,

-Sush...

 

Hope this piece of Information Helps you... and if it does then mark this response as Solution....!!!

Volker Schillings's picture

Hello Sush...,

yes I know that. But maybe, someone has an idea what the reason could be. Hope will never die... ;-)

 

Bye,

Volker

Volker Schillings's picture

Hi Chris,

thank you for your reply. Unfortunately it did not help. I am wondering, why the selection for the backup job is fine and only the restore makes trouble...

bye,

Volker

avalanche's picture

I'm having the same problem on a Debian Squeeze machine, I'm guessing this has to do with the name encoding as the article suggests, only LATIN-1 isn't the "fix" for this anymore, the actual fix would be a proper autodetection mechanism in the agent, which an unset Encoder variable suggests. It would be nice if Symantec actually fixed this issue which has been around for ages.

I'll try to run backups without the Encoder set to LATIN-1.

If anyone have any other solution to this, please help :).

 

Best regards,

Andreas

avalanche's picture

Unsetting Encoder doesn't help at all, the only thing that happend is that non english characters are garbled. This is totally unacceptable, the backup software should not decide what os version it's customers run, i refuse to belive that this is a matter of os version, the filenames appear as normal when i browse them in a selection list, if it can get the names right in the selection list, why doesn't it get it right when running the actual backup?

Best regards,

Andreas

avalanche's picture

Please note that I run successful backups on two other Debian 6 machines, same filesystem and the same version of the linux/unix agent.

 

Also, does anybody even read this?

pkh's picture

An unsupported OS means that it has not been fully tested by Symantec.  If it works, you are lucky.  If it does not, you are on your own.

avalanche's picture

Thank you,
that was really helpful. As I wrote in a previous post, i do not belive that it's a matter of Debian versions, the selection lists all look normal. I'm running several Deb5 machines with the same kernel version as my Deb6 machines. The only difference then should be versions of some libs that really isn't used by the agent.

/andreas

stevaleelee's picture

Avalanche,

You have to understand that for a non-Unix/Linux admin the many different flavors of Linux using the 2.6 kernel are daunting.  The marriage of closed/open source is still an evolving concept and does pose hurdles to implementation.  I've so far been pleased with Symantec's willingness to at least "pick up the phone" with regards to unsupported installs.

The trick is to look at the installed packages on the Deb5 machines where it works and the Deb6 machines where it doesn't.  Just as you probably had to install some COMPAT libraries to even get RALUS to install you might need some more to make it work.  You can use ld to identify which libraries are used by the various RALUS commands.  If there are major revision differences in the versions of these libraries that could be a starting place for looking for COMPAT library packages that could provide the backwards compatibility necessary.  This might require some creative linking to get the linker to select the correct library at run time.

Once you get it to work ;-) clue me in since I'm seeing the same issue on my FC13 box running as my media agent.

I'm going to try and dig in on the encoding thing and see if that leads anywhere.

avalanche's picture

I've just closed a case with symantec support on this and there's no solution, however Deb6 support is on it's way but they couldn't tell me when and if it's going to be in a major release. A possible workaround would be to mount the storage share on a machine (which you also backup) that works and alter it's selection list to backup your mount, be sure to change the settings in the ralus conf as network filesystems are often excluded by default. I'll try to solve this more cleanly though.