Jump to content

Copying DDS Tapes

Recommended Posts

I'm trying to duplicate my Retrospect DDS backup tape archive library using 'Copy' in the 'Tools' window with 2 DDS drives. After the first tape of the storage set finishes a window saying 'Operation Incomplete' pops up. My only option then is to close the window which takes me back to the beginning of the procedure and Retrospect copies the same data from tape 1 all over again.

Has anyone made copies of storage sets that have more than 1 DDS tape?

Edited by Guest
Link to comment
Share on other sites

I believe that "Copy" will not do what you want, and there's actually no way to copy (duplicate) retrospect backup tapes.


However, if you have two DAT drives, you can "Transfer" the data from one backup set (one tape set and all of its members) to another backup set (another tape set). In your case, you would probably start out with the destination backup set as empty, and members will be added as needed.


No, the tapes will not be identical because they will be members of different backup sets, but they will have the same contents in the backup sets.


Hope this helps,



Link to comment
Share on other sites

Thanks for the replies.

I'm using an H.P C1537A as the read drive and a Sony SDT-9000 as the write drive, (they both have the same firmware as recommended) with Retrospect 6.0.204 running on an old g4.

My workflow is ;

Go to TOOLS menu

Select COPY


Choose the back up set to copy

Create a new storage set suffixed, "CLONE"


and click TRANSFER


This works fine for the storage sets that have a single tape but once the operation has reached the second tape of a multi-tape storage set I get a window saying 'Execution Incomplete'.

In the report log I get this ;

"Trouble positioning "TAPE NAME" (4782), error 109 (unexpected file markor FTP end of file).

Link to comment
Share on other sites

Nigel, I'm a bit confused. In your initial post you said:

I'm using an H.P C1537A as the read drive and a Sony SDT-9000 as the write drive, (they both have the same firmware as recommended) with [color:red]Retrospect 6.0.204[/color] running on an old g4.

but, in your most recent reply, you said:

We're running a Power Mac G4 single processor 350mhz, 448 mb of memory, 1mb L2 Cache, 100mhz Bus Speed. OS X 10.4.11, [color:red]Retrospect Version 6.1.230[/color].

Did you upgrade Retrospect in the middle of this?


If so, what version of Retrospect Driver Update ("RDU") are you running? (see the Retrospect log). RDU updates are here:

RDU update

and the RDU version history (release note) is here:

RDU version history


I'll have to admit that I have never tried a "transfer" of a multi-member tape backup set (have only done it on a single member set; do alternating backup sets in the autoloader to server the same purpose). But, before we go chasing our tails, it would be nice to confirm that you are seeing this using the current version of Retrospect and RDU.



Link to comment
Share on other sites

Hmmm... Does it behave the same regardless of which drive is the source?


Having written a few tape drivers in my youth, the way things are supposed to work is that, upon seeing sensing of the EOT strip (which is not sensed by the head, but which is sensed by contacts that are before the head), the driver is supposed to write two file marks (to indicate logical end of tape, perhaps doing a space reverse file before doing the write). Retrospect may not be clearing the EOT sense bit after it backs up.


One way to test would be to write a short backup, then do a "skip to new media", which would start a second member. That would show whether the problem occurs because of switch to second member in the set, or whether it's because the EOT strip sense bit isn't getting cleared after backing up to get back on the right side of the strip.


End of tape recovery routines are hard to test and are rarely tested thoroughly.



Link to comment
Share on other sites

Ok, then it appears that you have discovered a Retrospect bug (not properly handling the physical EOT sense strip in "Transfer" mode when using two tape drives). Your tests indicate that it's not a problem with the driver for one of the particular drives, because you get the same failure results when you swap drives, and because you don't get the failure result when logical (not physical) EOT causes a switch to the second tape. And the good news is that it's a reproducible bug with different drives.


I'm a bit surprised that it doesn't happen in restore mode; I've done multi-tape restores before, so I believe that does work.


I suggest you contact EMC / Retrospect support and file a bug report:

Contact EMC support


Good luck,



Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...