Is retrospect 'Fragile'???

[pholzmann]

We're evaluating Retrospect, hoping we can both use and recommend to many clients around the world. Finding a number of strange/painful problems.

 

 

 

Overall, perhaps the most painful is that the software seems "fragile" with respect to its access to network resources and the SCSI tape drvie.

 

 

 

Scenario:

 

-- A 10/100 ethernet LAN that runs very reliably. Our test tools are easily able to transfer data continuously at wireline speed without any data errors or drops.

 

-- A SCSI backup drive (VXA-1) that also runs very reliably. We've used other software (Cheyenne Backup for Windows, Knox Arkeia for Linux) pretty extensively without hiccups.

 

 

 

We're seeing the following kinds of problems, quite regularly:

 

 

 

1) Intermittent loss of access to shared files. When backing up network shares (from Win98 and Linux/Samba), the backup will run for a while, then typically get a lot (hundreds) of -1116 errors [can't access network volume]. Immediately retrying the backup will cause more of these files to be found without trouble. The network volume has not hiccuped, nor has the network had a problem. [One guess?... our portable laptops are set with relatively short DHCP renewal times. Could there be a bug such that if the IP address is renewed (even to the same IP address, since ours are hardwired to the MAC address), the backup breaks? This would be a subtle bug to find, since desktop machines would by default only experience this problem every couple of days when the DHCP address renews.]

 

 

 

2) Extreme sensitivity to network or client activity (?). Apparently, if a client runs any screen saver (even a very mild standard Windows screensaver on a 1.5GHz Win2k Pro machine), the backup will terminate with a -519 error. What's really strange about this one: the situation where we saw this was with a client that had two partitions to be backed up, both on the same physical hard drive. Drive "C:" backed up without error (perhaps because it is small?). Drive "F:" had a lot of trouble until we carefully disabled all screen savers, etc. I don't understand why there's such sensitivity to speed; this is a fast machine, obtaining 10000 k/sec network throughput without trouble.

 

 

 

3) Extreme sensitivity to tape/SCSI errors. Using our setup, I've never before had a backup terminate prematurely due to SCSI communication errors. Our drive always passes all SCSI communication tests. But we've seen Retrospect terminate backups prematurely _several_ times in the last few days, due to such errors (error 203, hardware failure). Without any change, retrying the backup succeeds. Makes me wonder if it is retrying properly or has some other type of bug.

 

 

 

We'll continue to test to see if we can discover ways to make all this more reliable. Suggestions most welcome however. Right now, we're concerned that it just seems way too hard to get a reliable backup.

 

 

 

Thanks,

 

Pete

 

 

[KingMongo]

I would agree with your assessment(s).

 

 

 

Yes, you can't have any power saving turned on on the client machines, at least, not in my experience, screensavers included.

 

 

 

And, yes, Retrospect is starting to behave very unreliably for us. For some reason, the tapes keep getting "out of sync" with our catalogs, which means that they then have to be repaired; major pain in the butt.

 

 

 

And, like you, we don't have any discernible SCSI communication errors.

 

 

 

Very frustrating.

[windowsguy]

Retrospect 5.x for Windows is extremely fragile. One of my computers is not getting backed up now because a single file can't be read on the disk due to a sector that's apparently gone bad. Rather than skip that file and proceed, Retrospect issues a "winerrr 999, error -1001" and quits. Same fragileness with regard to the network. If there's even the slightest hiccup on your network during the backup, Retrospect just stops. The programmers at Dantz don't seem to have thought of retrying operations a few times, then failing. Their code just bails all the way out as soon as there's the slightest problem.

 

 

 

In spite of its price, Retrospect Workgroup Backup is just a toy. For a backup to work, absolutely everything has to go perfectly. Every file has to be accessible, there can't be any bad sectors on your disk, your network has to be practically idle, etc.

 

 

 

I switched from ArcServeIT to Retrospect because ArcServeIT was also very unforgiving, and also extremely complex to use. Retrospect is easier to use, but no more robust. There's got to be something better out there.

[windowsguy]

Also, Retrospect is 10x slower than ArcServeIT was.

[AmyJ]

Sometimes people ask why Retrospect is so sensitive to problems in various systems of a computer or computing environment. The answer is that Retrospect is not overly sensitive or fragile, but that backup utilities by their very nature can expose failings in a system, because they access so many different systems extensively. Retrospect exercises the file system, hard disk, network, and device transports of a computer extensively.

 

 

 

File system and hard disk:

 

 

 

