Search the Community
Showing results for tags 'cross-platform'.
Found 1 result
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!