Xaqtly Posted April 6, 2009 Report Share Posted April 6, 2009 We recently upgraded to Retrospect 8 and I ran our first full backup using it on Friday. To my dismay, I came in this morning to find out that it hadn't finished because it ran out of media. We've got about 5.5TB of data on our server currently, and we're using 800/1.6TB DLT tapes to back up to. Previously, using Retrospect Workstation 6.1, it only took 4 tapes to back up that much data. Now it takes 6. I verified that it is using hardware compression, the problem is Retrospect is not filling the tapes up before moving to the next tape. Looking at the media sets, Retrospect appears to only be putting about 1TB of data on each tape before moving to the next one. Out of the 6 tapes in the set, each one only has between 1 and 1.1TB on it, with 400-500GB free on each one. Frankly, WTF? This exact setup worked fine in Retrospect 6.1, and it filled each tape all the way up before moving to the next one. It's basically wasting 500GB per tape. Oh and for some reason, Retrospect refuses to go to the next tape if it's not actually erased. If you just take a tape out of the box and pop it in, Retrospect won't back up to it. Since realizing that, I checked the "Minimal Erase Confirmation" box in preferences, but we're not talking about tapes with data on them - these are blank tapes that just haven't been "erased" yet. Can anybody help with these issues? The fact that Retrospect is only using 2/3s of the available space per tape is really obnoxious, these things are expensive. Thanks. Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted April 6, 2009 Report Share Posted April 6, 2009 Retrospect is not filling the tapes up before moving to the next tape. Looking at the media sets, Retrospect appears to only be putting about 1TB of data on each tape before moving to the next one. Out of the 6 tapes in the set, each one only has between 1 and 1.1TB on it, with 400-500GB free on each one. Just because only 1TB is being written doesn't mean that there are meters of unused tape in the spool. It's also possible that compression isn't working as it should, so even though each tape gets to the end, there's just not as much data being written. How about some information about your hardware configuration? Dave Quote Link to comment Share on other sites More sharing options...
rhwalker Posted April 6, 2009 Report Share Posted April 6, 2009 Retrospect 8 is known to have serious (non) performance issues. Modern tape drives will adjust (lengthen) the inter-block gap if data is not being supplied fast enough so that the tape doesn't have to "backhitch" after each block, because such rewinding after each block will cause excessive tape wear and will drastically slow down the tape speed. I suspect that the capacity would increase if the program could keep up with the tape drive. Quote Link to comment Share on other sites More sharing options...
Xaqtly Posted April 7, 2009 Author Report Share Posted April 7, 2009 Just because only 1TB is being written doesn't mean that there are meters of unused tape in the spool. It's also possible that compression isn't working as it should, so even though each tape gets to the end, there's just not as much data being written. How about some information about your hardware configuration? Dave Here you go: Server: Apple XServe, 3.0 GHz dual quad core Xeon, 16GB RAM Drive being backed up: JetStor 642F 42TB RAID, connected to the XServe via Fibre Channel Backup unit: Overland ArcVault 48, 48-bay LTO-4 drive (mechanically an HP Ultrium Gen 4 DC) connected to the XServe via SCSI 320. The main thing is that as I mentioned, this setup worked great with Retrospect 6.1. The only thing that's changed is the version of Retrospect. Retrospect is saying that each member of my backup set (each tape) is 1562.8 GB, and that each one has about 1TB on it, and 500GB free. So it understands on some level that these are 1.6TB tapes with hardware compression. I should note that I don't have the software compression box turned on, since the backup unit does hardware compression. The fact that each tape has 1TB on it (and not 800GB) seems to indicate that compression is working at least to some degree. The Media Set summary does indicate that hardware compression is being used. Let me know if you have any ideas. Thanks. Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted April 7, 2009 Report Share Posted April 7, 2009 Happily Russ is participating in the thread. He understands tape systems better then anyone else likely to comment here. But I think Retrospect doesn't/can't know how much free "space" is actually on a tape. It's not like a hard drive that way. But not having a tape drive myself, and seeing that the Details section of the Details pane has a "Space Free" field, perhaps there's something I'm missing. Time for popcorn. Quote Link to comment Share on other sites More sharing options...
Xaqtly Posted April 7, 2009 Author Report Share Posted April 7, 2009 Here's a screenshot, in case it helps. Quote Link to comment Share on other sites More sharing options...
Xaqtly Posted April 7, 2009 Author Report Share Posted April 7, 2009 (edited) double post, sorry about that. Edited April 7, 2009 by Guest Quote Link to comment Share on other sites More sharing options...
Mayoff Posted April 7, 2009 Report Share Posted April 7, 2009 (edited) Retrospect will write data to the tape until the hardware tells Retrospect the tape is full. Your screenshot shows almost the same amount written to each tape, which means the hardware is probably writing correctly. Random capacity usually would mean device communication trouble. The remaining space displayed is based on an estimated capacity for display purposes only. Part of the problem is that 8.0 does not appear to have an option to change the estimated capacity like older versions. I will write a bug for that. See http://kb.dantz.com/article.asp?article=5658&p=2 Edited April 7, 2009 by Guest Quote Link to comment Share on other sites More sharing options...
Xaqtly Posted April 7, 2009 Author Report Share Posted April 7, 2009 It's writing correctly, but it's not writing the correct amount. Those numbers may be estimated, but they are correct, which is why it took 6 tapes to back up 5.5TB instead of 4. I'm not sure I fully understand your assessment of the problem. Will the ability to change the estimated capacity allow Retrospect to use all 1.6TB of the tapes instead of the 1TB it's using now? All I know for sure is that Retrospect is moving to the next tape when it hits 1TB, and it didn't do that with Retrospect 6.1. Nothing in my setup has changed except for the version of Retrospect. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted April 7, 2009 Report Share Posted April 7, 2009 Retrospect is writing data to the tape until your hardware has reported the tape is full. Try creating a new media set with hardware compression turned off. How much data gets written to the tape? Retrospect has no control over the total amount written to the tape, this is controlled 100% by the hardware. The capacity is an estimate for display purposes only and has no impact on actual capacity. Quote Link to comment Share on other sites More sharing options...
Maser Posted April 7, 2009 Report Share Posted April 7, 2009 Maybe the compression algorithm has changed? If you have have one extra tape, it would be interesting if you could try backing up a specific folder that has 2-3G of data in it -- once with Retrospect 6.1 and once with Retrospect 8 -- using the same exact tape. And see what both report when that *same tape* fills up. Both versions of the app back up alphabetically, so you should be able to see exactly where both versions stop. And maybe set both 6.1 and 8.0 not to do *any* encryption so you get the most throughput as possible? If I had a tape device here, I'd try that... Quote Link to comment Share on other sites More sharing options...
rhwalker Posted April 7, 2009 Report Share Posted April 7, 2009 Maybe the compression algorithm has changed? unlikely because hardware compression is being used: I verified that it is using hardware compression... Retrospect is saying that each member of my backup set (each tape) is 1562.8 GB, and that each one has about 1TB on it, and 500GB free. So it understands on some level that these are 1.6TB tapes with hardware compression. LTO4 tapes are 800/1600 GB (uncompressed/compressed) so we know that compression is in play. While possible, it's unlikely that Retrospect 8 is reporting that it is using hardware compression but is really doing software compression (it would be possible that Retrospect 8 is reporting hardware compression but didn't send the right bits to cause that to happen, but we see compression). It's also possible that Retrospect 8 is using tiny blocks rather than the size blocks used by Retrospect 6.1, but that's unlikely. Trust me. The inter-block gaps are being lengthened by the drive because the throughput is too low. If the blocks are being spaced apart, then you get fewer blocks on the tape. It's that simple. I spent enough time optimizing unix tape drivers years ago to get the throughput up. The one piece of information that hasn't been provided is the type of SCSI HBA being used. The problems we had with our Apple Dual-Channel SCSI card (really an LSI Logic 22320 Dual-Channel SCSI card) that is the BTO option with Xserves didn't involve throughput issues, but we scrapped the card in favor of an ATTO card before we got to the point where performance could even become an issue. The LSI Logic 22320 is a PCI-X card, which means that it would have to be on a PCIe converter/riser card in the Xserve Xeon, which could be causing throughput issues, but those same throughput issues would have been seen on the same hardware running Retrospect 6.1. While a PCIe SCSI HBA could have faster throughput than a PCI-X SCSI HBA, I don't think that this is the issue because throughput problems aren't being seen on the same hardware running Retrospect 6.1. In fact, if only hardware issues were in play, Retrospect 8 (Cocoa native Intel code) should be faster than Retrospect 6.1 (Carbon on Rosetta). One way to tell, if you are willing to sacrifice a backup written to a new tape (would need to be a tape never written by Retrospect 6.1) would be to do the backup on that tape, wait for EOT to cause a media request, then tear open the LTO 4 tape cartridge, see how far it wrote on the spool (even when the tape rewinds, you can see a slight difference in the rewind pattern on a new tape that will tell you how far the writing went on the virgin tape reel). If the rewind pattern shows that the writing went all the way to the end of the spool, rather than only 2/3 of the way as your results might indicate, then this is a clear indication that it's caused by data starvation of the tape drive (failure to keep the pump primed), which is causing the tape drive to lengthen the inter-block gap. That won't be fixed until the performance of Retrospect 8 is increased. Trust me on this. Russ Quote Link to comment Share on other sites More sharing options...
Xaqtly Posted April 7, 2009 Author Report Share Posted April 7, 2009 Looks like there are a lot of possible variables here, but Russ is correct when he says that if it were throughput problems with the hardware, I would have seen those problems in Retrospect 6.1 as well. The fact remains that everything worked perfectly in Retrospect 6.1, and the only thing I've changed is the software. That's it. Logic pretty much dictates at this point that Retrospect 8 is the problem, not the hardware. Mayoff, I know you said Retrospect is writing data to the tape until the hardware has reported the tape is full, but the thing is this problem is restricted to Retrospect 8. If I go back to 6.1, it works fine. My hardware is being consistent, the only variable here is the version of Retrospect that I'm using. So I don't know what that means specifically, but the problem does appear to be directly connected to the use of Retrospect 8. Maybe it's wonky about the hardware compression, or maybe it's not fast enough as Russ suggested, maybe it has communication issues with my hardware. In any case, here's more specific hardware info in case it's useful. Vendor: LSILogic Product: Ultra320 SCSI HBA Revision: Firmware 1.3.39.0 Initiator Identifier: 7 Signal Type: Low Voltage Differential Description: Channel A Quote Link to comment Share on other sites More sharing options...
Mayoff Posted April 8, 2009 Report Share Posted April 8, 2009 I don't recall, exactly how much does 6.1 write to your tapes? Do you have a 6.1 screenshot similar to the one you posted above? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.