To back up a computer, Retrospect must copy all files on the hard drive. This involves creating a list of all of the files, and then reading each file, byte for byte from the hard disk. Intentionally or not, this ends up testing both the file system and the hard disk. If there are errors, or corruptions, or failures, the act of scanning the directory for all files, and then reading all files in their entirety will often expose the problem.

 

 

 

Network:

 

 

 

If you are backing up over a network, Retrospect exercises the network extensively. Obvious to copy every single file from a computer over the network, to another computer extensively uses the network interface card (NIC) on both computers, as well as all of the network and network hardware that connects them. The strain this puts onto the network and network components is all appropriate, that is, Retrospect does not "try to copy too much," as networks are set up to control throughput naturally. It is not Retrospect's job to throttle back data transport: a properly functioning system takes care of itself. If a network fails for Retrospect backups, usually one or more parts of that network are faulty.

 

 

 

Device Transport:

 

 

 

Retrospect reads and writes data using various device transports, such as USB, IEEE 1394 or FireWire, ATAPI, and SCSI. Each device transport has its own requirements and limitations, but Retrospect can properly and completely back up data using any of these. Retrospect is not overly sensitive to errors on any transport; Retrospect simply sends commands and data to devices, following each transport's strict protocols. If unexpected errors are reported, Retrospect reports to the user. In a properly functioning system, all will be well. If, however, something is not operating properly (for example, a SCSI bus is not properly terminated or you are using old IEEE 1394 device drivers for a new 1394 device bridge), errors can be reported. The issue here is not one of sensitivity, but rather the nature of backup: if data is reported to not have been written or read properly, Retrospect must report it to the user, to avoid data loss.

 

 

 

People from time to time contact Dantz to complain that Retrospect does not work with a device, or that Retrospect reports an error, but that another backup application does not. There are many possible causes for this. First, and most frightening, it is possible that the other backup application is simply ignoring the error, and that your data is not actually being backed up properly. Second, there are many ways to access devices, including hundreds of commands and series of commands an application can use to send data for backup. Another backup application many issue commands to a backup device in a different order, or in fact use entirely different ways of writing. This does not make Retrospect's access methods incorrect, or inappropriate (nor the other application's for that matter). Dantz spends tremendous resources on testing and qualifying various backup devices with Retrospect; if we certify that a device is compatible with Retrospect, we have thoroughly tested the drive. This does not mean that in some configurations other factors will not be able to interfere.

 

 

 

The bottom line, though, is this: Retrospect is not fragile, or overly sensitive to hiccups in the computing environment. It is doing what you want a backup product to do: meticulously and carefully making sure that your data is backed up properly.

[windowsguy]

As an end user of Retrospect, and as a professional software developer, it's my opinion that Retrospect is a very fragile product, for the reasons I detailed in my earlier post. Why does it quit backing up an entire disk because it's can't read one sector of one file? Why not instead report that error, and continue backing up the rest of the disk? Why does it stop backing up a system if network connectivity is lost for a brief moment? Why not instead attempt to reconnect to the backup client software for 30-60 seconds, then give up? There seem to be no retries built into the software, and as a result, either your backup works perfectly, or you get no backup at all. I'd rather have 999,999 files backed up successfully and receive a warning about one file that couldn't be backed up, than have the program give up entirely because of that one file.

[AmyJ]

In reply to:

---

Why does it quit backing up an entire disk because it's can't read one sector of one file?

---

If there is a file error, this will be logged and the backup will continue. If there is a disk error, which is considered a fatal error, the backup will stop. When referring to these errors, it would be helpful to cite the exact error you are seeing.

 

 

 

In reply to:

---

Why does it stop backing up a system if network connectivity is lost for a brief moment? Why not instead attempt to reconnect to the backup client software for 30-60 seconds, then give up? There seem to be no retries built into the software, and as a result, either your backup works perfectly, or you get no backup at all.

---

This is called a Net Retry. Amount of time without communication between the client and the backup computer before a Net Retry dialog appears = 10 seconds. Net retries will ultimately result in an Error 519. Amount of time without ANY communication between the client and the backup computer for a 519 error to occur = 2 minutes.

[windowsguy]

I'm not seeing the Net Retry behavior you describe. Is this configured somewhere? If it is, I can't find it in the UI. What I've always seen is that a single short networking blip causes Retrospect to stop backing up the client that's currently being backed up. No warning dialog appears on the backup client.

 

 

 

