GMRMacBackup Posted May 17, 2010 Report Share Posted May 17, 2010 Is there an approved method of transferring content from one tape cartridge to another without dumping it back to a hard drive? I have a series of backups that are incremental in nature and one of the first tapes were accidentally overwritten. Since the local copy held the exact same contents and did not have any additional members to the backup I would like to duplicate it to recreate my offsite copy. I've researched the Retrospect manual and there does not appear to be a function available for such an action. After checking the web i found there is a 'tcopy' command available in UNIX but haven't a clue if it would be possible to implement it and have a viable backup tape. Any suggestions? My backup library has two identical LTO4 drives connected via 4GB Fibre and I have the Advanced Tape plug-in so Retrospect can communicate with both drives at the same time. System specifics: Intel Xserve (10.5.8 Server, 2 x 2Ghz, Apple Raid card, 3 x 750GB Raid 5, 10GB RAM) EMC Retrospect Single Server Unlimited 8.1.626 Advanced Tape Support enabled Apple 4Ghz 4 Port FC Card (driver 2.02) Brocade 200e Fibre Channel switch (connected to Apple FC card) Promise 610f 9TB (Raid 5, 4GB FC controller, connected to Brocade) HP StorageWorks 4048 LTO4 dual drive w/4GB FC controller (connected to Apple FC card) Quote Link to comment Share on other sites More sharing options...
rhwalker Posted May 17, 2010 Report Share Posted May 17, 2010 The unix "tcopy" command won't work because you don't have unix tape drivers. Retrospect's drivers aren't general-purpose unix tape drivers. Strictly speaking, there's not a way to do exactly what you want, but there is a way to accomplish the same result. Retrospect views each of the tapes as a unique member of a tape library, and doesn't provide a mechanism to "duplicate" tape members. You must have gone to great lengths to overwrite those tape members if you used Retrospect to do so, because Retrospect tries so hard to protect your data that it sometimes becomes frustrating when you do, in fact, want to overwrite a tape. I suspect, if you used Retrospect to overwrite the tapes, you did a "recycle" or "erase" of the tapes. However, here's how to do almost what you want: Create a new media set with the new tapes as members. Then "transfer" (now known as "Copy Media Set") from the onsite copy to the new tapes. You will end up with a differently-named media set, but the same data on it. See page 167 of the Retrospect 8 Users Guide. As an aside, the only Unix tape drivers for Mac OS X of which I am aware are the Tolis Tape Tools from Tolis Group. But that's not what you want here. Russ Quote Link to comment Share on other sites More sharing options...
GMRMacBackup Posted May 18, 2010 Author Report Share Posted May 18, 2010 Thanks Russ. While I was having my library problems I was manually moving tapes into the drive while the library was uncommunicative. I was using the library web interface to swap tapes and made the error of not having a list of associated tape numbers available when I did. Two of the offsite tapes were in the wrong slots at the wrong time. I've already copied the contents of the first tape and the second one should be done later today. As an aside, what are your thoughts about a function of this nature? I would dearly love to have the ability to transfer all of my LTO1 tapes directly to LTO4, it would have allowed me to retire my old PowerVault 132T. Having the ability to copy tape to tape would have saved me a bundle since I wouldn't have had to buy the old library off of lease. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted May 18, 2010 Report Share Posted May 18, 2010 Thanks Russ. While I was having my library problems I was manually moving tapes into the drive while the library was uncommunicative. I was using the library web interface to swap tapes and made the error of not having a list of associated tape numbers available when I did. Two of the offsite tapes were in the wrong slots at the wrong time. Sounds like you aren't using barcodes, because that might have prevented the issue. I strongly suggest using barcodes, and I also suggest making the barcode labels correspond to the member and media set names. For example: 1-A 0001 2-A 0001 3-A 0001 (etc., for members of media set A 0001) 1-B 0001 2-B 0001 3-B 0001 (etc., for members of media set B 0001) If you give your media sets (f/k/a/ backup sets) names that correspond to the media type and that relate to the barcodes, it becomes easy to retrieve the right tape when Retrospect asks for a tape member. For example, using the above barcodes, have media sets named: VXA Set A [001] VXA Set A [002] ... VXA Set B [001] VXA Set B [002] ... LTO Set A [001] ... DAT Set A [001] etc. We use Tri-Optic barcodes, and I have been very satisfied over the years: Tri-Optic barcodes As an aside, what are your thoughts about a function of this nature? I would dearly love to have the ability to transfer all of my LTO1 tapes directly to LTO4, it would have allowed me to retire my old PowerVault 132T. Having the ability to copy tape to tape would have saved me a bundle since I wouldn't have had to buy the old library off of lease. I think it's a very good idea, but the only way I know to do it at present is to buy Tolis Tape Tools and use the unix "dd" command. It's been requested before, but the best there is with Retrospect is the Transfer (now known as "Copy Media Set") command, discussed upthread. And, if you think about it, Retrospect's approach might be the only approach possible because Retrospect writes all the way to EOT. The problem that Retrospect would have with such a feature (duplicating tape members rather than duplicating media sets) is that a tape member is uniquely identified by Retrospect in its catalog, so that Retrospect knows which member holds which data. If, for example, two tapes don't hold the same amount of data (tapes do differ in length, whether because of differences in inter-block gaps caused by different transfer rates as the processing load changes, or because of slightly different tape lengths), it might not be possible to "replicate" one tape member onto another. Remember, Retrospect writes until it hits EOT (or decides that the tape is bad because of errors), then moves to the next member. Actually, tape is a bit more complex than that, in that physical EOT (the metal strip) is located well before the actual end of tape (so that the tape doesn't come off the reel), and the driver can write a few more blocks before writing the EOT mark (logical EOT). The metal strip (physical EOT) is more of a warning than an actual hard limit. Just a bit of trivia for those of you who haven't had the pleasure of writing tape drivers. Russ Quote Link to comment Share on other sites More sharing options...
GMRMacBackup Posted May 18, 2010 Author Report Share Posted May 18, 2010 Our tapes are barcoded from the factory, hence the widely varying numbers on the lists of tapes in the pictures. As long as my library and Retrospect maintain communications the tapes shouldn't get scrambled again. I was on the road and was using the library web interface via my iPhone and didn't have access to the tape lists and was foiled by the Media Sets/Members inability to show know members when a backup is in progress. In others words a self induced problem. That would be another nice change, have the list of known members visible in light grey when the backup is in progress. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted May 18, 2010 Report Share Posted May 18, 2010 That would be another nice change, have the list of known members visible in light grey when the backup is in progress. The GUI could stand many improvements. Right now, the buglist is so large that bug issues prevail over GUI improvements. Russ 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.