Backup Server hangs when 2nd new dvd media is inserted

[WNewall]

Has anyone else got this problem with Retrospect 6 when writing to dvd-r disks?

 

I've set up a Backup Server script and it starts OK, and seems to write the first dvd-r OK, ejects it and shows the Devices window.

I then insert the second (empty) dvd-r disc, select the device and the 'Proceed' button.

Retrospect accepts the new disk and appears to proceed (the devices window disappears), but Retrospect then hangs before writing any files to the new disk.

 

It is backing up a Windows XP client, and the only way to sort out the hang seems to be to turn the Retrospect client panel off and then on again on the client. There is a massive amount of network traffic on the Powerbook when it hangs, so it doing something! Retrospect shows the spinning cursor and doesn't respond to any input. The Retrospect client panel says that it is still connected to the server process.

 

The log doesn't seem to show any messages that might be related to the hang.

 

Setup is as follows:

Retrospect 6 (trial version 6.0.178)

15-inch Al Powerbook with superdrive (Matshita uj-816)

1 Windows XP client

Writing to dvd-r disks

Compression is on

The latest Retrospect driver updates are installed (5.1.103)

[WNewall]

The CPU also seems to go to 100% when it hangs (so maybe I have the same problem that quite a few others have!).

[natew]

Hi

 

This is odd to say the least. Can you run a little experiment please? It will help determine if the hang is due to the media change.

 

Create 2 disk image files using the disk utility 300MB each should be fine. Then create a removeable disk backup set in Retrospect. Unmount one of the disk images and start the backup then remount the other one when Retrospect asks for a disk. At this point do you get the same hang?

 

Do backups of your local drive that span 2 dvd disks also cause trouble?

 

Thanks

Nate

[WNewall]

Backing up the remote machine to 2 disk images works OK.

 

I think it might be something to do with some kind of timeout, as I think I have got it to work OK if I put the 2nd DVD-R in immediately Retrospect asks for it. However, if I leave the backup running overnight, and the 1st disk fills up during the night, and then it waits for a number of hours unitl I put the 2nd disks in in the morning it hangs. Not sure of that though!

 

I've turned off all screensaver/sleeping on both the machines.

 

I am now in the process of backing up from the local machine (and leaving it overnight waiting for the new disk) to see if that works.

 

 

[WNewall]

It didn't hang when backing up from the local machine.

I've just done another test backing up the client Windows XP machine and it hung even if I put the 2nd DVD in immediately at the prompt. Retrospect automatically accepted the DVD (removing the Devices window without me needing to press the Proceed button) and then appeared to continue (I think the messafe said something like "Continuing...") but there was no progress. The DVD drive timed out after a few minutes and stopped spinning. The CPU of the local machine was at 100% (Retrospect process). The remote machine was not doing anything.

 

I then turned the client panel off and on again. This cleared the server (which then complained about the client being turned off - error 519).

[AmyJ]

While in Retrospect go to Configure > Devices > Device Status and list the version number for the drive.

[WNewall]

DXJ3

[WNewall]

Any response?

The version number is given as DXJ3. The full info is:

ATAPI-A:0:0 MATSHITA DVD-R UJ-816 DXJ3 Panasonic DVD-RW (5.11)

 

I have installed the latest Windows client driver (6.5.136) and updated Retrospect (6.0.193).

It still hangs when the second DVD is inserted.

 

The dialog changes to "copying..." but nothing happense. The CPU goes to 100%. The client says it is in use by "Root". Turning off the client immediately makes Retrospect come to life and report "error 508 (access teminated)", which then of course stops the backup.

[jschaffe]

I'm having the same problem, with the following differences: client = Win2000, media = CD-R.

 

Backup machine:

-- Quicksilver G4, 866MHz, 640MB, 10.2.8, all Apple patches applied

-- Retrospect 6.0.193, Driver update 5.2.101

-- Happens with two CD-R drives in my config:

----- LaCie d2 FireWire CD-RW, CDRW 52x32x52x, LTR-52327S, LITE-ON, QS03

----- QPS Que!Fire 12x10x32 CD-RW, CD-R PX-W1210A, QPS, 1.07

----- (Have not tried my slow native Apple SuperDrive)

 

Client machine:

-- ThinkPad, 1.13GHz, 512MB, Win2000, all MS patches applied

-- Retrospect client 6.5

 

Network:

-- 100MB ethernet, both machines plugged into same ethernet switch

 

Behavior:

-- Start backup, preview, 11.7 GB to backup

-- Begin backup

-- Insert first CD-R

----- Mac CPU 100%

----- ThinkPad CPU varies around 20-30%

-- Member full, Retrospect requests next member

----- ThinkPad CPU drops to 0-1%

-- Replace member 1 with new blank CD-R in same drive

-- Retrospect preps member ("please wait")

-- Retrospect turns to backing up first file on new member

----- Mac CPU 100%

----- ThinkPad CPU 0-1% (shows no blip since member 1 full)

