infinitesunrise

It is indeed the server version of OS X, drat. The licensing options were a bit confusing, but looking over them all it makes sense to me now and it's clear that I have a more limited version of Retrospect. The HFS+ driver sounds like a good bet, I'll give that a shot. Thanks for the help from both of you!

Sorry for the ambiguity. Yes, Retrospect is on Windows. We're a nearly all-Mac studio and I'm a Mac native but I always opt for Windows when using Retrospect because I'm not at all a fan of the Mac version. I've had lots of issues with it in the past, due to both the hardware difficulties you mentioned and bugginess in the Mac version of Retrospect when dealing with larger catalogs. The Windows version seems to run much faster and the interface is more straightforward to me, so I prefer to build a dedicated Windows machine for Retrospect LTO backups regardless of environment. Regarding trying to make the Mac a backup client instead of going over SMB, at this point I would like to try that. When we purchased Retrospect our license was for "Retrospect Desktop with 5 Workstation Clients", and sure enough when I click Licenses within Retrospect I see a 5-pack listed under Backup Clients, with '0 used, 5 available' under Status. I installed the Retrospect client on the Mac and it's running, and I can see the Mac when I go to add a new Retrospect client in Windows. But when I click 'add', Retrospect says 'Additional license required' and asks for one. But, I was only even given a single license so I don't know what's going on with that. If that's in error and can be resolved then I'd gladly go that route, but otherwise I don't think we'd have the budget for further licenses. Found the logs but they didn't elucidate much, the asserts log looks like a stack trace and doesn't say much, no clues in the ops log and nothing within that time frame in Windows event logs

Some background: I've got about a hundred HFS+ formatted external hard drives full of data that I'm transferring to LTO6 one at a time by attaching them to our OS X Yosemite server and sharing them all out under the same SMB share name ('Archive'). On the Retrospect side in Windows (Desktop v 10.0.2.119), I have an incremental backup script that pulls everything from the 'Archive' share. So I plug in a drive on OS X, share it out via SMB as 'Archive', back it up over the LAN with the script in Retrospect, unshare it, unplug it, and repeat with a new drive so that everything backed up all shows up under 'Archive' in the catalog. But I've been running into this error that crashes Retrospect completely, over and over again. The first drive I backed up was an 8TB and the backup got through about 7.5TB just fine. But on the last 300GB or so it kept seemingly running into files that would trip it up. It would throw up the error message 'Retrospect has encountered a serious error: Assertion failure at "elem.cpp-1145"; A log of this error has been written to the file "assert_log.utx".' I noticed that it always seemed to trip up on a large sequence of images that was on the drive, a different image file every time. I eventually zipped the entire folder of images on the drive, Retrospect had no problem chugging through the zip file, and the backup finished. I'm now on the second drive and it's happening again, but this time it looks like Retrospect's window disappears completely behind the error message, so I can't tell what file it hangs up on. Doesn't look like I have any choice but to just run the backup again, which means Retrospect has to spend hours figuring out which of the 2TB of files it's already backed up (I guess because the catalog file doesn't save correctly when it crashes?), and then it crashes the same way once it's a decent way through the new attempt at the backup. Obviously I cannot continue this way. I have literally hundreds of drives to work through and I was already expecting this to take a year or so. I absolutley have to find out why Retrospect is crashing, or I'm not going to be able to move all these archives off their hard drives. I don't know where the "assert_log.utx" that the error message mentions is located, otherwise I'd take a look at that for clues. I see that in the release notes of v 9.0.1.011 last year a mention that it fixes the "elem.cpp-1145" assertion failure I'm getting, but here I am running the latest version still getting it. Does anyone know what this means? Can anyone suggest any way to fix it? Thanks in advance for any guidance.

Thank you! That's a ton of good advice, the pointer to Parted Magic in particular. I'll go ahead and pause the backup and reboot the server. If that breaks the backup I'll restart it as an incremental and see if it recognizes what it's already backed up. If not, it'll be worth the time saved to see if Parted Magic can recognize the volume and put the Linux Retro Client on that instead. edit - Success! The backup continued after server reboot, uninturrupted.

I would have loved to install the Linux retro client on the SMB server, but when I said "poorly-configured Linux box", I really meant it. Its a 36-drive SuperMicro server similar to this one with an LSI MegaRAID card controlling 3 internal 14TB RAIDs. The operating system is Openfiler Linux (a now-defunct headless NAS OS controlled via web interface) running on a 1GB (!!!) partition, which joins the three 14TB RAIDs into a weird 44TB proprietary software SAN volume with an XFS filesystem. SAMBA can't even be configured correctly via the web gui for retrospect to connect to it, so I've had to manually create the correct configuration files via SSH to get it to connect at all. The Retrospect Client for Linux will absolutely not install because Openfiler Linux is an exotic "appliance" style OS that lacks or is incompatible with several libraries that the Retro client requires. I've tried, and determined that manually-configured SAMBA was the only way to go. I even tried booting the system with a Windows disk, but although Windows could see the 14TB volumes it couldn't re-construct the strange software SAN. This system was created years ago by a predecessor, and I've been charged with getting all the data on it to LTO tape. It's a one-off operation, and after it's finished we'll be getting rid of the Linux sytem completely, good riddance. The fact that it's supposed to be a one-off is why incremental backup was disabled. We have a catalog of "job archives" that it's going to, most of which are backed up from a different location. Since this would be the only backup coming from this alternate source on the catalog, I figured I'd keep it simple by turning off incrementals. Probably would have helped me to leave it on though, yeah? So basically I just need to know: If I pause the execution to reboot the file server, does it break my transfer even though it's paused? Or, alternatatively: If I kill this backup right now at the halfway point, and restart a new one incrementally, will it recognize the stuff I've already backed up and skipped it, even though it wasn't backed up incrementally?

Quick question: I'm doing a very large (26TB) backup from an SMB file server to LTO6 tape. Incremental backup is turned off. The SMB server is an old, poorly-configured Linux box and transfer speed has crawled almost to a halt about halfway through execution. I know that rebooting the SMB server should get it working at speed again, but I don't know if this is possible to do mid-backup without losing everything I've done up to this point. If I pause the execution, reboot the SMB server and then continue the execution once it comes back up, will it keep going from where it left off? Or will this sever the connection between Retrospect and the SMB server, destroying my progress? Thanks. Any related tips also appreciated.