Copious Posted February 3, 2012 Report Share Posted February 3, 2012 Okay so I'm currently running Retrospect single server 7.6.123 and Driver update and hot fix 7.6.2.101 on a Windows XP x86 box with 4GB of RAM. We use this machine to backup a couple folders from about 200 workstations throughout the building. All the data gets sent to a DroboPro via iSCSI connection directly off the box. The "problem" that I'm seeing is that while the backup never quits per se, the transfer is very sporadic. Looking at my network utilization, the traffic spikes every now and then dropping back to zero for at times 30 seconds before spiking again. Retrospect only shows the files being transferred during the spikes and doesn't move while the network utilization is a zero (obviously). Retrospect claims that it's transferring at 34.5MB/min although I would imagine that is false since the box is on a 100Mb switch and the traffic is spiking. My question is, is this normal? Is the client doing something like gathering up data and pushing it to the server in chunks or what? The files that it's pausing on can't be more than a few megabytes in size and eventually (during the spikes) you can see similar files zipping by quickly. Also, are there any optimizations within Retrospect or within Windows that would correct this issue or at least make the transfer more consistent? All the clients are set to give the backup 100% priority. Sorry, loaded post. Just can't seem to get this to run as well as I know it can. 1 Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted February 3, 2012 Report Share Posted February 3, 2012 Retrospect claims that it's transferring at 34.5MB/min although I would imagine that is false since the box is on a 100Mb OK, the network is 100MegaBIT per SECOND, which is about 10MegaBYTE per SECOND, or 600 MB per minute. Retrospect claims 35 MB per minute, which seems slow but reasonable. Quote Link to comment Share on other sites More sharing options...
Copious Posted February 3, 2012 Author Report Share Posted February 3, 2012 I think that's where my confusion comes in. When the backup begins, it starts out pretty strong at around 200MB to 300MB per minute. Once the traffic spiking starts (goes from zero to 100% for a few seconds and then drops to zero for up to 30 seconds), that drops to around 35MB/min. This occurs even at night when network traffic is at a minimal and the machines aren't likely to be in use. I mean 35MB/min is a far cry from 600MB/min theoretical. I was just wondering if there was some factor that I wasn't taking into account that I could change to speed this up. Thanks so much for your response! Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted February 15, 2012 Report Share Posted February 15, 2012 We had just a (very) similar problem here: We have a couple of RAID-5 iSCSI devices (from HP, not Drobo). One of them crashed due to a broken hard drive. (Yes, that should not take the server down, but this time it did.) After getting the replacement drive and reinstalling the software, the performance was VERY bad. After some days of troubleshooting it turned out the "write cache" was turned off. This affected only iSCSI performance for some reason. Turning write cache ON solved the bad performance problem. We had the same symptoms: Starts out just fine, but after a few hundred MB, the performance went bad. No network activity, except for short bursts. See if you can turn of the write cache on the Drobo and see if that helps. EDIT: Sorry for the late reply: Email notification failed. Quote Link to comment Share on other sites More sharing options...
Copious Posted August 15, 2012 Author Report Share Posted August 15, 2012 I know this is very old right now, but just in case anyone else has a similar problem, this did work for us. Thanks for the help! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.