Retrospect crashes during automatic backup

[jjf]

We have been having issues with Retrospect crashing during a scripted backup. We have done all the updates to the most current installer, client and driver and the details of the machines involved are as follows:

 

Host/Installer Machine - G4 tower running 10.3.9,

Client machines - Mac Minis, couple power books, Imacs all running tiger or Leopard (most current versions).

 

An automatic backup runs at night and when it crashes, it has been on both the Tiger and Leopard machines (so I can't pinpoint to an OS). It has crashed on each type of machine (so I can't pinpoint to a machine) so the only thing I am left to wonder is if it the fact that the host/installer machine is running Panther, that this is somehow causing a problem.

 

When it crashes, it freezes the whole machine and there is no error message that occurs except when you turn the machine back on, it just gives a message about checking a power surge (which is not occurring).

 

Any suggestions - please be patient, I am not a computer wizard as some of you are.

 

Thanks.

[twickland]

What kind of backup set are you writing to (tape, DVD-ROM, file backup set, etc.)? What hardware are you using and how is it connected to the host computer?

 

When did the problem first appear? You seem to suggest that was happening before you updated the Retrospect application, but please confirm. Had you just performed any updates or installations on the host computer when the problems began?

 

Does the script in question back up any local volumes on the host computer in addition to the clients? Has Retrospect ever crashed when backing up local volumes?

 

Does the log indicate whether the backup script is consistently in the copying phase or the comparing phase (i.e., what is the last entry in the log when Retrospect crashes)?

 

Can you successfully perform an Immediate Backup of your client volumes?

 

Is the host computer used for anything other than Retrospect backups? Have you run Disk First Aid on the boot volume and the volume where the Retrospect catalogs are stored?

[jjf]

- Removable Disk backup to Western Digital 1TB external drive connected via Firewire 400

 

- The problem has occurred on and off for a period of about 3-4 months. Nothing has changed on the host computer other than running all the updates Retrospect puts out at the time they are put out.

 

- The script does not back-up any local volumes, but we do a "nightly" back-up that does local volumes and it never has a problem. These nightly back-ups are manual back-ups and we have never had it crash on a manual back-up. I also end up doing manual back-ups when I get in in the morning when it crashed over night and it never crashes at that time either.

 

- The log shows that it has crashed during both the comparing and copying stages, it is not specific to either one. The log entry basically just ends at that point "comparing documents on.." and no error after that line item or anything.

 

- Yes, an immediate or manual back-up is fine, no problems.

 

- This computer is also the host for Filemaker Server, but it is turned off when we run the back-up. I have also run a complete test of all the hardware using tech tool and everything gets a clean bill of health.

 

I can say that prior to having any Leopard machines in the office, we did not have this problem, but the problem also did not the immediately after having Leopard machines nor does it only crash on Leopard machines, so I'm not sure if that is having any effect.

 

Thanks for your help.

[CallMeDave]

Removable Disk backup to Western Digital 1TB external drive connected via Firewire 400

 

Is there a compelling reason why you're not using a File Backup stored on this external drive? Do you expect to be adding additional drives to your Backup Set?

 

an immediate or manual back-up is fine, no problems

 

If you Execute an Immediate Backup, then switch from Interactive mode to Unattended mode from the Control Menu (visible after scanning, during actual backup/compare), doe the problem show up?

 

When it crashes, it freezes the whole machine and there is no error message that occurs except when you turn the machine back on, it just gives a message about checking a power surge (which is not occurring).

 

This suggests a hardware/device issue. If you don't require the unique features that come with using your fixed-platter FireWire hard drive as if it were a removable device, I'd suggest using a File Backup Set stored on that drive.

 

And if the WD 1TB is actually two 500 GB drive in a striped array, I'd suggest using something different instead.

 

Dave

[jjf]

- Yes, we do add additional drives as they become full.

 

- I will have to look into whether going to the unattended mode causes any issues. At that point, the script was not started by itself though, so would you really see the same results?

 

- File backups as I understand it do not allow you to span multiple drives. We did 4 500GB WD drives prior to these two 1TB drives using File backups, but obviously not having to do a "fresh" backup and wasting that HD space each time was the motivator for going to the Removable media once Retrospect introduced it.

 

- These are not scabbed 500 GB, it is a 1TB individual drive.

 

So you're thinking the Removable media backup is the problem?

 

 

[twickland]

Removable Media backups in Retrospect for Mac are a kludge and seem to be subject to flaky behavior under certain circumstances. However, if they have worked for you up until now, you're probably OK.

 

When did you move from your 500GB drives to the 1TB drives? That didn't happen to correspond with your troubles, did it? Have you added a new destination drive member since the problems began, and did they persist with the new member?

 

I agree with Dave that your symptoms are suggestive of hardware problems. The fact that you don't see them during an immediate backup may simply be statistical, especially if the time taken for your immediate backups is shorter overall than for your scripted backups.

 

If on the other hand the backups fail when you switch an immediate backup to unattended mode, that would suggest a problem with the configuration file "Retro.Config."

 

It's pretty easy to test Retro.Config, so you might want to do that in any case, especially if you have a backed up copy from when things were behaving properly. (If you don't have a backup copy, you'll need to recreate all your scripts and lists from scratch.) Drag Retro.Config from /Library/Preferences/Retrospect to the desktop or somewhere safe, and then drag in your backup copy. If you don't have a backup, Retrospect will create a new version; you'll have to reenter your serial number.

 

 