The other day, I happened to have my laptop undocked when the backup started, so I was connected via WiFi. During the backup, the WiFi link dropped for a few seconds. The dropout was about 5 seconds long. My VPN connection to an external client terminated, because it drops after a very short amount of non-connectivity. Retrospect also stopped and issued a -519. All my other networking applications, such as instant message clients either stayed connected or re-connected transparently.

 

 

 

I won't even ask why Retrospect can't handle me suspending the laptop, docking it, and waking it up. This doesn't work even if I pause the backup on the server. I would like to have done that the other day, since WiFi is 11Mbit and my LAN is 100Mbit. Every other network-aware application I have handles this situation fine.

 

 

 

As for deciding that one bad sector is a fatal error, let me decide that. I'm going to run PartitionMagic on the disk today to block out the bad sector, but in the meantime, Retrospect ought to give me the option to keep going. Windows and Windows applications don't refuse to run because of one bad sector. If that bad sector happens to be a Word file, Word will tell me it can't open that file, but it will let me edit other files, or create new ones. Retrospect's policy is the equivalent of Word telling me that because one Word file has a bad sector, I can't run Word at all.

[AmyJ]

If there is a file error, this will be logged and the backup will continue. If there is a disk error, which is considered a fatal error, the backup will stop. When referring to these errors, it would be helpful to cite the exact error you are seeing.

 

 

 

You are referring to bad sectors on your hard disk and bad files interchangeably. These are not the same things. A bad sector refers to a flaw with the hard disk drive disk, while a bad file refers to a flaw with the file. While you can relate cause and effect (a bad sector can cause a bad file), they are still two distinctly different issues and do not always go hand in hand.

 

 

 

 

[windowsguy]

I understand the difference between a disk error and a file error. I understand that Retrospect stops backing up a client when it encounters a disk error. My point was that I would prefer to have an option on whether to continue or stop. Some disk errors are truly fatal, but most are very localized. A bad sector makes the file that owns that sector unreadable, but all other files on the disk are probably still readable. Retrospect seems to assume that any disk error, no matter how localized, is completely and utterly fatal. My point was that other applications, and Windows itself, behave differently. Word doesn't tell me "You can't edit any files on C: because Word encountered a disk error reading a Word file on C:". It may tell me it can't open the affected file, but it lets me work on other files. I would prefer if Retrospect gave me that option.

 

 

 

And I would sure like to understand how to enable and/or configure the Net Retry behavior you described earlier, because the behavior on my system is not at all like that. There doesn't seem to be any waiting period or retry; the slightest network hiccup stops Retrospect in its tracks. The online help does not have any entries for "retry".

[windowsguy]

I did a test during last night's backup. I removed the ethernet cable from my laptop for a very brief instant. I just unplugged it a tiny bit, then plugged it right back in. Retrospect paused, then continued the backup. I then removed it for 8 seconds and plugged it back in. No Net Retry dialog appeared on the server or the client. The server paused for awhile, then issued this error and quit the backup: "Trouble reading files, error -519 (network communication failed). If this retry capability actually exists in the product, why isn't it working on my system?

[CW_NS]

Though I have to agree that I haven't found any controls for things like "retries", it is my

 

experience that Retrospect DOES perform them, and absolutely does continue on with the

 

remainder of the backup routine after a particular SERIES of failed attempts for a particular

 

item in the script.

 

I've actually watched it do this. Kinda like watching a clothes dryer in action, but I

 

was actually watching for another reason when I noticed the progress window show that

 

Retrospect was trying to get a particular file again.

 

(Don't ask me what it actually said or did. I don't make a habit of staring at progress bars

 

so I don't recall if it was a text thing, or some other. I all remember is making a mental

 

note that it DOES make a couple of attempts before moving on to the next item in the

 

script.)

 

I've never seen it shut down a backup routine completely. So I can't speak to that one

 

at all.

 

 

 

One question does come to mind though. If you know you have a computer reporting

 

disk errors, why hasn't that disk been replaced yet? If not taken care of soon, a lack

 

of tape backup could possibly be the least of your concerns about it.

 

And if you can't get it onto tape in preparation for replacment, don't wait for the tape.

 

Just start copying to another drive and pitch that bad boy out a window, I'd say.

 

(My 2 farthings, FWIW.)

 

 

 

Have a great one,

 

Derick

[cblair]

I have to agree with "windowsguy" on his posts. We have a small network of 7 computers and we experience similar problems. There seems to be no rhyme or reason to when the fatal errors occur during our backups. We backup 3 times a week (Mon; Wed; Fri) and sometimes we go 3 or 4 backups without incidence. Then...we'll have 6 or 7 failures in a row.

 

 

 

