Jump to content

bad backup set header

Recommended Posts

I keep getting 'bad backup set header errors' while trying to restore a project. I upgraded to Retrospect 4.3 within the last 4 months and am wondering if I have to go back to 4.1 to retrieve older projects. I ran Norton Speed Disk recently if that matters. Also, when I try to rebuild the backup set it gets to about 25 Gigs and says not enough application memory. I increased the memory to 15Megs and no go, so I tried 60Megs and still no go. Could I be having a media or drive problem?




B&WG3 350MHz


OS 9.1


128Megs Ram


Cybernetics CY-8050 AIT II drive attached to Adaptec 2940UW in slot J10


Sony SDX2-50C AIT II tapes (100 Gigs compressed)


Seagate Cheetah removable drives attached to Adaptec 3940UW in slot 2x4

Link to comment
Share on other sites

A bad backup set header indicates Retrospect encountered a missing or damaged file header, which contains information such as the file’s name and size. This error can indicate SCSI communication problems. Please see SCSI troubleshooting at the end of this post.




Error -108 (out of application memory) means that there is not enough memory available to Retrospect for it to continue the operation. This error occurs most often when scanning volumes and catalogs or when using file backup sets.




When Retrospect needs more memory to start an operation it temporarily takes memory not in use by other running applications. Because of this you usually do not have to change the default memory settings of the Retrospect application. Changing the memory settings may reduce overall performance. However Retrospect does not use temporary memory when using file backup sets so you may have to increase the memory settings when you work with file backup sets.




Retrospect may report error Ð108 when other applications and extensions are using most of the memory or your Macintosh does not have enough RAM installed. Try quitting your other applications or restarting with fewer extensions to make more memory available to Retrospect. Repeat the operation which brought about the error.




If Retrospect still reports this error try setting Retrospect's preferred memory size as shown in the user's guide. NOTE: These requirements increase by approximately 900K on a Power Macintosh (or Mac OS compatible PowerPC-equipped computer) without virtual memory turned on. If you have more than 100 clients logged in to Retrospect increase the Retrospect application's memory allocation by 2K per client.




Increasing the Memory Allocation: To increase the memory allocation of the Retrospect application follow these steps.


1. Quit Retrospect if it is open.


2. Go the Finder and select the Retrospect application icon.


3. Choose Get Info from the File menu. (Under Mac OS 8.5 and later Get Info is a submenu; choose Memory from it.)


The Info window appears listing Retrospect's memory allocation. Enter a new preferred memory allocation number in the space provided in the lower right corner of the window.






SCSI Troubleshooting:


A SCSI hang can be caused by one or more of the following:


1) A dirty tape drive or bad tape. Clean the drive using a cleaning cartridge. Try another tape. If other tapes work, then you just have a tape with a spot that's bad enough to crash your backup.




2) Another device on your SCSI bus is interfering with the tape drive's communication. Make sure your SCSI ID numbers are set correctly. Turn off your Mac and the SCSI devices. Disconnect all SCSI devices except for the tape drive.




3) You have a bad cable. Replace the SCSI cable that connects the tape drive to the computer after removing other devices and cables from the SCSI chain.




4) You are missing a terminator or have a bad terminator. The last device and ONLY the last device in your SCSI chain needs to be terminated. Try replacing the terminator if you already have one on the chain.




5) The computer may be having a problem. Install Retrospect on another Macintosh and try the tape drive there as the lone SCSI device.




6) The drive may be defective. If you have implemented all of the preceeding steps and get failures on multiple tapes after changing cables, terminators and computers, then the drive, being the only factor that has not changed, is the culprit--send it back to your vendor for repairs.




The steps above are essentially the outline of our SCSI troubleshooting here at Dantz. Hands on testing of device issues is really still the best method and even getting SCSI logging information is usually only to confirm empirical testing. Note that concluding something is a bad device is the LAST thing we assume after all other components and variables have been ruled out.


"SCSI voodoo", as they call the nebulous symptoms that can plague a SCSI bus, can often lead one to false assumptions of the cause of problems. It's important that once a variable is tested that it be tested more than once for consistentcy's sake to rule out dumb luck. For example, SCSI voodoo accounts for why a tape drive may work fine for many months without proper termination but then suddenly fail in some way later. Although customers will often cite that nothing has changed with their SCSI bus configuration in months and that it was all working before, this is really indicative of the inconsistency of SCSI voodoo.


The quickest and most conclusive test for most devices is to test it on more than one computer as the only device on the bus and with a different SCSI cable. If the problems can be reproduced on multiple computers, it's more than likely a hardware problem with the device itself.


Of course there a myriad of other specific issues having to do with a device's own hardware settings like with internal jumper cables, dip switches or internal termination that has to be sorted out with the device's manual and/or vendor or manufacturer of the drive but the kernel of SCSI troubleshooting above is a good general guideline.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...