[jjf]

Thanks for the reply twicklnad.

 

Sorry for the delay in response, I wanted to go back through each and every one of my logs from now back to January to see if I could find any more tidbits or correlations.

 

To answer your questions first, when we switched to the 1TB drives, we had no problems, things went well for quite a while. We have not had to go to a new member yet, so I don't know if it would be problematic.

 

As for the manual vs automated back-ups. When the automated back-up crashes, we have to run the entire back-up manually, so it is the same length of back-up, same files and computers.

 

When I looked back in the logs, it appears that the first time the crashing occurred regularly was after the installation of Retrospect driver update 6.1.13.101 (The Retrospect Installer version at the time was 6.1.138). The crashing did not occur specifically on either drive, it occurred on both. It has continued to crash every 2nd or 3rd back-up since June 13th when we did the install. We have since done the driver, client and installer updates as they become available, but it has not seemed to change anything.

 

As far it being a hardware/removable media issue, I would agree if it weren't for the fact that we have been through 4 WD500GB drives already (over the span of 16 months let say)with no issue and used the 1TB drives for more than 6 months without problem (prior to this update).

 

I do not have a back-up copy of the Retro.Config file. So if I do as you say and drag it and save it somewhere, the new one will only require me to enter my serial number and will not cause me to have to re-enter all my scripts etc?

 

Thanks very much for your help.

 

[twickland]

I do not have a back-up copy of the Retro.Config file. So if I do as you say and drag it and save it somewhere, the new one will only require me to enter my serial number and will not cause me to have to re-enter all my scripts etc?

Unfortunately, all your scripts, lists, custom selectors. etc. are contained in Retro.Config. However, what you're doing at this point is only a test. If you can't run a successful backup under a clean copy of Retro.Config, you'll have determined that the problem must lie elsewhere, and you can reuse your old Retro.Config file. If, on the other hand, your old Retro.Config turns out to be corrupt, you will need to reenter all your scripts by hand, since you have no backup copy.

 

[jjf]

Do you have any thoughts on the coincidental nature of the problems occurring after the driver update?

 

Thanks.

[CallMeDave]

Do you have any thoughts on the coincidental nature of the problems occurring after the driver update?

 

Sure; it's reasonable to suspect that the new driver is the cause of your problem.

 

Fall back to the driver you were using successfully, and see if the problem goes away.

 

 

Dave

[jjf]

In order to revert back, that means I will have to revert all the client installs back as well correct? If so, is there an easier way to do this than going to each machine and uninstall/reinstall?

 

Also, how do you rollback the installer and where are the previous versions to install?

 

Thanks in advance.

[twickland]

In order to revert back, that means I will have to revert all the client installs back as well correct?

Hmm. Sounds like it's past time that we got some more information about your configuration. For starters, what versions of Retrospect/RDU/Client software are you currently using? You mention 6.1.138 with RDU 6.1.13.101 as being the point where you started seeing problems, but it now sounds like you have subsequently updated again.

 

Also, how do you rollback the installer and where are the previous versions to install?

You can use the appropriate installer to uninstall the existing software and to install your desired version. (Be sure to save a copy of your configuration file in case something goes wrong.)

 

EMC's website used to maintain many archived earlier versions of the installer, but the selection now seems to be much more limited. (I found a page that lists old versions, but the links on it lead only to blank download pages.) I don't suppose you have your original install CD or download, do you?

 

Frankly, though, if you have updated more than once without success, I'd doubt if the RDU is the problem.

 

To me, it would also be easier to write a test script in a new, clean configuration file than to perform a lot of uninstalls/reinstalls.

 

[jjf]

In one of my earlier posts that I noted that I initially had the problem with the version mentioned and have since done all available updates with no resolution to the problem.

 

Yes, it would be quite helpful for Retrospect to provide access to previous versions where reverting is the solution or at least a test.

[CallMeDave]

In order to revert back, that means I will have to revert all the client installs back as well correct?

No. I'm only suggesting falling back to a previous version of the RDU file.

 

 

Also, how do you rollback the installer and where are the previous versions to install?

No installer; the RDU is a single file ("Retrospect 6.1 Driver Update") that lives in the same folder as the Retrospect application. When you launch the program, you'll see the version listed in the Operations Log. It's the simplest test to try first (especially since you asked about the possibility that this might be the cause; always go with your gut first).

 

Dave

[rhwalker]

In case it helps, here is the RDU version history with links to all of the versions for downloads:

RDU version history

 

Russ

[jjf]

Sorry for my lack of understanding, but will reverting the RDU affect me using the external drive or anything? I just want to make sure I don't muck anything up.

 

Thanks again to all you guys for your help. I will try this early next week since I will be busy doing a manual back-up today before the weekend!

 

Josh

 

[CallMeDave]

will reverting the RDU affect me using the external drive or anything?

 

 

I suppose you have no reason to trust my advice, as I could easily be a deranged loner living in my mother's basement. But for the record, I would not have knowingly suggested a test or course of action that would adversely impact your setup.

 

Falling back to the RDU that worked before you updated will behave the same as it did when you used it before; hopefully, that means that it will work without the problem showing up again.