Error 109

[ridgedale]

I have Retrospect v.6.0.204 with Driver Update v.6.3.102 running on a G5 tower server running MacOS 10.3.9 Server and am getting the following error:

 

Error 109 (unexpected filemark or FTP end of file).

 

This is occurring both during both the start-of-week recycle backups and also the incremental backups

 

Could somebody please explain what this error means and how I can avoid/prevent it from happening in future?

 

Thanks for your assistance.

[twickland]

More information is needed. What kind of backup device are you using, and on what kind of bus? How long (if ever) have you had successful backups with this device? Have you changed anything (hardware or software) recently?

 

Does this occur only with scripted backups, or also with immediate backups?

 

If you create a new backup set as a test, does the problem still exist?

[ridgedale]

I got the following information from the device status window under Configure>Devices in Retrospect:

 

ID Vendor Product Version Driver

SCSI-A:0:0 SONY LIB-81 0106 Sony Library (5.02)

SCSI-A:1:0 SONY SDX-500C 0204 Sony AIT-2 DC (5.05)

 

Further fuller information:

 

The server is running MacOSX 10.3.9.

NOTES = The AIT Lib-81 is attached directly to the Apple G5 server which is backing up the whole local RAID-1 volume.

The SCSI card is an ATTO ExpressPCIPro UL3S (Single Channel Ultra3) SCSI card.

The driver for the ATTO SCSI card is v.3.20.

The version of Retrospect in use is (Mac) 6.0.204.

The version of the Retrospect Driver Update is (Mac) 6.3.102

The Sony tape library firmware is version 0106

The Sony tape drive firmware is version 0204

 

I have already spent a considerable amount of time liaising with Sony and ATTO support to get the backup performance optimised which involved making sure all the associated drivers and firmware were up-to-date - which they now are unless any new releases have occurred.

 

There have been no changes in hardware or software other than the driver and firmware updates which were completed by the end of last month.

 

This problem appears to be intermittent - the last couple of weeks it hasn't been a problem. But it has occurred before! All the backups are scripted backups based on a weekly recycle backup over the weekend followed by incremental backups on each Tuesday/Wednesday/Thursday/Friday early morning.

 

Given the amount of data involved I'm loath to get involved in new backups run manually - can I do this with a subset of the data as a test?

 

Thanks for your assistance.

[twickland]

I've never seen a 109 error myself, and, judging from the lack of mention in the forums and in the Knowledgebase, I suspect it's pretty rare. The type of error and the fact that it's intermittent does suggest a hardware problem. However, corrupted Retro.config files or backup catalogs can also cause odd errors.

 

I would try some routine troubleshooting. Temporarily relocating the config file out of /Library/Preferences/Retrospect will force Retrospect to create a new file the next time it's launched. In addition, you could try reinstalling the Retrospect software. Create a test script (or perform an immediate backup) to write to a new backup set. As a source, use a client or volume that has been implicated in a prior occurrence of the error.

 

if the problem recurs with a clean install and a new backup set, it would certainly cast suspicion on your backup device, SCSI cable, terminator, or SCSI host adapter. However, with an intermittent problem, it might take some time for the problem to appear.

[ridgedale]

I'm beginning to wonder if this is an issue relating to the temperature in the server room!

Since the end of last week the temperature rocketed and the errors started occurring.

When I checked the log this morning - after a relatively cool night and early morning - there was no repeat of the error! I'm going to monitor this and see what happens.

Thanks for your assistance - much appreciated.

[natew]

Hi

 

One suggestion:

 

Use the Atto utility to slow the SCSI bus speed to 40 DT. Thats 40 MB/s simultaneous read write. It sounds slow but it is still faster than the max of the AIT-3 drive (approx 33Mb/s).

 

This will eliminate any SCSI speed auto -negotiation problems. I have seen those in the past with LIB-81s and LIB-162s

 

Thanks

nate

[daviddidit]

I've been having this problem too but with a Sony AIT-2 4 Cartridge Autoloader, same SCSI card and OS 10.3.9 with latest updates, and the latest Retrospect Server with the latest RDU. After completely rebuilding the backup server (new scripts, tapes, everything), the issue has resurfaced. What's really strange (although it shouldn't be) is that when the server was at 10.3.2 we didn't have this issue. So something appeared during an update of either the OS, Retrospect, or ATTO firmware/driver that is causing this to happen.

 

I'm going to try the suggestion about slowing the SCSI bus down and see what happens. If the issue persists, I'm going to rebuild using OS X 10.2.8. The issue is wasting too much time...

[daviddidit]

changing the scsi speed to 40T did not resolve the issue as it just reappeared. what's strange about this issue is that there's no pattern as to when the error will occur.

 

i've swapped out almost everything (software reinstalled cleanly and newly configured; hardware swapped including the autoloader). the only thing i didn't swap out was the scsi cable and terminator. good thing we already have most of these parts already as it would've been a rather expensive issue to troubleshoot.

 

can someone chime in and explain what "unexpected filemark" means?

[CallMeDave]

Quote:

---

only thing i didn't swap out was the scsi cable and terminator. good thing we already have most of these parts already as it would've been a rather expensive issue to troubleshoot

 

---

 

IMHO, the _first_ thing(s) that should be replaced/tested would have been the cable and/or termination. Not only is it the most obvious point of failure, it's also the least expensive to swap out.

 

 

 

Dave