XSAN, Veritas netbackup and disappearing ._ resource fork files

[dgb900]

I am doing some testing of backups of XSAN volumes (using Veritas Netbackup). I am running XSAN 1.4.1 on MacOSX 10.4.9

I found that doing a full restore of a directory tree was losing the ._ files that represented resource forks. The particular application we are using embeds metadata into the resource fork of a file, and on XSAN this gets created as a separate file with the prefix ._ followed by the file name (e.g. file ‘abc’ has resource fork ‘._abc’).

More investigation revealed that some files still had their ._ resource forks. In particular, files with names starting with ‘+’.

More testing today has discovered the cause:
On XSAN, if I rename a file, and if it has a ._ resource fork that gets renamed too. So far so good, although this isn’t exactly standard behaviour! If there is already a ._ file of the target name, that is DELETED whether the file has a ._ resource fork or not – in effect an absent resource fork overwrites the ._ file – probably to avoid a bogus resource fork becoming attached.

See below:

[code]
xs04:/Volumes/XSAN admin$ ls -al
total 65568
drwxr-xr-x 2 admin ingestgr 2048 Feb 16 17:59 .
drwxrwx— 51 admin ingestgr 12288 May 21 16:18 ..
xs04:/Volumes/XSAN admin$ touch ._a
xs04:/Volumes/XSAN admin$ touch b
xs04:/Volumes/XSAN admin$ ls -al
total 65568
drwxr-xr-x 4 admin ingestgr 2048 May 21 16:57 .
drwxrwx— 51 admin ingestgr 12288 May 21 16:18 ..
-rw-r–r– 1 admin ingestgr 0 May 21 16:57 ._a
-rw-r–r– 1 admin ingestgr 0 May 21 16:57 b
xs04:/Volumes/XSAN admin$ mv b a
xs04:/Volumes/XSAN admin$ ls -al
total 65568
drwxr-xr-x 3 admin ingestgr 2048 May 21 16:57 .
drwxrwx— 51 admin ingestgr 12288 May 21 16:18 ..
-rw-r–r– 1 admin ingestgr 0 May 21 16:57 a
[/code]

This is not the behaviour on an HFS+ filesystem.

With my restore, the files were being created in a temporary directory and then moved into the target directory. The files starting with “+” were backed up before the ._ files and then the regular files. Thus the regular + files were created followed by their ._ resource fork, but for other cases the ._ resource fork would be created and then shortly afterwards obliterated as the regular file is moved into place.

Has anyone else encountered this problem and found a workaround?

Thanks, David.

[maxroper318]

We have encountered these same issues with backing up Xsan volumes using all Veritas products. One workaround was to backup over SMB rather than using the built-in Veritas software, but we still ended up seeing similar issues, especially with Quark files. As a Symantec partner, we contacted support and Symantec claimed not to support Xsan.

Just an FYI,

Max Roper
Technology Consultant

318, Inc. | Technology :: Solutions :: Consulting
http://www.318.com • mailto:[email protected]
(310) 581-9500 voice • (310) 581-9515 fax
:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:
http://directory.microsoft.com/MPRD/support/AboutPartners.htm
http://train.apple.com/news/success/three18.html

[Author]

Posts