Jump to content

Tape Archive Restore Failures Leopard Server

Recommended Posts

Running Leopard Server 10.5.7. on a PPC with vers. 6.1.130

The process for doing a Restore from a vers. 4.x tape catalog with a supported DDS 3 drive was working for 5 months until recently.


Receiving this message in the Console:

"....... Stray process with PGID equal to this dead job///"


and also multiple launchD PID's in the Activity Viewer.


Using a different tape catalog that is open and working works correctly WITHOUT multiple Stray Process... and LaunchD PID's.


Moved and tested the results on a standalone workstation machine(PPC) with the 4.x tape catalog gives the same results.


Are we chasing a bug?

Does a 'cache' cleanup of Leopard Server remove all the stray processes and the 'dead job' lockup?


Is there a 'permissions issue' involved if the Target for the Restore is a different permission group than the 4.x tape catalog?


Pondering my options,,,,



Link to comment
Share on other sites

Running Leopard Server 10.5.7. on a PPC with vers. 6.1.130

The process for doing a Restore from a vers. 4.x tape catalog with a supported DDS 3 drive was working for 5 months until recently.

I'm not so certain that it was working "until recently" for some values of "recently".


Back in February / March of this year, it was reported by one user that Retrospect support told him that Retrospect 6.1 could not read 4.x backup sets. Here is that older post:

Retrospect 6.1 cannot restore backup sets from older versions


See also a subsequent discussion on this point in the Retrospect 8 beta forum:

Restore of older Retrospect backups pre 6.x


The original backup machine 4.x tape catalog is working correctly from the original machine, a G4 with OS 9.

Well, the G4 with OS 9 can't be running Retrospect 6.x, which only runs on Mac OS X 10.x, so I assume the G4 is running Retrospect 5.x.


Because of an unrelated (and difficult-to-reproduce) Retrospect 6.x bug that apparently can hang the SCSI chain during Retrospect's device scan phase prior to backup start if there are SCSI disks on the same SCSI channel as a tape autoloader / tape drive (only workaround is to move SCSI disks off the tape drive / autoloader SCSI channel), we had to recable our Xserve G5 and I cannot any longer test this bug with our older DDS3 DAT drive that was in use until 2005 (it is SCSI 1, our current drive / autoloader is LVD and VXA-2) unless I recable the Xserve to test.


However, like you, I have been able to retrieve older 2.x and 4.x backup sets on a PPC running OS 9 and Retrospect 5.1, so I know that works, and we keep that saved computer around in a cabinet so that we can bring it out if needed for that purpose.


Like you, prior to the time we did the recable of the Xserve, I did occasional restores from the older DDS3 DAT tapes using Retrospect 6.0.x and, I believe, some early versions of Retrospect 6.1.x. But I haven't made that test in a while.


Regardless, this was discussed at length back in February / March 2009 in response to a similar user's posting, and it seemed to be left with the conclusion, reported to that user from Retrospect support in a support incident, that the current version of Retrospect 6.1.x can't retrieve Retrospect 4.x backup sets. See above thread.


Of course, I seem to recall that you first had to rebuild the catalog when you opened the 4.x backup set (whether with Retrospect 5 or 6), but, after that, Retrospect 6 would retrieve the data (until this apparent bug was introduced).



Edited by Guest
add link to similar thread in February 2009
Link to comment
Share on other sites

The comments above are mostly correct, we did log an issue with using 4.x tape catalogs with vers. 6.x previously.


To clarify, the DAILY retrieval from the LOCKED 4.x tape catalog was successfully running for 5 months, until last week.


The only major change on Leopard Server was applying the 10.5.7 Combo Update, the Security Update, and running Repair Permissions (while the server was offline).


We have also just confirmed using 5.1 on an OS 9 machine that the Catalog Repair is successful.


It is ONLY this particular tape catalog that fails to actually write the chosen files from the Restore search screen to the drive. Another 6.x tape catalog operates correctly for Backup and Restore immediately after the 4.x Restore fails.





Link to comment
Share on other sites

The following message repeats 3-4 times in the Console of the serverat the time the Restore is started (NOT when Retrospect is opened);


com.apple.launchd[825] ([0x0-0xd00d0].AuthenticateUser[4944]) Stray process with PGID equal to this dead job: PID 4947 PPID 1 LaunchCFMApp


Link to comment
Share on other sites

The original backup setup was an external scsi DDS 2 sony drive unit.


The current setup is using an HP USB DDS 3 external unit.


From the large amount of console writes regarding SCSI access it appears Retrospect wrote specific drivers for the support of this unit. The online database lists this mechanism as certified.



Link to comment
Share on other sites

Since its been a few days since I discussed this post, and there seems to be few takers, I'm ending the requests for help on this issue.


Regards to those who thought and couldn't post.

I thought that the matter was completely resolved upthread above with my post:

Retrospect 6.1 cannot read older version backup tapes


Have you tried contacting Retrospect support?

Contact Retrospect Support


(these forums are user-to-user support).



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...