-- Retrospect non-responsive (will not respont to pause or stop buttons)

-- Force quit Retrospect

 

I attepted fresh backups 4 separate times, twice on the LaCie, once on the QPS, once starting on QPS with second member in the LaCie. I got exactly the same behavior each time. I rebooted both machines at least once during the process.

 

I hope this helps, but it's a major bummer for me!

 

Jeff

[jschaffe]

I have to keep Retrospect 5 and 6 on my Mac until I get fully off of version 5 backup sets.

 

Any possibility that's part of the issue?

 

Doing a search of my drive for Retrospect files (I renamed the preferences file to see if that helps), I noticed files like retrospectcdfs.kext that are in non-version-specific folders like retrospectcd.fs.

 

In the meantime, I found a later version of the client and I'm going to try with a fresh preferences file.

 

Jeff

[WNewall]

I.ve never had Retrospect 5 on my machine, so I don't think that's the problem.

Your description seems to be exactly the same as what happens on my machine.

 

Woll

[jschaffe]

I wrote:

 

> ...later version of the client and...a fresh preferences file

 

Well, that didn't work.

 

I also tried running another incremental backup session beginning from where my last failed attempt halted. In case the information is useful in narrowing down where the problem occurs, Retrospect would not accept the second member CD-R it had prepared immediately before freezing. I received the message:

 

-- Couldn't erase disc, error 112 (can't erase/format media).

 

Sacrificing new CD-Rs gets a new second member created, but freezes at the same point in the creation of the third (sigh).

 

Jeff

[jschaffe]

(Thought I'd retitle this to make it reflect my situation)

 

What a nightmare!

 

I called Dantz support on Monday. An hour in the queue.

 

The LaCie drive I was using is not supported yet. The QPS drive is version 1.07. Support wants 1.08 before they'd talk with me. QPS never provided Mac updaters, and the PC updaters wouldn't work with a firewire interface, which rules out using my ThinkPad to upgrade the device. Hours later (went a whole detour trying Plextor updaters too) with a scavenged PC, a ribbon connector from my Mac, the QPS firewire bridge dangling from wires while it powered the bare drive, which was connected to a scavenged PC, I was able to apply the update and now the QPS is at version 1.08.

 

Tried another backup. Same result.

 

Another hour in the Dantz queue today. Their advice was to use Retrospect's configure device routine. Ran that once, and tried a backup. on a 12x write-speed device, 16MB per minute. I killed the backup and repowered everything and configured the drive again. Much faster, almost 100MB per minute through the first CD-R

 

Retrospect asked for the second CD-R. It prepped it and seemed to spend a number of seconds to finish writing the file left over from the first member.

 

Then it hung again.

 

New data, though, is causing me to think it's not the drive.

 

I left Retrospect spinning the rainbow wheel and went and shut down the ThinkPad.

 

Retrospect unhung and gracefully reported "Execution incomplete." Here's the log entry:

 

+ Executing Immediate Backup at 4/13/2004 6:51 PM

To backup set Endymion E EDT…

 

- 4/13/2004 6:51:05 PM: Copying C_Drive (C:) on ENDYMION…

4/13/2004 6:51:05 PM: Connected to ENDYMION

Trouble reading files, error 519 (network communication failed).

4/13/2004 7:05:34 PM: Execution incomplete.

Remaining: 53893 files, 10.9 GB

Completed: 5844 files, 906.2 MB, with 22% compression

Performance: 68.0 MB/minute

Duration: 00:14:29 (00:01:10 idle/loading/preparing)

 

I'm beginning to think it's something about resuming communications with the client, but I'm not sure.

 

Oh well, maybe tomorrow I'll have tome for the next exciting installment of "Backup Trouble!"

 

Jeff

[jschaffe]

OK, I tried one more thing (a local backup) and here's a summary of where I am right now:

 

1) Backing up my ThinkPad client to a Max OS X backup server, Retrospect hangs either immediately after it preps the second CD-R (or immediately after it finishes writing a split file or the contents of its buffer to the new disk). There is no response to stop or pause buttons but quitting the PC (or perhaps turning the client off?) ends the hang and closes out the second backup set member gracefully. Of course Retrospect doesn't validate the backup.

 

2) Backing up my Mac locally works fine, using each of 4 CD-Rs as it's inserted.

 

Here's my configuration:

 

Backup machine:

-- Quicksilver G4, 866MHz, 640MB, 10.2.8, all Apple patches applied

-- Retrospect 6.0.193, Driver update 5.2.101

-- QPS Que!Fire 12x10x32 CD-RW, CD-R PX-W1210A, QPS, firmware 1.08

-- -- (same behavior with firmware 1.07, 1.08, and 1.08 plus custom configuration)

 

Client machine:

-- ThinkPad, 1.13GHz, 512MB, Win2000, all MS patches applied

-- Retrospect client 6.5.136

 

Network:

-- 100MB ethernet, both machines plugged into same ethernet switch

 

