Jump to content

Backup fails during media change with error 515


Recommended Posts

Quote:

Here's an analogy for you: I have a car that won't start

 


 

Interesting story, but there's a way that's more apt, although I don't think it's quite analogous to the situation under discussion:

 

- When your car doesn't start, a the display on the dashboard shows a unique error code.

- Checking on the car manufacturer's web page you find that the error code refers to a relay in the fuse box.

- Now, even though you were able to get the car to start with the new battery, you go out on a limb and invest the $9.75 on a new relay, since the car manufacturer possibly has specialized knowledge of this.

- Lo and behold, you put the original battery back in and the car starts reliably again!

 

On a visit to the car show, you run across a manufactures rep engineer, who explains the workings of that particular relay. Seems that while the car is designed to start with a battery with as little as 400 cranking amps, when that relay goes south the car requires a full 600 cranking amps to start. And then he does the right thing and refunds the money you paid for the relay.

 

My position on this thread is that you should contact Dantz tech support. If you've used up the support incident that was included in your purchase or upgrade of Retrospect 6, you should bite the bullet and pay the $70. If they help you to solve the problem, then it was something on your end and the money would have been well spent. If it's a software defect that makes the program fail you can ask for a refund and will probably get it without a problem.

Link to comment
Share on other sites

Quote:

 

Given the raw capacity of your autoloader, if you're getting about 25% compression, that 50GB wall you're running into could be due to your autoloader changing tapes, which would make your problem identical to mine. Does your autoloader have the ability to log media changes, or else can someone supervise the autoloader when your backup is about to hit your 50GB limit, and see whether the piton error happens right after a tape swap?

 


 

We were thinking the same thing, and are going to test this tomorrow.

Link to comment
Share on other sites

  • 1 month later...

Well, after not being able to resolve this, I finally decided to bite the bullet, follow your suggestion, and call Dantz as soon as the tech support line opened this morning. After receiving a service request number, I've been on hold waiting for a tech support person for more than _two_ hours. With no indication of how long it might take, although the recording keeps reminding me that my "call is important". Lord, this company stinks.

Link to comment
Share on other sites

  • 4 weeks later...

I can't believe that this is still happening!

 

I was one of the people reporting this problem (back in May, I think). For me the solution was reverting my Win2K clients from Retrospect Client 6.5 back to 6.0. I never had a problem backing up my OS X hard drive itself, but I couldn't add new media members to a backup set for my clients...if they were Windows 2K clients running version 6.5.x of the Retrospect client, that is. Reverting to version 6.0.X of the client, however worked fine.

 

This week I got a fancy new WinXP machine, and I thought, surely, the 6.5 client will work with XP!

 

Wrong!

 

It still hangs after preparing the second member for backup!

 

I rebooted and am about to switch members on my second try...if it fails I'll have to see if 6.0.x runs on XP...

 

(Frustrated still!)

Jeff

Link to comment
Share on other sites

OK, no such luck.

 

It didn't work with my external QPS CD-RW drive, then it did with my internal Quicksilver superdrive and it worked! Then I added the third cd and it didn't.

 

So now with the latest version of Retrospect on my Mac and reverting to client version 6.0.x on my Win XP machine, I'm trying yet another backup!

 

Stay tuned...

Link to comment
Share on other sites

Yep, there it is. Downgrade the client to 6.0.x and voila...presto...works like a champ.

 

What is going on? the latest mac server Retrospect sw can't work with the latest Windows client sw, but it can work with the previous version of client sw?

 

Am I the only person with this problem?

 

Dantz/ECM, help!

 

Jeff

Link to comment
Share on other sites

We have experienced all the problems described above. Dantz has acknowledged the Win client 6.5 media change bug and recommends the 6.0 client downgrade as a workaround.

 

Dantz does not acknowledge a similar bug with OS X clients, and in fact seems to willfully deny the possibility of a bug. After experiencing a flurry of piton protocol errors at media changes for OS X clients under Retrospect 6.0 (we upgraded on November 1), I retrieved operations logs covering the past 13 months. I discovered that under Retrospect 5.0 / OS 9.2.2, Retrospect 5.1 / OS 10.2.8, and Retrospect 5.1 / OS 10.3.x, EVERY piton protocol error that was reported corresponded to a media member change (we use DDS tapes).

 

Under Retrospect 5.x, only about half of the media member changes that occurred while backing up an OS X client generated a piton protocol error. Thus far under Retrospect 6.0, every media member change that has occurred while backing up an OS X client has generated a piton protocol error.

 

I find it hard to believe that everyone who has reported this error is experiencing network problems. In our network, each office is served by two routers. It's easy to shift the Ethernet cable from one router's jack to the other. The fact that the problem remains tells me that it is almost certainly due to one of three reasons: 1) a faulty network interface in the backup Mac; 2) the configuration of our routers (they are, for example, configured to block subnet broadcasts across them); or 3) the Retrospect software itself (either client or backup); specifically, how the software handles paused backups in certain network configurations. The preponderance of evidence suggests it's probably option 3.

 

Dantz would do well to take this issue seriously and start compiling a history of these problems. Since they are the only ones who know how the proprietary piton protocol works, they are the only ones in a position to develop insights into how the problem may be being generated. For example, every time a user reports a piton error, start by having the user check the backup set configuration and determine whether a media member change occurred at the time.

Link to comment
Share on other sites

Quote:

The fact that the problem remains tells me that it is almost certainly due to one of three reasons:

 


 

If it's true that _every_ media request during a Client backup results in this error, it would be trivial to test for #2, and only moderetly more involved to test for #1.

 

If a test condition that always fails with your stock condition is successful without the LAN infrastructure, or on a different physical Macintosh, you've pretty much removed #3 as the cause.

 

I find it hard to believe that everyone who has reported this error is unwilling to test with a cross-over cable.

 

Dave

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...