We also recently upgraded (new P4 computers) all but one of our computers (it was reformatted and new OS installed)...and hired a local software company (they write software nationally for major corporations) to install and set-up our network. Alas...the exact same Retrospect problems continue to occur. Like "windowsguy"...the rest of our computer network system works perfectly...with virtually no other software application problems. We're using backup hardware (Onstream ADR drive) that's on Dantz's list of approved hardware and we've checked and double checked that the correct drivers...firmware updates etc. are all applied.

 

 

 

In addition...we've had the Onstream drive replaced (at no charge to us I might add even though Onstream couldn't find a problem with the original drive)...and tried it in three different computers with different motherboards; CPU's etc. All with the same poor results.

 

 

 

I think what "windowsguy" is getting at is that it's pretty ridiculous for critical software like backup software to be this difficult to configure so that it won't fail.

 

 

 

And in a small company...switching is a major pain since usually the guy/girl doing network administration and handling back-up issues is doing it only as a small part of his/her overall duties.

 

 

 

Like "windowsguy" we've also tried several other backup software titles with various forms of problems so it's not just Dantz software that has issues. We've tried Windows Backup; ArcServe; and Veritas products...and all had some kind of issues that caused us to move to something else.

 

 

 

I'm sure Dantz has thousands of customers using their software without problems. But when you read through these forums and see literally hundreds of OTHER users experiencing a mutlitude of major problems...it's pretty frustrating to see other forum members say in essence: "Windows systems and networks are complex and many other things could cause the software to fail."

 

 

 

Our conclusion is the same as "windowsguy." Retrospect is VERY picky about the hardware; OS and it's configuration. Which if you think about it.... is ridiculous...since every company's computers and networks will most assuredly be vastly different from one another.

 

 

 

Chris Blair

 

Magnetic Image, Inc.

 

Evansville, IN

 

 

[JeffV]

Amen, WindowsGuy. I have a client who is chomping at the bit to replace Veritas Backup Exec. We are using Retro on a couple of systems as a trial, and I am using it on my home network. But while I see a lot of things to like, I'm concerned about what I read here, and what I've seen on my trial systems.

 

 

 

No Dantz apologists need reply. We need answers.

 

 

 

Jeff Vandervoort

 

JRVsystems

[AmyJ]

In reply to:

---

No Dantz apologists need reply. We need answers.

---

 

 

 

What is the question? I understand you're frustrated using the software, however I don't see information in your post related to what exactly isn't working for you.

 

 

[JeffV]

My post is coming, but it will be in a new thread.

 

 

 

Clearly, my comment was in support of WindowsGuy, and his frustration with having his very real Retrospect problems blamed on everything in the world but Retrospect. That sort of thing greatly diminishes the value of a support board, and concerns me as I evaluate Retrospect.

 

 

 

I used to do volunteer peer support for a few MS products on CompuServe in the olden dayes, and as a Microsoft MVP after that. I was enthusiastic about the products I supported, but I never hesitated to call a spade a spade.

[AmyJ]

Retrospect does have issues, and we address them openly on these boards and on our website. Some issues (errors) are network or hardware generated - and Retrospect is the messenger, not the cause.

 

 

 

Windowsguy had questions with Retrospect not continuing a backup after discovering that his hard disk was having problems and also that when his network cable was unplugged for too long, Retrospect logged an error and moved on. These are problems in the environment that are not being caused by the software - they are being reported by the software. His suggestions that Retrospect should continue despite finding hard disk failure and loss of network connectivity were noted.

 

 

[windowsguy]

