Issue with Russian characters in file names

[mmatheny]

NetBackup 7.5.0.6, JAVA UNIX and Windows and Windows thick console all show same thing. Files were originally stored on Windows 2003 server, data was migrated to a NetApp CIFS. The filenames are correct in the filesystem. Backup server runs on Solaris.

We have files that have Russian characters in the filename, i.e. 56Р 19 августа14 ам послепуск.xls. When going to do a restore, the files are listed like this: H2TV30~1.xls

This makes restoring a specific file an all or nothing project. Any ideas? Only thing I have found in 4 days of Googling is someone on version 6.x said that they were told by Symantec that the Windows thick console will display the filenames correctly - well, in a word no - just finished installing and setting up the Windows thick console and they are still displayed the same. So either it is changing the name when it gets backed up, or is changing the name in the catalog. I there a way to search the catalog to see how it is actually stored?

[mph999]

What is the locale of the volume of the netapp where the files are stored ?

[mph999]

The local of the volume needs to be UTF-8

EG - to change vol locale

vol lang <volume name> en_US.UTF-8 

OK, yours won't be en_US, but whatever it is it needs to have UTF-8 tagged on the end, filer needs a reboot to take effect.

[mmatheny]

But they appear fine on the  file share from any Windows or Mac workstation. It seems to be NetBackup that is not interpreting the filename correctly. We do have a ticket open for this. I went back to when this file share was on a Server 2003 box, and the Russian file names did not back up correctly on it either, so it is NOT related to NetApp, as we see it on Windows Server 2003 as well.

[mnolan]

Hi, Is this actually being backed up via NDMP?

If so, I believe you already have a case open with support as I am aware of a similar case with a similar filename.

[mph999]

Yes, quite often they appear correct in windows etc,but NBU uses UTF-8 encoding and the volume locale must be set to <locale>.UTF-8

I have seen just about every combination of these errors, it looks right doesn't retore, it looks wrong (in GUI) but restores, it doesn;t look right and doesn't restore ...

Fair enough, NBU (esp Java GUI) has suffered issues, and that is one potential cause, but with UTF-8 set on the filers volume, you are also introducing an issue that can cause the same problem.

So, this has to be set, so we can see if it is causing the problem.  It's perfectly possible you have two issue causing the same symptoms, the UTF-8 on the filer volume (if it is not set already that is) and 'something else'.

Therefore you have to fix one we know about else you may never be able to find the other (if there is one) as the UTF-8 issue will be hiding it.

Therefore, set the UTF-8 on the filer, and leave this set until the problem is fixed (if that doesn't fix it) - then if you must, set it back later and see if that reintrouces the same, or a similar issue, but I wouldn;t recommend that as it's pretty much a condition that UTF-8 is set.

[mmatheny]

mnolan - yes, I do believe we have ticket open, just thought I'd ping the community for any cause/solutions

[mph999 · Accepted solution]

Could you confirm the local set on the filers volume.

Just because it may/ may not work in other operating systems, does not mean it will or will not work in NBU.

As I have mentioned, it's pretty much a requirement for filer voliumes to be UTF-8 , as that is what NBU uses.

I also explained that you could be unlucky and have multiple issues, the filer volume locale issue  + 'something else'.  Of course if you have two causes of the same symptom you have to fix both at the same time, else the problem would still be there - hence why if the volume is not set to UTF-8 it needs to be to make sure this is not part of the problem.

Or in other words, if UTF8 is not set on the filer volume any further trouble shooting for this issue 'could' be meaningless.

NBU doesn't change what goes into the catalog - it puts in what is sent from (in this case) the filer .

That is not to say NBU can't change it if something has gone wrong, but nothing like that springs to mind, whereas I can recall several issues related to locale, adn also issues on filers where they send incorrect information to NBU which gets written into the catalog.

cat_convert -dump <catalog.f file> will show the contants of what was written into the catalog.  The problem here is that the local of your machine you are virewing it on could affect the results, so try and do this on the master server itself.

[mph999]

The locales of the operating systems can also play a part in this issue, again, everything needs to be UTF-8 ...