Share catalogs between PC and Mac servers

[NTmatter]

Greetings!

 

Background:

I'm in the middle of trying to set up a Disk-to-Disk-to-Tape (D2D2T) backup strategy that involves two instances of Retrospect Server running on Windows and Mac using shared network storage and a single tape drive. Both Windows and Mac RS servers need to write to the network share, and the Mac controls the tape drive.

 

Problem:

I've hit a snag when trying to share the Disk-based media between with both machines.

 

I can share the disk-based backups and catalogs between the two servers by manually updating the path to the media set every time a backup runs. I haven't found a way to to make the change automatically, mangle paths, or even to have Retrospect use a relative path to identify the media set's members.

 

Has anybody got any workarounds for this kind of setup?

<p>

Constraints:

• Retrospect Server for Windows is required for Exchange Mailbox backup
  
• Retrospect Server for Mac OSX is required for fast Xsan backup and tape loader
  
• Network share as disk-based media set in Disk-to-Disk-to-Tape (D2D2T) workflow
  
• Separate network share for catalogs
  
• Backups must be fully unattended, as humans will not be on-site at 2am
  

Approaches Already Tried:

Some other odds and ends I've tried along the way

• Retrospect 10's WebDAV support: The catalog still contains the platform's native representation of the WebDAV path. For the Mac, this is still a local path in /Volumes.
  
• Tricks with OSX's mount command to fake a local windows path or UNC path: Forward slashes and backslashes are a bit too incompatible to work with.
  
• Switching to a single server: Not possible as a Windows server is needed for backing up Exchange mailboxes. A Mac server is required for Xsan connectivity and Tape loader -- backups are far too slow when run through the Retrospect Client.
  
• Manually editing the uncompressed .rbc file with a hex editor: The .rtS chunk has a 4-byte constant (0x00011001) followed by a 16-byte value specifying how many two-byte characters are in the string (UTF-16?), ending with zero-padded to the next multiple of 4 bytes. Running a homebrew length-altering binary search and replace seems somehow unsafe, despite the entertainment value of doing so
  

Further thoughts would be appreciated!

[NTmatter]

A bit late, but I've stumbled upon a reasonable workaround: File-based backup shared on an SMB fileshare with Samba.

 

As a bit of a background, the "system-specific paths in the catalog" problem is solved by the File-based backup as the backup catalog is embedded directly in the RBF.

 

Samba (specifically SMB) is used to provide cross-platform shared storage for the RBF files. The SMB share could probably be handled with a regular Windows or Mac box, however the storage server just happens to be FreeBSD. It might also be possible to use some other platform such as NFS, however that's a whole bunch of other experimentation and security to take care of.

 

For anyone interested, or who may be running into a similar problem, there were also several earlier attempts at using SMB/Samba to provide access to the Windows server and AFP/Netatalk to provide access to the Mac server. This generally met with failure due to File Locking issues between Samba and Netatalk. Once both Retrospect servers had attempted to access the media set, one of the systems would report that the media set was corrupt or inaccessible. Making a copy of the file on the storage box would render the backup set accessible again, however this would be a rather slow and error-prone task.