Behavior:

-- Start Retrospect, preview ThinkPad, 11.7 GB to backup

-- Begin backup

-- Insert first CD-R

----- Mac CPU 100%

----- ThinkPad CPU varies around 10-35%

-- Member full, Retrospect requests next member

----- ThinkPad CPU drops to 0-1%

-- Replace member 1 with new blank CD-R in same drive

-- Retrospect preps member ("please wait")

-- Retrospect turns to backing up first file on new member, writes for several seconds

----- Mac CPU 100%

----- ThinkPad CPU 0-1% (shows no blip since member 1 full)

-- Retrospect non-responsive (will not respont to pause or stop buttons)

-- Shutting down ThinkPad wakes Retrospect and closes out the second backup set member

 

I've toasted 14 CD-Rs sofar trying to get this to work.

 

I'll continue working with Dantz tech support, but I'm wide open for suggestions!

 

Jeff

[jschaffe]

First let me update the previous post:

 

I also have difficulties seeing the client when I want to start a backup. I've had to literally disable and re-enable the network in the client before Retrospect 6 see's the client

 

I also performed the test described earlier in this thread:

-- Create two 300 MB disk images using Disk Copy

-- Unmount one

-- Create a new catalog for removable media

-- Back my client up to the new catalog

-- When the first image is full, mount the second one

This test succeeds.

 

The next suggestion from support was to *downgrade* the client from 6.5 to 6.0

 

This worked!! 11.8 GB successfully backed up to 16 CD-Rs!

 

Retrospect 6 seems to be extremely sensitive to network communications. First, Retrospect can not successfully resume a backup with a 6.5 client after a media change in my environment.

 

In addition, after downgrading the client and watching Retrospect 6 make it successfully to the 4th CD-R in my backup, I had another interesting problem. While Retrospect continued on to the 5th CD-R, I started Timbuktu on the Macintosh and opened a control window to a third machine on my network. In the midst of my otherwise successful backup, I spent maybe 8-10 seconds resizing a graphic on the remote machine, resulting in CPU- and network-intensive operations on the Macintosh. This caused Retrospect to think it had lost contact with the backup client and Retrospect terminated the backup. Termination was graceful, however, and I restarted the backup with no further problems through the 16th CD-R (other than not being able to verify the first 4 CD-Rs, of course).

 

If this theory is right, Dantz may have to make the communications handling a bit more robust than it is at present.

 

In the meantime, if you're still experiencing freezes, see if the client downgrade applies to your situation.

 

Jeff

[natew]

Hi

 

First let me apologize for not responding sooner. As you may have guessed by the hold time we are having a hard time keeping up.

 

I am trying to reproduce this problem on my mac powerbook G3/400 but so far I haven't had any luck. Changing disks does not seem to interfere with the network communication even with the newest client.

 

I'll let you know if I run into the same problem. Have you tried connecting the machines directly with a crossover cable?

 

Nate

[jschaffe]

No, I haven't tried that. If I get the time, I'll give it a try.

 

Looking forward to hear if you have any luck reproducing the problem.

 

Jeff

[jschaffe]

Another update. I completed a second complete 15 CD-R backup from my ThinkPad (Client 6.0) to my Mac OS X Quicksilver (Retrospect 6.0.193) with absolutely no problems!

 

On the other hand, I tried a 2 CD-R backup from my Toshiba Equium 8000s (Client 6.5.136) with the same hang at the beginning of the second CD-R. I downgraded the Equium to Client 6.0, but haven't yet attempted another backup that needed a new CD-R.

 

So the media change freeze happens with two Win 2000 machines and 6.5 Client, but not locally on the Mac or with 6.0 Clients (one not yet verified).

 

Jeff

[msilano]

Same problem here. Retrospect 6.5.343 on a Thinkpad T40 running XP

 

Drive is an External USB2 Sony DRU-500a (firmware 2.0h) driver 1.56

 

Backing up the laptop, all is well until a new disk is required. Then, we get to "erasing disk" and the drive simply continues to blink ad infinitum. The program never recovers, and must be terminated. The backup can be restarted successfully, and Retrospect will properly handle the erasing of the disk this time through......right up until a new disk is required.

 

Any help would be greatly appreciated.

 

Thanks,

 

Mike

[mattnevels]

This sounds exactly what I'm seeing now that I've upgraded to 6 from 5. Except that I'm using a tape drive instead of CDs, When a windows client is backing up and a new tape is needed it never continues after the new tape is inserted. Same symptoms on two different Retrospect 6 Servers. I will try downgrading that client and report back.

 

I just upgraded them all from 6.0 to 6.5, now I've got to go back to 6.0? Does anyone else have a problem with this? I probably have to go out to each machine to do this don't I?

 

Matt Nevels

[WNewall]

Is there any news on fixing this problem? I am still having to run using the old client (6.0.110). I see there has been an update recently, but no news on whether this has been fixed.

 

Woll