Once again, AmyC is either missing most of my point, or choosing to gloss over it. When I tested Retrospect by unplugging the network cable for 8 seconds, it was because she said (http://forums.dantz.com/ubbthreads/showthreaded.php?Cat=&Board=Server&Number=14477&page=&view=&sb=&o=) that Retrospect would retry for 10 seconds, then display a dialog telling the sysadmin about the problem. I had never seen this 'NetRetry' behavior, so I did that simple test. Once again, what AmyC described did not happen. Retrospect recovered if the cable was unplugged for 5 seconds, but when it was unplugged for 8 seconds, Retrospect gave up.

 

 

 

My main point is that for Retrospect to work, you have to have a quiescent, perfect LAN, and don't you dare touch anything while the backup is going on. Another example: This morning, my wife was trying to use her computer while it was being backed up, but she found the computer to be very slow. I started the Retrospect client on her computer, and lowered the Priority on the Preferences tab one notch. Almost the instant I clicked Apply, the Retrospect server issued a -519 error and stopped backing up her computer. That is fragile software.

 

 

 

As for not continuing when Retrospect encounters a disk error; I point out again that every other piece of Windows software simply alerts the user if it encounters a bad disk sector in a data file, then lets the user continue working on other files. Word doesn't refuse to run just because one Word file on your disk has a bad sector in its midst.

 

 

 

I continue to have unexplained problems with Retrospect almost daily. I get mysterious -519 errors all the time, for no apparent reason. Once again, I point out that all my other network-aware software is built robustly enough to retry and virtually always recover when it encounters a network error. I stand by my assertion that Retrospect could do a lot better.

 

 

 

I've also been very disappointed in the usefulness of this forum. Rather than offer much help, the replies to my posts have spent 99% of their time asserting that the problems I'm encountering can't possibly be Retrospect's fault. A company that won't admit it has problems in its products is extremely unlikely to be able to fix those problems.

[Zarniwoop]

Here is a section of the log from the most recent issue I have had. The timeout was clearly more than 2 minutes. As you can see, it took Retrospect 4 days to time out on a client. This completely ruins our backup schedule for yet another whole week, as weekends are the only time we have to perform a recycle backup. This is a client I visit one day weekly, and due to the unstable nature of Retrospect, I will have to start checking on them daily just to see if the backup is "hung". Every other time backup has hung like this, I had manually intervened (see below), but this time the server was left to handle this unattended and for the first time I can see that it stopped for 4 days before erroring out.

 

 

 

I have found no recourse when Retrospect hangs like this other than to use the Support Tools KILL.EXE on the process and start the service again, or reboot the server.

 

 

 

- 10/31/2002 9:43:46 PM: Copying Drive C (C:) on CDAHLK

 

10/31/2002 9:57:43 PM: Snapshot stored, 31.4 MB

 

10/31/2002 9:57:51 PM: Comparing Drive C (C:) on CDAHLK

 

File "C:\WINDOWS\Prefetch\RTHLPSVC.EXE-18DFBDDD.pf": different modify date/time (set: 10/30/2002 9:45:56 PM, vol: 10/31/2002 9:45:27 PM)

 

10/31/2002 9:58:17 PM: 1 execution errors

 

Completed: 176 files, 21.6 MB

 

Performance: 92.4 MB/minute (143.7 copy, 71.8 compare)

 

Duration: 00:14:31 (00:14:02 idle/loading/preparing)

 

 

 

10/31/2002 9:58:18 PM: Connected to DDAYTON

 

 

 

- 10/31/2002 9:58:19 PM: Copying Drive C (C:) on DDAYTON

 

10/31/2002 10:13:10 PM: Snapshot stored, 33.4 MB

 

10/31/2002 10:13:19 PM: Comparing Drive C (C:) on DDAYTON

 

File "C:\WINDOWS\Prefetch\RTHLPSVC.EXE-18DFBDDD.pf": different modify date/time (set: 10/30/2002 10:00:59 PM, vol: 10/31/2002 10:00:11 PM)

 

10/31/2002 10:13:48 PM: 1 execution errors

 

Completed: 131 files, 74.6 MB

 

Performance: 229.3 MB/minute (248.4 copy, 212.9 compare)

 

Duration: 00:15:28 (00:14:48 idle/loading/preparing)

 

 

 

10/31/2002 10:13:48 PM: Connected to DRAFTING

 

* Resolved container DRAFTING to 2 volumes:

 

Drive C (C:) on DRAFTING

 

Local Disk (D:) on DRAFTING

 

Can't access volume Drive C (C:) on DRAFTING, error -519 (network communication failed)

 

Can't access volume Local Disk (D:) on DRAFTING, error -519 (network communication failed)

 

 

 

11/4/2002 9:26:09 AM: Connected to DWHALEY

 

* Resolved container DWHALEY to 3 volumes:

 

Drive C (C:) on DWHALEY

 

Drive E (E:) on DWHALEY

 

Drive L (L:) on DWHALEY

 

 

 

- 11/4/2002 9:26:18 AM: Copying Drive C (C:) on DWHALEY

 

 

[AmyJ]

Please post more information about the problems you are experiencing such as version numbers of the application and client, operating systems in use on the backup server and the client.

 

 

 

What was the state of the client machine when this occured? Was it locked up? Responding normally?

 

 

 

You indicated that this has hung in the past - does it always occur on the same client? Multiple clients? Same backup set? Different backup sets? Have you established a pattern to the hangs?

 

 

 

What does Retrospect say it's doing when it's hung up? Is is copying? Connected to a client? What's on the screen?

 

 

 

Please provide any and all relevant information so we have a better understanding of your configuration.

[Guest]

I have to agree totally with this entire thread. While I can't say I've experienced problems exactly similar to all of these mentioned on this post, I can say that I have had to deal with the fragility of Retrospect on numerous ocasions.

 

 

 

I've experienced network problems of all sorts, even though my company's network is new, Retrospect seems to be the only program in existance that shows all these apparent problems. I find this nearly impossible.

 

 

 

Forget about remote managment, which I do a lot for most of my other duties, because Retrospect can't be run as a service (at least 5.6) and as such, you can't open it when it is already opened on another account. If you were so lucky and it managed to close itself after a "successful" backup, and you open it remotely, I've found it simply will not execute the next time its supposed to. This is corporate class software, why hasn't this been addressed?

 

 

 

Perhaps Retrospect 6.0 is the answer to all my problems, but budget is low at the moment, so we will be waiting on the upgrade for a few months. For the time though, critical problems like the ones mentioned on this thread, should be addressed with free patches in my opinion.

 

 

 

My time is divided between a number of tasks, and unfortunately I can't spend all my time working on Retrospect. I guess what I'm trying to say is that I add my vote to the fact that Retrospect is incredibly fragile. I've seen it not just for network problems, but problems of all sorts.

 

 

 

Eric

[Zarniwoop]

You said:

 

>Please post more information about the problems you are experiencing such as version numbers of the application and client, operating systems in use on the backup server and the client.

 

 

 

Server is:

 

+ Retrospect version 5.6.132

 

Launched at 11/14/2002 2:47 PM

 

+ Retrospect Driver Update, version 3.1.103

 

 

 

Clients are 5.6.

 

 

 

>What was the state of the client machine when this occured? Was it locked up? Responding normally?

 

 

 

The clients are powered on at all times. Backups are scheduled when people are not here, so the client was idle. Occasionally people power off when they go on vacation, and the laptops are not always here.

 

 

 

>You indicated that this has hung in the past - does it always occur on the same client? Multiple clients? Same backup set? Different backup sets? Have you established a pattern to the hangs?

 

 

 

It does not always occur on the same client, or the same backup set. We have 9 backup sets corresponding to weekly recycled then appended normal backups, rotated to give a 9 week history and recoverability. There is no pattern.

 

 

 

>What does Retrospect say it's doing when it's hung up? Is is copying? Connected to a client? What's on the screen?

 

 

 

I will take a screen shot next time. It is on a normal backup screen. The stop button, once pushed, does not cause the backup to end. Stopping the service is denied. Only forced killing the process ID and then starting the service, or rebooting the server makes Retrospect usable again.

 

 

 

This is the point I have a problem with. The screen is not moving, it is obvious nothing is happening. It is hung and should continue all by itself. Not after 4 days, not after 4 hours even. Backups that don't finish make the next backup not start, and then there is no backup.

 

 

 

>Please provide any and all relevant information so we have a better understanding of your configuration.

 

 

 

Server class hardware, Cisco 3548 switch, Brand new Dell Windows XP clients, and a few older Windows 2000 clients wired at 100Mbit, server wired at 1000Mbit. Exabyte Mammoth 7-tape loader with Mammotn-2 60/150GB drive.

[Zarniwoop]

Is this thread now being left to die away ?

[AmyJ]

How often does the problem occur? Is it easily reproducible?

 

 

 

What else is running on the machine during the backup? Utilities? Anti-Virus software? File Server apps?

 

 

 

Have you tried reinstalling Retrospect?

 

 

 

Does this ever happen on the backup of the local drives - or only with client computers?

 

 

 

Unfortunately, trying to solve a problem that has no discernable pattern through a community forum can be difficult. The goal is to isolate the variables involved to determine which one is causing the issue.

 

 

 

Make sure your computer and backup device have all the latest updates from the vendor (including firmware).

 

Check your SCSI card drives and firmware

 

Quit any running programs, and disable any programs running in the background.

 

Make sure the NIC drivers are current

 

Reinstall the TCP/IP protocols

 

 

 

Do you have another computer you can try with Retrospect for a few days to see if the problem follows to another computer?

[rmorton]

Does Retro 6.0 solve the problems identified in this post?